Wikipedia:Village pump (all)

From Wikipedia, the free encyclopedia

This is the Village pump (all) page which lists all topics for easy viewing. Go to the village pump to view a list of the Village Pump divisions, or click the edit link above the section you'd like to comment in. To view a list of all recent revisions to this page, click the history link above and follow the on-screen directions.

Click here to purge the server cache of this page (to see recent changes on Village pump subpages)


Village pump sections

Edit-find-replace.svg
Policy
watch
To discuss existing and proposed policies

Preferences-system.svg
Technical
watch
To discuss technical issues. For wiki software bug reports, use Phabricator

Dialog-information on.svg
Proposals
watch
To discuss new proposals that are not policy-related. See also: perennial proposals.

Tools-hammer.svg
Idea lab
watch
To discuss ideas before proposing them to the community and attempt to find solutions to issues

Help-browser.svg
Miscellaneous
watch
To post messages that do not fit into any other category

View all village pump sections at once

Other help and discussion locations
I want... Where to go
...help using or editing Wikipedia Help desk
...to find my way around Wikipedia Department directory
...specific facts (e.g. Who was the first pope?) Reference desk
...constructive criticism from others for a specific article Peer review
...help resolving a specific article edit dispute or making a user conduct dispute complaint  Requests for comment
...to comment on a specific article Article's talk page
...to view other Wikimedia projects Wikimedia Meta-Wiki
...to learn about citing Wikipedia in a bibliography Citing Wikipedia
...to report sites that copy Wikipedia content Mirrors and forks
...to ask questions or make comments Questions


Contents

Discussions older than 7 days (date of last made comment) are moved to a sub page of each section (called (section name)/Archive).

Policy

Should Wikipedians be allowed to use community granted tools in exchange for money?

Recently we had an OTRS "volunteer" lose their access to the tool here. User:KDS4444 is a well known long term paid editor.

This raises the question:

  • Should OTRS volunteers be allowed to request money from people sending in question to OTRS?
  • Should editors at AfC be able to request money for passing / accepting an article at AfC?
  • Should admins be allowed to bill for undeleting an article / use of admin tools?
  • Etc

Or should we have policies clearly disallowing this. Doc James (talk · contribs · email) 16:18, 1 November 2017 (UTC)

  • Seems like WP:INVOLVED and WP:COI capture most of the spirit of this, and would be the places to amend if clarification is needed. — xaosflux Talk 16:40, 1 November 2017 (UTC)
    • That we have had OTRS agents using the system to make money proves that when it comes to paid editing "spirit" is often not enough. We need it to be black and white. Doc James (talk · contribs · email) 17:46, 1 November 2017 (UTC)
  • Obviously not, that's corruption. If our existing policies do not effectively forbid it then we should have news ones that do - perhaps amendments to WP:INVOLVED and WP:COI, as xaosflux says. Boing! said Zebedee (talk) 16:58, 1 November 2017 (UTC)
  • I think that an explicit prohibition of such would be a good idea. In government and business that is considered to be bribery or a kickback scheme. And since Wikipedia conflates tools with related powers/positions, we should note that it's not just mis-use of tools, it's mis-use of powers/position. North8000 (talk) 17:10, 1 November 2017 (UTC)
  • The admin aspect was already discussed and rejected as a standalone item. Jo-Jo Eumerus (talk, contributions) 17:11, 1 November 2017 (UTC)
    • One difference is that the proposal there was "No administrator may accept payment to edit articles or to perform any administrative function on Wikipedia" (my emphasis). This suggestion is only about prohibiting paid use of tools. Boing! said Zebedee (talk) 17:17, 1 November 2017 (UTC)
    • And after reading a bit through it, the discussion is essentially about whether admins should be prohibited from paid editing. Boing! said Zebedee (talk) 17:32, 1 November 2017 (UTC)
  • Making rules that are impossible to enforce is...problematic. Honest people lose, liars win. As someone who has never gotten a dime for editing Wikipedia, I can only suggest (mostly facetiously) that all editors be required to give WMF regular copies of all bank statements. Or quarantine all editors on a desert island with internet access. What a nightmare this all is. If I had to guess, I’d say that at least 10% of political edits at Wikipedia are financed by somebody. Anythingyouwant (talk) 17:51, 1 November 2017 (UTC)
    • Locking your door does not prevent 100% of break-in, that does not make it useless. Wikipedia improves when good faith editors overall have a greater ability to contribute that bad faith ones. Rules help achieve a positive balance. Google Knol failed as it filled full of advertising. Doc James (talk · contribs · email) 18:06, 1 November 2017 (UTC)
  • Obviously the answer is 'No!' It's odd that the questions even have to be raised, but the goal therein is to make it absolutely clear, because paid editors - some of whom are notorious for their Wikilawyering - will use any 'omission' in the policies to practice their art. Kudpung กุดผึ้ง (talk) 18:01, 1 November 2017 (UTC)
  • Okay so with respect to wording, what do people thing about adding at WP:COI:
"No one may use admin tools or accepting articles at WP:AfC in exchange for a financial reward. Additionally the WP:OTRS system may no be used for recruiting clients or payment."
Doc James (talk · contribs · email) 17:55, 1 November 2017 (UTC)
  • In order to shine a light on this, if we read current policies as prohibiting administrators, editors or OTRS volunteers, from taking actions while at risk of being thought to be paid for those actions, then no funded academic, employee, Wikimedian in residence, should ever take any action using their editing/sysop/access rights which could in any way benefit their employer or funder, even the scenario often used in the past by certain employees that though they are employed, they were editing in their volunteer time... It might actually be better to highlight case studies where administrators that were in a paid contract or had a grant, did legitimately use the tools as they were the best person at that time to do so, while correctly handling their declaration of interest in a transparent way. There may be cases where conflicts of loyalty have nothing to do with money, and those may also make for useful case studies. -- (talk) 17:55, 1 November 2017 (UTC)
    • If you were a WiR at say the NIH and you protected all NIH related article without explicit consensus to do so, that would still be a problem. Doc James (talk · contribs · email) 18:08, 1 November 2017 (UTC)
    • (edit conflict) Some good points there, which were raised in that other discussion (I've just finished reading it). While we should certainly want to prohibit 'corrupt' use of tools, it's hard to word policy so it does not adversely affect honest use as in examples like those. Boing! said Zebedee (talk) 18:11, 1 November 2017 (UTC)
  • I fully support this. Nick (talk) 18:08, 1 November 2017 (UTC)
  • Anything other than "regular" editing (as can be done by an auto-confirmed user; a name-space restriction has too many edge cases to be reasonable) in exchange for payment should be strictly prohibited. The corner cases (what if a professor who is an admin does admin work on university time) can be figured out by lawyers, the spirit should be clear. power~enwiki (π, ν) 18:10, 1 November 2017 (UTC)
  • I also support making policy clear against potential corruption. I don't have a problem with Doc James formulation; it's of course always possible to improve it in the future for precision, i.e. WMF legal suggestions welcome... —PaleoNeonate – 19:36, 1 November 2017 (UTC)
  • My view: No editor should be allowed to use permissions given through community input or tools that allow editors to work in an "official" capacity (OTRS, etc.) to edit for pay. As long as a draft meets all normal AfC requirements, I'm ok with editors being paid for their work. Admins can be paid for their work as long as they don't use their admin toolbox in the process. Of course, all paid contributions should be declared. Gestrid (talk) 08:24, 2 November 2017 (UTC)
  • OTRS is outside of our domain, and it seems the question has already been answered. However, I'm not aware of any instance of an admin using tools for pay - I'd be hard pressed to think of a situation where that would occur. Do we need to prohibit a practice that doesn't happen? As to AfC, that is a common job request, so it does represent something that happens. My knowledge of AfC is limited, though - do you need special tools in order to approve an article from AfC? I didn't think that was the case, but maybe I'm mistaken. - Bilby (talk) 08:49, 2 November 2017 (UTC)
Bilby, Of course you're not aware of any instance of an admin using tools for pay. I'm not. Nobody is. They are not exactly going to yell it from the rooftops if they are. It's a very plausible concern and I can think of several situations where it might occur. Kudpung กุดผึ้ง (talk) 11:23, 2 November 2017 (UTC)
Hard pressed to think of a situation where an admin using tools for pay would occur? How about undeleting an article that had been deleted, unblocking a blocked paid editor, protecting an article at a favoured revision? It took me about 30 seconds to think of those three. Boing! said Zebedee (talk) 11:37, 2 November 2017 (UTC)
No, I'm hard pressed to think of a situation where an admin is accepting money to undelete an article. The advantages are clear, but I haven't seen an admin use the tools for pay, and I'm hard pressed to picture that situation arising. - Bilby (talk) 11:41, 2 November 2017 (UTC)
Several years ago, a Russian Wikipedia admin was desysopped for using admin tools to promote paid editing.--Ymblanter (talk) 17:24, 2 November 2017 (UTC)
One instance, several years ago, on a different language Wikipedia. Ok. But has this ever happened here? I agree with the principal - no admin should use the tools in return for pay - and if the community wants that to be clearly stated I'm a bit concerned re WP:BUREAU, but it doesn't bother me overly much. I do worry about "the sky is falling" policy changes, though, and pushing through changes without evidence of there being a need for them. - Bilby (talk)
Did you ever hear, (until now), that somebody was actively using OTRS to recruit clients and solicit payments?Winged Blades of GodricOn leave 10:21, 4 November 2017 (UTC)
I can testify for my own part, that this case was particularly egregious and lost me a bit of sleep thinking about it. I realize it may not look that way from our end, but from the perspective of our readers, OTRS is in few ways a higher position of trust than being an admin on wiki. From the perspective of readers, they're getting an email from Wikipedia, and not a message from some anonymous user on Wikipedia. I think per discussion below, I'm personally leaning toward favoring something along the lines of No one may misuse a position of community trust... and perhaps specify that this can include user rights, various coordinator positions, and off wiki access like OTRS and ACC. GMGtalk 10:29, 4 November 2017 (UTC)
The problem with OTRS was a serious one, but that should be handled through OTRS. As I said, I'm not opposed to this on principal. My concern is that I'm seeing a lot of rhetoric and exaggerated claims about paid editing which are leading us to take more extreme steps, but not a lot of data to back up the specific claims. Given that I can't imagine any current admin accepting money to use the admin tools, the change in policy is moot, and I'll support a well worded proposal. It doesn't prevent anyone from doing anything that they were going to do. But I do want to be cautious of inventing problems that don't exist. - Bilby (talk) 11:10, 4 November 2017 (UTC)
Well, at least to my mind, the admin bit isn't really special here. It's just one of many rights or positions, of which there are many requiring both more and less community trust, and more or less oversight. And this isn't an expectation of admins; it's an expectation of everyone, and admins are an everyone. The key common factor there is the trust, not the number of buttons. For example, autopatrolled users are trusted by the community to make acceptable quality articles that don't require community review.
Also pretty much just to my own mind, there are really two distinct types of policy formation. There's policy that attempts to create new process to deal with outstanding problems, and there's policy that simply documents widespread community practice that's already in place, but hasn't been explicitly written down anywhere. I believe this is the latter. It's already a de facto policy. When we have, and if we do find someone abusing positions of trust, we will remove them from that position. That's a fact. But we currently don't appear to have explicit, unequivocal wording that says You knew this was going to happen when you made the decision to abuse your position or access. GMGtalk 11:26, 4 November 2017 (UTC)
I understand where you are coming from - I am fully in agreement that admins should not use tools for pay, with the various normal exceptions for WiR and whatever. My caution comes from seeing what can only be described as a war between paid editors and anti-paid editors, and in that war we're giving up progressively more. Thus I need to ask, every time a new policy change is put forward, the basic three questions - is it needed, will it work, what will it cost? This one costs nothing, in that it is such a specific case that it won't have a wider impact. But it isn't needed, because we have no evidence of this ever happening on en.Wiki. Will it work? I can't see how anything can "stop" something that doesn't occur, but I think we'll find that this is going to be very hard to prove to the level where we can desysop someone if it ever does arise, and that from a practical sense we'll end up using a different justification.
In regard to other tools, though, the approach doesn't seem to be the best solution. With AFC, I think we need a clear statement that says "you cannot approve any draft in return for financial remuneration" - it isn't about the use of tools, but the act of approving a draft. Focusing on the tools is the wrong part of the equation - someone just needs to take the longer process of approving it without any special permissions to meet the policy. Similarly, if we remain worried about auto-patrolled users, we need to say that all paid articles must be created through AfC is we want a real fix. It isn't the auto-patrolled status that is the core problem, but paid articles being created in mainspace and not being independently verified - although there will be more of a cost if we make that change. - Bilby (talk) 11:49, 4 November 2017 (UTC)
Not to beat the horse into a pulp, but to focus narrowly on existing community practice and reasonable expectation of future practice:
  • When we have found users abusing AfC for paid editing, we have removed their access;
  • When we have found users abusing OTRS for solicitation, we have removed their access;
  • If we did find someone abusing autopatrolled to avoid scrutiny of paid articles, we would remove it;
  • If we did find an FA coordinator, a member of the ArbCom electoral commission, etc. abusing their position, we would remove them from it;
  • If we did find a sysop doing this (as other projects have), they'd have their mop snatched so fast it would cause whiplash;
So that raises the question to me, of why we haven't taken the time to write this down, when we seem to all agree to some extent that it is the way things work, and the way they can be expected to work for the foreseeable future. GMGtalk 12:05, 4 November 2017 (UTC)
I don't understand enough about OTRS - my assumption is that it was a meta issue, not a en.WP issue, but if I'm wrong it is something to address here.
In the case of ArbCom, FA coordinators and admins, you are correct - we'd act if we found them. In general I don't really care if we wish to formalize those issues, except to note that we're formalizing something that we've never done, never had to do, and which would happen irrespective of any decision here. I'm wary of the principal of creating unnecessary changes. (I'd also note that, if policy reflects practice, in these cases we're reflecting what we believe would be practice, not what actually is, simply because it has never arisen).
With autopatrolled, yes, we would (and have) removed it. Let's put that in Wikipedia:Autopatrolled as the relevant place to discuss this and make the change. This one is far more important to me, and reflects something that we do, should do, and should formally note.
AfC is the other big issue to me - I would like to see that hole filled, as there are a lot of jobs hiring people to pass articles at AfC. But it isn't the tools that are the issue, so much as the approval. I'd like to see a more important change stating that articles cannot be approved from AfC in return for pay, as that would address the actual problem. Focusing on the tools rather than the approval is an error.
Just to be clear, my disagreement isn't with the spirit of the proposal, but with the two basic issues - I don't like creating policy changes that are not needed, and I don't care for skirting around the real issues (permissions) when we should be addressing the actual problems (approving articles for pay; creating paid articles in mainspace). - Bilby (talk) 13:03, 4 November 2017 (UTC)
Well... it seems the main difference in approaches is that you would like to wait until each individual right or position is abused, and then add a specific policy on that specific topic. (Also, BTW, OTRS is stand alone project and AFAIK the only one running media wiki that doesn't accept SULs.) To my mind, it just seems simpler to put a blanket statement on a central place, like PAID. GMGtalk 13:11, 4 November 2017 (UTC)
Not quite. I have two main differences. a) I'd like to address the real problem at AfC of approving articles for pay, rather than tackling the secondary (and mostly irrelevant) issue of use of permissions. b) I don't think we would need to change in policy even in the unlikely chance that the problems with FAC coordinators, admins or ArbCom members arose, because we would solve it without a change in policy. In that situation, I don't like creating policy changes to address remote issues that have never arisen and wouldn't need a policy change if they ever did arise.
I'm sure we'll end up with a blanket statement at paid. And WP won't end as a result. But I wish this energy went into changes that would have an impact or would address the real problems. - Bilby (talk) 13:22, 4 November 2017 (UTC)
That's part of my concern though, that if we have a blanket statement, we have one arguably time wasting discussion. If we do it piece meal, we end up with separate recurring discussions for each individual piece. GMGtalk 13:49, 4 November 2017 (UTC)
I'm sorry, I think I've been explaining things badly. If we have this discussion and agree to make this change to WP:PAID - which it is likely we will if we can get the wording right - it won't make any difference to how we respond to the main cases you raise: admins, FaC coordinators and ArbCom members. It may not do any harm, but it won't change the response, make it more or less likely that the problem will arise, or make things any easier if the situation ever appears.
In regard to this change and AfC, based on what I was told below, all the paid editor needs to do is not use any advanced permissions to pass something through. They can either argue that use of the helper script is not an advanced user right, or they simply don't use the script and do it the long way. That's because the AfC problem is not about permissions, but about actions. So if we make this change, we will still need to have another discussion to address the real problem.
In the situation of auto-patrolled users, the change I'd most like to see isn't a ruling that paid editors can't create pages in mainspace if auto-patrolled, but a rule that says that paid editors cannot create pages in mainspace. That second one seems more valuable to me, and will also involve a separate discussion.
Anyway, this is not of much value, because we're having the discussion however I may feel about it. :) Which is fine. But I've been arguing against paid editors for many years now, and what I'd most like to see is discussion around actions which will address the core issues without harming the project. This discussion has the advantage of not harming WP, but it retains the disadvantage of not addressing the problems that matter. - Bilby (talk) 14:19, 4 November 2017 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Well, part of my concern is once the issue of the paid OTRS agent was raised, it took several days for access to be removed. Even after the evidence was damning, it didn't seem like anyone wanted to unilaterally pull the trigger. Yes, it's technically a separate jurisdiction, but for English agents, it's pretty much the same cops on the beat. (I don't know of specific instances where autopatrolled has been removed for paid editing, but I'd be interested to.) This is the kind of thing that is to be expected where sysops, ideally cautious by nature, are in fairly uncharted territory as far as the letter of the law.

As to AfC, that and the issue of non-user right positions (coordinators, etc), are the reasons for my focus on emphasizing "positions of trust" and not just user rights. From a lower level implementation standpoint, if there is a project wide policy in place to that effect, project or right specific policies can probably for the most part be boldly added, and simply point to the main. Something along the lines of:

No user may use positions of community trust in order to solicit or accept payment for activities which have a direct and foreseeable impact on Wikipedia. This includes advanced user rights for which individual vetting and permission granting is required, positions of authority elected or appointed by the community, and system access on or off wiki not normally available to all users.

I think something like that would fairly well cover everything, including OTRS and AfC. GMGtalk 15:57, 4 November 2017 (UTC)

GreenMeansGo: to your question, the same OTRS agent Doc James mentioned above voluntarily relinquished their autopatrolled flag after I suggested it to them when the issue was first raised. We have no policy as to when to revoke user permissions in cases like this, and as a recent ArbCom case pointed out, the removal of user permissions is one of the most controversial things an admin can do.
Re: your proposed wording, I think I like it. I might also add something such as ...impact on Wikipedia; or use such a position to take actions on behalf of a client. for clarity. TonyBallioni (talk) 16:05, 4 November 2017 (UTC)
My issue with raising OTRS here is not that it hasn't proven to be an issue, but that my understanding is that OTRS policy is managed at meta, so I assumed that a change in that policy in regard to paid editors has to be presented and discussed there. If this is not the case I have no problems with agreeing to the policy change here, but I had always assumed that OTRS policy is outside of our immediate control.
I still need to return to my issue with the AfC problem. I do not see permissions or "positions of trust" as the primary concern, based on what I've been told. What I think we need is not the change being discussed here, but a clear and unambiguous change to Wikipedia:WikiProject Articles for creation that states that you are not permitted to approve an article where you have a COI, and in particular you are not permitted to approve an article in return for remuneration. It isn't about positions of trust or advanced permissions, but simply who can and cannot approve an article. - Bilby (talk) 16:28, 4 November 2017 (UTC)
Well, my thought was that AfC would be covered under system access on or off wiki not normally available to all users. It's true that en.wiki can't actually enforce anything at OTRS. But I think we can probably still say that someone abusing OTRS to make changes to en.wiki is exactly half in en.wiki jurisdiction, and we can still say that we don't approve of it.
Also, I'm fine with Tony's suggested addition. And I think the absence of policy on when to remove these rights is part of the problem, and part of why sysops are rightfully hesitant to do so. GMGtalk 17:00, 4 November 2017 (UTC)

    • Yeah, AFC Reviewers need access to a helper-script, designed for the purpose, that heavily eases the process/workflow.It may be noted though, that all auto-confirmed editors have the right to move articles from draft space into mainspace or that any body could choose to follow a tedious manual reviewing process, that existed before the development of the script.Winged Blades of GodricOn leave 09:08, 2 November 2017 (UTC)
      • In that case, there are no special permissions needed for AfC? Just optional access to a helper script that is open to any autoconfirmed editor? - Bilby (talk) 10:08, 2 November 2017 (UTC)
        • Manually reviewing articles is sufficiently tedious so as to be prohibitive for most users. It is a de facto user right. GMGtalk 10:27, 2 November 2017 (UTC)
        • Echo Timothy.In a very strict sense, AFC is not a right.But, in my wiki-life, I have neither seen someone evading the script-access-barrier by manually reviewing the submissions nor someone who is moving other author's AfC draft(s) to mainspace without using the script.Winged Blades of GodricOn leave 10:45, 2 November 2017 (UTC)
          • I guess what I'm wondering is if you need special community-granted permission to use the tool. Is this the case? Or an anyone use the tool? - Bilby (talk) 11:41, 2 November 2017 (UTC)
            • AfC works similarly to rights granted at PERM, but at a different venue. All you need is to convince one sysop that you're competent. The major differences are 1) it doesn't automatically come with the admin kit, although theoretically any admin could grant it to themselves, similar maybe to the way some things work with stewards (unless I'm mistaken), 2) it's not technically required for reviewing, but it's a bit like saying you don't technically need access to the elevator to get to the top of the Eiffel Tower. GMGtalk 11:49, 2 November 2017 (UTC)
  • There was "consensus for some language on this issue" last time and it is still a good idea, so support. Alanscottwalker (talk) 10:57, 2 November 2017 (UTC)
  • Regarding Doc J's wording, if it is to be used, it may be simpler and more effective to say No one may use advanced user rights.... I have a hard time imagining a scenario where any right couldn't potentially be abused, which is why they're restricted. In fact, with ACTRIAL in effect, it could be easily argued that creating a paid article outright, instead of going through AfC is itself a type of abuse of auto-confirmed.
For rights with a greater potential for damage (e.g., sysop, AfC, page mover, AWB), and especially for those which have a comparatively limited amount of public oversight (e.g., OTRS, CU, OS)... Well... until very recently I should have thought that this actually didn't need to be spelled out at all, and that anyone with enough sense to use them would have had enough sense to assume this as a matter of course. But since the laundry list of rights and the myriad ways they could be abused is so lengthy, probably best to spell out the principle, and let the community decide the specifics, For example, is it an abuse of auto-patrolled if an editor doesn't unreview their own paid article creation? I don't know that we've ever needed to answer that question, but we might at some point. GMGtalk 10:59, 2 November 2017 (UTC)
Actually, after thinking my way through a hot shower:
  1. It may be better to say No one may use abuse advanced user rights...
  2. I realize most autopatrolled users probably can't unreview their own article in the first place, because they probably don't have NPP. Which adds another layer of hypothetical problems.
  3. It's not entirely clear that pieces of the admin kit that non-admins may also have should be on the one hand, specially covered for sysops, or on the other, specially exempted for non-sysops. GMGtalk 11:10, 2 November 2017 (UTC)
  • No to allow use of "community granted tools in exchange for money" - for all the obvious reasons. Yes to policies that disallow it.Atsme📞📧 11:56, 2 November 2017 (UTC)
  • An even more perverse variant of this problem crops up periodically at AFC. An author/submitter of a declined (or deleted) draft is contacted off-wiki by someone who claims they will approve (or undelete) the page for payment. This practice of holding a page (draft or mainspace article) to ransom has been condemned as a form of extortion. There is a standing request that all such incidents be reported to WMF Legal. Roger (Dodger67) (talk) 12:07, 2 November 2017 (UTC)
  • NO - No one should be paid this way. This smacks of bribery. ←Baseball Bugs What's up, Doc? carrots→ 12:15, 2 November 2017 (UTC)
  • No- this is a horrible idea. Reyk YO! 12:21, 2 November 2017 (UTC)
  • I'd like to be clear that the question here is quite different from "Can an editor simultaneously be a paid editor and have access to certain user rights, so long as they do not overlap those roles?" ~ Rob13Talk 14:12, 2 November 2017 (UTC)
    • I'd planned on commenting on this today and it was closed before I could. Rob makes a good point, and I think it is worth clarifying if there are circumstances when being paid is incompatible with a role: the only thing I feel somewhat strongly about in this regard as an absolute no is the autopatrolled flag since it's impossible to turn off for only paid articles. Other areas I do think need clearer guidelines as well, and I think this is a first step in the direction of setting up those guidelines. Obviously this is a nuanced topic where there are strong opinions on both sides by the community, and I think further discussion (if not on this question then on other questions) is needed. TonyBallioni (talk) 14:24, 2 November 2017 (UTC)
    • (+1) to Rob's queries.But, primarily this discussion has in itself stemmed from an overlap.I have requested CPower678 to vacate their close.Winged Blades of GodricOn leave 14:40, 2 November 2017 (UTC)
      • The close is fine, mostly because the question as posed was wrong. The question is "should volunteers in roles of trust be allowed to use their tools for money?" The answer is a snow no, which is obvious. There is quite a separate question of whether volunteers can both hold roles of trust and separately be paid. For instance, should Wikipedians-in-residence be able to be admins? That is a very nuanced issue that would need a very different discussion. We can't have that discussion when it starts with such a flawed question. ~ Rob13Talk 14:59, 2 November 2017 (UTC)
At least to my mind, one of the more intuitive ways to go with this is that if you have an account with basically any userrights other than extended confirmed or autopatrolled, and you want to do disclosed paid editing, then you need to register a separate account for the sake of propriety. GMGtalk 15:11, 2 November 2017 (UTC)
As to off wiki access like OTRS, that's a blanket no from me. It can't be separated technically, since access is granted to a person, and not to an account, and it has comparatively little oversight. Probably similarly with CU since they have access to private information, possibly also ACC, and being part of ArbCom is right out. (Jesus this list gets long fast.) GMGtalk 15:14, 2 November 2017 (UTC)
(edit conflict) The WiR issue in particular is complex because while generally a wonderful program it has caused issues in the past (I think I'm thinking of one WiR who copied compatibly licensed advocacy pieces into en.wiki about 6 months back). That being said, having worked with Doc James on PAID issues several times, he typically is not referring to individuals employed by orgs that share the WMF's mission and values (the WiR program or similar), but to those who are paid to edit commercially.
This could be spelled out better, I agree, but I don't think the question is fundamentally flawed: establishing a principle that people agree on has value, even if it is only a very basic one. That gives a starting point for agreement for any future conversations on the issue, which as Rob rightly point out will be nuanced out of necessity. TonyBallioni (talk) 15:17, 2 November 2017 (UTC)
The UNESCO fellow? GMGtalk 15:20, 2 November 2017 (UTC)
That's the one I was thinking of. TonyBallioni (talk) 15:25, 2 November 2017 (UTC)
Rob, the question, flawed or not, concluded with "or should we have policies clearly disallowing this.". The close failed to address that adequately, or explain why it was overlooking it. I agree with your other sentiments, and a close thus explained would have been fine. -- Begoon 15:28, 2 November 2017 (UTC)
  • No since this is open again, the answer to the question asked is clearly no. I also disagree with Rob that this is a flawed question, and think we can set out some general best practices here for the less complex cases that will make the more complex cases easier to deal with when the time comes to have conversations on those issues (call it the baby-steps approach if you want). These are the policy things I think are fairly easy to deal with:
  1. No one should use a position of community trust to solicit payment for services rendered on Wikipedia.
  2. No one should use any user rights or positions of trust to advocate for their clients or to make technical changes that would not otherwise be possible if they did not have the rights (i.e. an admin undeleting a page or a page mover skipping the RM process for a controversial move over a redirect, etc.)
  3. Technical permissions, use of tools requiring a checklist, and positions of trust that involve new content cannot be used to evade our normal scrutiny system for new content and COI content.
I think these three principles are things most people can get behind, and can help be the policy basis for any guidelines on how to apply the principles that Doc James is asking about. There are obviously others that might be able to be agreed upon as well and questions that can be raised regarding these points, but I think they would provide a basis for future discussions on the more nuanced and complex cases. TonyBallioni (talk) 15:42, 2 November 2017 (UTC)
  • Comment I've seen questions raised about whether buying access to admin capabilities is really a big deal. Yes, it is. Look at the number of admins whose talk pages are filled with begging from conflicted editors whose articles were deleted. Won't spell this out due to BEANS but the possibility for a rent-seeking admin with access to deleted revisions are obvious. Also, very few people know about this, but I've communicated privately my evidence-based concern about at least one other CU confirmed socking account that was trying to gain access in 2015 to OTRS. There are good reasons to believe the socking was undisclosed paid/advocacy editing-related as is often the case. This is a big deal since OTRS handles all kinds of private, confidential information that could lead to WP:OUTING at the very least.
If you can't tell I'm leaning very hard towards "no" on the question, but want to see some refinement of the terms before making a commitment. Behavior that even smells of rent-seeking and bureaucratic malfeasance, aka bribery, could be another piece in the puzzle that results in the end of this worthwhile project. ☆ Bri (talk) 17:35, 2 November 2017 (UTC)
  • Yes? I think Anythingyouwant sort of addresses my viewpoint. There's an unmet need in the economy for moving drafts through AfC and getting images approved at OTRS. I would never want to turn either of those processes into pay-for-play and perhaps that's what the opposition is scared of. The fact is, volunteers do a poor job of meeting our various backlogs. Wikipedians edit where they find satisfaction and avoid the drudgery that's needed to keep our maintenance effort going. So long as editors divulge their payments per ToU, I don't see the problem. I don't think money is universally corrupting. I'd like to see our hard-working Wikipedians get paid for their work, and I'd love if some of our most-talented Wikipedians could make a living off of editing just as we're happy to see our favorite YouTubers be able to focus full time on their content work. Disclosure is the sunshine treatment that prevents corrupt activity. If the WMF would stop spending money on un-asked for coding projects and started on-going investigations for business promotion (among other problems) I think introducing a pay mechanism would help us refine product. I know I've enjoyed getting paid to edit; sadly there aren't many reasonable opportunities anymore. Chris Troutman (talk) 21:42, 4 November 2017 (UTC)
  • Hell no and props to Doc James for raising this issue. Support a common-sense prohibition. Coretheapple (talk) 17:14, 5 November 2017 (UTC)
  • NO in the strongest possible terms - This does not conform to the spirit of the encyclopedia. - Knowledgekid87 (talk) 16:19, 6 November 2017 (UTC)
  • Once again, we have a proposal that would, whether intentionally or not, stop or hinder Wikimedians in Residence in their valuable work. "Should Wikipedians be allowed to use community granted tools in exchange for money?" What, like when I use my account creator status to set up accounts for attendees at an editathon I'm running, as a paid WiR, even thought it was given to me for that purpose? I mustn't move an article that one of my trainees creates? I mustn't use AWB, or rollback, or mark an edit as patrolled, in my WiR role? "No one should use a position of community trust to solicit payment for services rendered on Wikipedia." So, when I apply for a paid WiR role, I mustn't mention my experience as a Wikimedian? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:28, 24 November 2017 (UTC)
Usage of ACC right for editathons etc. and WIR does not fall under the purview of this discussion. Winged Blades Godric 15:05, 24 November 2017 (UTC)
  • No - it seems I inadvertently said this twice; see my comments below under Kudpung's proposal. Ivanvector (Talk/Edits) 15:51, 4 December 2017 (UTC)
  • No--Ozzie10aaaa (talk) 16:09, 16 January 2018 (UTC)

We just need acceptable wording and a place to put it

I agreed with the now retracted close. This is a "snow no" to allowing people to use positions of trust and tools for personal enrichment. There are many cases covered here, mainly at AfC, OTRS, and admins, so we need to refine the wording and place it in the right policies. I say policies in the plural because paid editors routinely ignore guidelines and because OTRS is regulated on enWiki by Wikipedia:Global rights policy, admins are regulated at WP:Admins (specifically at WP:Involved}, whereas AfC reviewing is not regulated by any policy that I know of, only by Wikipedia:WikiProject Articles for creation.

I suggest similar wording for all the above, based on User:TonyBallioni's wording just above. Once we get the wording to almost everybody's liking, then place it for an RfC at WP:GRP and WP:Admin. I'll be bold and start the discussion at Wikipedia:WikiProject Articles for creation soon myself.

Basic wording:

No editor may use a position of trust or any user rights to:

  • solicit payment for services to be rendered on Wikipedia, or
  • accept payment for the use of such a position or rights
    • for the benefit a client
    • for advocating for a client, or
    • to evade our normal scrutiny system for new content and COI content.

Payments and grants made by the Wikimedia Foundation or its affiliates (e.g. chapters) are excepted.

Please see AfC and the related talk page. Smallbones(smalltalk) 18:38, 2 November 2017 (UTC)
  • Support since it is based on my wording above, see my reasoning there. I would also extend this to NPP/the NPR flag as well as AfC because that is what gives a user the ability to mark a page for indexing by Google. This wording should cover that, but I did want to mention it explicitly in my support. TonyBallioni (talk) 18:40, 2 November 2017 (UTC)
  • Support as initial wording, without prejudice to editing or improving as with any policy. This seems concise, reasonable, and easy to understand. Everything a policy needs to be. --Jayron32 19:04, 2 November 2017 (UTC)
  • Comment How would this apply to Wikipedians in residence (i.e. people who edit on behalf of universities, libraries, and museums). I personally know someone who was paid by a museum to help write articles on 100 notable New Zealand craft artists as part of a GLAM project. It seems like the wording used here could be made to apply to that project as well. "any user rights" seems ambiguous. I am extendedconfirmed, does that count as a 'user right' in this context? Does that mean that autoconfirmed users are not allowed to use the perks of that 'user right' (i.e. creating articles) to create articles for pay? Or is this meant to only apply to user rights that are community granted (i.e. page mover, rollback). — Insertcleverphrasehere (or here) 19:53, 2 November 2017 (UTC)
    • It'd be pretty simple to deal with WiR's would create distinct accounts, which they do anyway normally, and in most cases, I would expect the accounts wouldn't have additional flags. Autoconfirmed isn't a flag but an implicit group that is determined every time a user action is attempted. Extended confirmed is a flag, but it is automatically granted, so I'd assume we'd use common sense and treat it the same as autoconfirmed. TonyBallioni (talk) 20:23, 2 November 2017 (UTC)
  • Comment I agree with ICPH any paid editor (disclosed or otherwise), any wikipedian in residence that uses an autoconfirmed user right to create a page or even just to edit is in breech of this text; Wikipedia:User right is redirected to WP:User access levels and ALL user groups have right attached to them. Domdeparis (talk) 20:08, 2 November 2017 (UTC)
  • Those creating articles for pay are to go through AfC. Doc James (talk · contribs · email) 20:18, 2 November 2017 (UTC)
  • As I mentioned above, autoconfirmed is not a user right. It is a test that the software does automatically when any action is attempted. TonyBallioni (talk) 20:23, 2 November 2017 (UTC)
You might be right about autoconfirmed. — Insertcleverphrasehere (or here) 21:36, 2 November 2017 (UTC)
Insertcleverphrasehere: yes, this is made clearer in Special:UserRights. See yours here. It lists autoconfirmed as an implicit membership rather than a membership. Its just a software check. From the admin side of it, we can't revoke autoconfirmed status once it has been achieved (there is no tick box for it, and removing the confirmed tick box on the rare occasions that flag is granted does nothing once someone meets the software requirements). TonyBallioni (talk) 21:44, 2 November 2017 (UTC)
  • Support Doc James (talk · contribs · email) 20:18, 2 November 2017 (UTC)
  • I definitely support a prohibition such as this. I would suggest that the way to distinguish someone like a Wikipedian in residence etc. from what we want to prohibit, is that the prohibited conduct occurs when there is a quid pro quo in exchange for something that would not be approved if it were out in the open. --Tryptofish (talk) 20:21, 2 November 2017 (UTC)
    • Tryptofish, WiRs who have distinct accounts for their work as a WiR would be in compliance with the user permissions part of this since that role account would not have additional permissions. We do want to prohibit a WiR who is also an OTRS agent (or hell, hypothetical future arbcom member) from using that position to somehow advance the cause of the org they are being paid by just as much as we'd want to prevent those paid for commercial purposes. The WiR program is good but we also need to recognize that some of them do have a COI on advocacy issues, and that the same principles apply to them as well. I think the overwhelming majority would not abuse it, but I don't want to exempt them completely. TonyBallioni (talk) 20:29, 2 November 2017 (UTC)
      • I agree with what you say. I didn't mean to make it sound like I was saying that there should be anything special about WiR, but I see now that it sounded that way. What I meant was distinguishing acceptable from unacceptable conduct. And I think that what defines unacceptable is (i) a quid pro quo and (ii) a result that would have been opposed by the community if it had happened out in the open. --Tryptofish (talk) 20:34, 2 November 2017 (UTC)
  • Comment - I don't know if this is exactly the right wording, someone can probably improve upon it, but I would suggest going with something more like No editor may use advanced user rights requiring community trust.... Auto confirmed and Extended confirmed are both user rights, but they're not really an expression of community trust, and they're not really a user right in any meaningful sense that we are talking about now. As for the rest of it, if we did have a user with advanced rights go out for WiR, I think it would be totally appropriate for them to either request their rights be temporarily removed, or register a disclosed second account, especially as it concerns auto-patrolled and sysop. I don't really see a reason why a WiR would need to be active at places like NPP or AfC anyway. GMGtalk 20:24, 2 November 2017 (UTC)
I'd support this proposed change in the wording (which I believe was the original and understood intent of the version proposed above). I propose that we amend the proposal to this new wording, and then continue the voting. — Insertcleverphrasehere (or here) 22:11, 2 November 2017 (UTC)
If we are going to change it lets just come out and add normal editing by autoconfirmed or extended confirmed users is not considered use of permissions for these purposes or something like so we don't get into quibbling as to what an advanced permission is or which ones require community trust. TonyBallioni (talk) 22:19, 2 November 2017 (UTC)
Umm... I think I actually disagree on one point. I think the purpose is kindof to be intentionally vague to some extent, and let the community decide the specifics in an actual situation. GMGtalk 22:30, 2 November 2017 (UTC)
Not all forms of advanced editing privileges requiring community trust are backed by user rights. I wouldn't want FAC coordinators accepting money to get commissioned articles on the Main Page, for instance. MER-C 12:57, 3 November 2017 (UTC)
Ah ha! Now this is actually a very good point indeed! There are actually quite a bit of coordinator type positions that have nothing to do with a user right in the software but could be just a easily used improperly and in many cases with greater effect. This should probably be covered here somehow. GMGtalk 14:12, 3 November 2017 (UTC)
  • Oppose for now. I'm 100% in support of the sentiment here, but I still think the wording is a little vague. For instance, last year I spent some time in a paid WIR position. I registered a separate account, and made it clear that I would not be using any of my admin/functionary access for anything related to my work as a WIR. I kept the separation going to the point of CSD tagging old userspace drafts rather than deleting them myself. I did not make a secret of the fact that I was an administrator before taking the job, and I suppose that an overzealous individual could say that by making this clear I was trading my 'authority' as an admin and trusted user in exchange for a job? I am also not sure what problem this instruction creep is going to solve, as in the KDS4444 situation the user was quickly evicted from OTRS once their conduct was discovered without the need for a policy change. This does have the smell of security theatre about it. Lankiveil (speak to me) 02:17, 3 November 2017 (UTC).
    • Wikipedians are not the only audience for this policy. This creates a policy we can point to when reporting spammers to freelance job sites and/or in OTRS tickets regarding commissioned articles. MER-C 12:52, 3 November 2017 (UTC)
  • No editor may use a position of trust... may be overly broad. If you were going to legitimately hire someone to make non-promotional edits, you'd want to engage someone who was trusted by the community. Conversely, if an editor is going to provide copy-writing services, the community should prefer someone who is trusted to follow policies, guidelines, and best practices, versus someone who has failed to be proven trustworthy. isaacl (talk) 03:05, 3 November 2017 (UTC)
  • Support in principle. Wording wise, I suggest something like "Editors with advanced editing privileges requiring community trust must not solicit or accept payments for using said privileges to advocate for or on behalf of a client or circumvent normal editorial processes regarding new and COI content". As for placement, why not put it in WP:PAID as well? MER-C 12:52, 3 November 2017 (UTC)
  • Comment Personally I would go even further and require that any advanced user right cannot be *held or granted* if you are engaged in or offering any commercial or otherwise paid service related to Wikipedia. The inherent conflict of interest that receiving money for services engages means that its too much of a risk. Only in death does duty end (talk) 17:14, 3 November 2017 (UTC)
  • Support, with wording to be refined, particularly regarding acceptable exceptions. And yes, per Only in death, no advanced right or permission should be granted or allowed to paid editors. Justlettersandnumbers (talk) 20:24, 3 November 2017 (UTC)
    I don't see that working generically for practical reasons. The GLAMwikitoolset right has been given to GLAM and Wikimedia Chapter employees for their "official" user accounts in order to manage donations of image archives to Wikimedia Commons and in some cases to run bot-generated reports (with granted bot flag) to support reuse on Wikipedias. They were being paid to do the work, and there is no reason to waste valuable unpaid volunteer time when projects like these are run transparently. -- (talk) 22:56, 3 November 2017 (UTC)
    @: minor questions. a) Is this being run to make edits on enWiki? b) is this right covered at WP:GRP? c) does my proposed wording below make your objection mute? Smallbones(smalltalk) 16:30, 4 November 2017 (UTC)
, what I said in my first short sentence above ("wording to be refined, particularly regarding acceptable exceptions") should be taken as applying also to what I said in the second sentence. Also, what happens on Commons happens on Commons; my opinion expressed here on Wikipedia relates specifically to this project. Justlettersandnumbers (talk) 18:43, 5 November 2017 (UTC)
  • Oppose. I'm ok with the principal, but what is meant by "any user rights"? That seems overly broad. The wording makes it sound as if anything you can do as a user - create new articles, edit, revert, etc - would fall under this. The wording needs to better reflect what rights are at issue. - Bilby (talk) 08:14, 4 November 2017 (UTC)
  • Oppose. The suggestion is that "payment for service" is automatically harming the encyclopedia, that is just suspicion, it's possible to be paid for doing good work, it's also possible for an admin to put their responsibilities to the community last or first, paid is not proof of a problem, it's only proof that we don't trust them. The heart of the issue isn't WHY the editor, or admin might be acting against the community, only that there is a problem with what they actually did. So lets be focused on behavior not mistrust. Dougmcdonell (talk) 19:17, 4 November 2017 (UTC)
Prohibition statements etc. in policies/guidelines oalmost always reflect upon the behaviour of common folks, not that of the outliers.Though, if you had choosen to oppose, because you think, that there's no problem in any editor soliciting payment(s) from potential customers through OTRS channels (as long as the worth the article he/she later churns out is satisfactory) or somebody self-patrolling his own paid creations, despite the elements of obvious cognitive bias or some sysop restoring articles, declining CSDs, closing AfDs in lieu of payments, it's another case.Winged Blades of GodricOn leave 14:05, 5 November 2017 (UTC)
  • Oppose I think Wikipedians should always be able to solicit "payment for services to be rendered on Wikipedia". Chris Troutman (talk) 21:46, 4 November 2017 (UTC)
  • Support long overdue. Coretheapple (talk) 17:16, 5 November 2017 (UTC)
  • Support in principle and most specifics; I prefer the slight modification in the next subsection. It's concise, non-bureaucratic, and consistent with the general community take on these matters. We know there'll be some paid/COI editing, and consensus implemented policy about it. This just closes a loophole.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  00:23, 11 November 2017 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── With very few exceptions there are no opposes here based on principle. We're just arguing about wording (and where to put that wording). Within the limits of my available time, I'll keep coming back to this. There are several places to put this, and I think several are needed since advanced rights are covered in several places. Progress so far:

Other discussions, with possible wording changes, will have to be held at WP:GRP (for ORTS) and WP:Admin. I don't expect any opposition at WP:GRP, and will start that discussion on Monday. My suggestion for wording follow. I'm just adding a line on Wikipedians in residence, but please note that the "who" in the 1st line will change based on where the policy is proposed. Once everything is done, we can then summarize the changes at WP:Paid.

  • I don't get it. As far as I can tell, using any bit in exchange for money is already disallowed so outlining rules for it just makes it easier to game. Anyone misusing any bit is subject to having that bit removed. Doing it for pay is clearly misusing it. There really is no question about it. Any admin unblocking for cash would be dragged to Arb and bit stripped, for instance. No one would oppose that. A new rule is superfluous. Dennis Brown - 20:14, 18 November 2017 (UTC)
  • @Dennis Brown, the TOU—even in the brave new world of the WMF crackdown—aren't as clear-cut as you think, and there are still quite a few loopholes. Show me where in policy it's forbidden for an admin to profit from their access to deleted revisions, for instance—and that's something that does have commercial potential, there are ad-funded websites that literally do nothing but host deleted Wikipedia articles (Deletionpedia is the best-known). ‑ Iridescent 20:23, 18 November 2017 (UTC)
  • As long as policy is based on consensus and consensus is overwhelmingly against selling use of the bits, then it seems obvious to me. If I find any admin using any bit for gain, I won't hesitate to block them, for example. I don't need a specific policy statement, WP:COMMONSENSE covers it well, as bits are based on trust that they will be used only to benefit Wikipedia. Any use of the bit to gain advantage, be it financial, in an edit war, or otherwise, is grounds to lose the bit. Any bit. The community has already said this by providing a vetting system for all the bits, and policies on use of each of the bits. Anyone that doesn't understand that shouldn't have advanced bits, as the reason we have them is to benefit the encyclopedia, not ourselves. I'm afraid once you start setting specific rules, you start creating loopholes. As it is now, ANY misuse of any kind, even those we can't think of ahead of time, is grounds to lose the bit. I truly feel we codify too much that is already covered by common sense, and that is part of the problem with the contradictory maze of policies we have. Dennis Brown - 01:35, 19 November 2017 (UTC)
  • Without a policy to back it up, the odds of a desysop from arbcom are negligible. Sure we could go the community ban route that we went with within the last few days for an OTRS agent, but that would also lead to the inevitable arbcom case. TonyBallioni (talk) 01:45, 19 November 2017 (UTC)
  • I have a bit of a counter-proposal to this, which is that rather than setting out prohibitions for paid editing activities, we should merely set out a very tightly limited list of what paid editors can do, and specify that any action not on that list is prohibited. The list would be something like, following disclosure of having been paid, adding reliably sourced information to a draft, or proposing on an article talk page that content be added or changed. If that is the complete list, then obviously things like unearthing deleted edit histories would be outside the scope. bd2412 T 20:28, 18 November 2017 (UTC)
    • As the United States discovered when it tried to ban alcohol, it is very difficult to regulate that which you prohibit, and I think your proposal comes so close to prohibition that the same principle will apply. If you make the rules too onerous, then at some point paid editors will just not disclose their paid status. I'm sure this already happens, and probably quite a bit, but it will get worse. WP:OUTING is written so strongly (too strongly IMO, but that's a separate discussion) that enforcement will be very difficult. --Trovatore (talk) 21:14, 18 November 2017 (UTC)
  • Support this or a similar version. Gandydancer (talk) 04:33, 24 November 2017 (UTC)
  • Support in principle. I don't like this wording -- for example, I don't know whether the limitation of the circumstances under which accepting payment is prohibited also apply to soliciting payment. More importantly, the access to non-public or privileged information described by User:GreenMeansGo in his boxed text above is missing. While admins getting a pass for articles about Mzoli's or something is mildly disturbing, I'm far more alarmed (for example) by the prospect that the Turkish government could call up an admin and say that their sockpuppet about to start a big argument with a Gulenist and they'd like to see the admin indef them both. Or that they could use the block to goad the editor into emailing a user or accessing a custom document to give away his IP, or simply get SPI access if they have it. We are wording this policy to fight nuisances, but we need to look at the serious threats above all. Mercs hiring themselves out to hurt our editors under color of etiquette. Wnt (talk) 16:07, 2 January 2018 (UTC)
  • support--Ozzie10aaaa (talk) 16:12, 16 January 2018 (UTC)

break

New basic wording:

No editor may use a position of trust or advanced user rights to:

  • solicit payment for services to be rendered on Wikipedia, or
  • accept payment for the use of such a position or rights
    • for the benefit a client
    • for advocating for a client, or
    • to evade our normal scrutiny system for new content and COI content.

Payments and grants made by the Wikimedia Foundation or its affiliates (e.g. chapters) are excepted. Wikipedians-in-Residence should declare their paid status and their paid use of advanced rights, but are otherwise exempt.

Smallbones(smalltalk) 16:30, 4 November 2017 (UTC)

This is an improvement, but I'm still a little uncomfortable with the word "solicit", which I think could potentially cover a wider range of scenarios than what is intended. Am I correct in assuming the intended effect of that clause is to stop people using OTRS and other WMF-sponsored tools for finding work? Lankiveil (speak to me) 02:30, 5 November 2017 (UTC).
Examples where "solicit" may come into play: Orangemoody-type advertising via email, i.e. Pay me to write your article and I'll make sure it sticks because I'm an admin, b) ads on Fiverr "You can pay me to write your article, and I'm an admin". One place that it wouldn't come into play is with Wikipedians-in-Residence because they "are otherwise exempt." I have no problem with a potential WiR saying to a respectable GLAM "BTW I also volunteer at OTRS" because GLAMs are aligned with our aims, and because I think GLAM folks (on- and off-Wiki) would police the activity themselves. I trust librarians!. Smallbones(smalltalk) 04:20, 5 November 2017 (UTC)
Can the scope of "position of trust" be narrowed? What roles that do not require advanced user rights are being targeted? For example, is a co-ordinator of WikiProject Military history, an elected position, considered a position of trust for the purpose of this proposed guidance? How about the Today's featured article co-ordinators? Teahouse hosts? isaacl (talk) 18:26, 5 November 2017 (UTC)
Sorry for my absence here, real-world obligations catch up sometimes. The answer to @Isaacl:'s question is most that there are many places where the rules for different positions and user rights are set out. I believe that each place needs input from the folks that hang out there and that the exact wording for each position can be worked out, In short, it'll be narrowed by doing one position at a time, and by the people involved. That's not to say that folks here can't be involved at those pages as well. So far:
  • small change already made at WP:AFC, with no opposition
  • small change at WP:COI reflecting the AfC change
  • an interesting discussion at WT:Good articles
  • I'll start a discussion very soon at WT:GRP (which covers OTRS and other rights)
Smallbones(smalltalk) 16:47, 8 November 2017 (UTC)
Can you list some examples of roles that would be covered which do not have associated advanced user rights? This would help me consider what type of wording may be appropriate. Personally, I do not think just being trusted by the community should be in itself a disqualifying factor, even though trusted editors inherently have a greater influence on discussions than those who aren't trusted. isaacl (talk) 17:00, 8 November 2017 (UTC)
My main concern is with holders of advanced rights who use their status, rather than the rights per se for paid editing, e.g. OTRS "volunteers" who might come on to enWiki (their rights, if we call them that are used elsewhere) and post something on a talk page, e.g. "From an OTRS ticket, I'm removing .... until a better source can be found." Or say an admin !voting at ANI. That's not exactly using their tools - it's a use of their position or status.
As far as "trusted positions" without tools - the only ones that concern me at all are AfC reviewer (this seems to have been taken care of) and Good Article reviewer (which is still being discussed). Others may be concerned about different positions - but let them make the proposals. As far as the elected director of WP:Military history - I just don't know enough about it - but I doubt that he'd win an election if he declared that he was willing to sell his services as the director. Smallbones(smalltalk) 17:49, 8 November 2017 (UTC)
FA coordinator and the ArbCom election commission have been mentioned above. GMGtalk 17:56, 8 November 2017 (UTC)
Perhaps it would be better to cast the restriction (for editors without advanced user rights) in terms of the type of services offered: the commonality seems to be decisions that are entrusted to one or a small number of persons, or the evaluation of the community's consensus view. So maybe something like this:
  • No editor with advanced user rights may solicit or accept payment for any service related to Wikipedia. Examples of services include advocating for a client, or evading scrutiny for any edits benefiting a client.
  • No editor may solicit or accept payment for any service related to evaluating the Wikipedia community's consensus view, or to deciding on an outcome either as an individual or within a committee, as opposed to part of a community discussion. Examples of outcomes include decisions made by the feature article co-ordinators, and rulings made by the Arbitration Committee election commission.
Further examples of course can be listed. isaacl (talk) 18:35, 8 November 2017 (UTC)
  • Prefer this version to the one in the above section, since it deals with the "coordinators" matter. I do think the admin, CU, etc. policies need to be updated with explicit rules again using such special power/tools/authority on behalf of off-site interests. It really doesn't have anything to do with money changing hands but with PoV, COI, and NOT#ADVOCACY policy.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  00:24, 11 November 2017 (UTC); revised: 12:34, 29 November 2017 (UTC)
  • I've made the relevant additions to New Page Patrol: [1][2]. MER-C 09:33, 22 November 2017 (UTC)

(radical?) counterproposal

Instead of running away and pretending we can stop editing (hint - I've only seen reports and instances of paid editing increase since the change in the ToS from my OTRS work), why don't we almost create a "trusted editor" system - editors that are trusted by the community are added to a page, can be contacted by external editors, and if the subject is indeed notable, the page can be created by them for either a charge or a donation to the WMF? (something a bit like WP:JOB but better publicised) Paid editing is clearly not going to go away - as I see it, we can have a choice where both us (with better paid-for articles, so less NPP needed), and the subjects (article less likely to get deleted, less likely to be scammed). I'm aware this does present a potential COI flag over the foundation, but as it is independent editors carrying out the editing, I don't see this as an issue.

Note: I'm not involved in paid editing, I just regularly dealt with the fall out from it. The current approach clearly isn't working IMO - maybe a shift in our approach may well get better results. Mdann52 (talk) 22:50, 3 November 2017 (UTC)

Those hiring paid editors are often looking for promotional rather than neutral content. The problem is growing as we become more well known and respected and the businesses that do this work increase in number. The rise of sites like Elance and Fivver also contribute. Doc James (talk · contribs · email) 07:18, 4 November 2017 (UTC)
@Doc James: True - however, I think if we are going to keep our head into the sands that this issue can be solved with our current approach, promotional content is going to become more widely available. I think that trialing different approaches to see what impact they make would be at least vaguely worthwhile. Mdann52 (talk) 17:01, 5 November 2017 (UTC)
Our current approach appears to be 1) some pretending the problem does not exist or if it does it does not matter 2) a small group trying very hard to keep our rules against paid editing from being applied and try to do everything possible to prevent any new rules from being created to regulate the practice or enforce our TOU.
So it is not surprising we are here. We do need to try things, but I would like to suggest we try enforcing our current rules or ban paid promotional editing directly in article space completely. Doc James (talk · contribs · email) 04:41, 6 November 2017 (UTC)
  • @Godric on Leave: I can see the parallels there, but that seemed to be far more about money from the WMF rather than subjects. I'm under no illusion this proposal is not going to get any real levels of support - sometimes, I think it's best to throw radical proposals out there to get people thinking, as in my time on Wikipedia, towing the same line has only seen the problem get worse... Mdann52 (talk) 17:05, 5 November 2017 (UTC)
  • Hi all! My opinion is simply disallowing those types of paied contributions because especially OTRs members as will as admins should be of the most confident users and represent the idea of volunteering for wikipedia and if we allow them to be paied for their contributions then wikipedia will become like any paid website and will lost its main principle of free knowledge. Those paied users are more prone to bias than those who are freely volunteering and sacrificing there efforts and time!. Regards--مصعب (talk) 11:18, 4 November 2017 (UTC)
This isn't going to happen.
  • @مصعب: There are a few editors involved with Wikipedia who are paid for their work and tend to produce high-quality articles - I'm of the opinion that paid editors != bad editors as a general rule - hence why I'd rather it was members of the community being paid for writing articles outside their comfort areas, rather than unknown people writing paid promotional content. Mdann52 (talk) 17:01, 5 November 2017 (UTC)
  • Just no TonyBallioni (talk) 13:13, 4 November 2017 (UTC)
  • Hell no! - it would be reputational suicide. --Orange Mike | Talk 20:58, 4 November 2017 (UTC)
  • Heck no! - some people get carried away! Smallbones(smalltalk) 21:44, 4 November 2017 (UTC)
  • Absolutely no . This is even worse than the error that was made in the first place by allowing paid editing under the condition of disclosure. No form of paid editing is compatible with the volunteer philosophy of Wikipedia.Kudpung กุดผึ้ง (talk) 03:36, 6 November 2017 (UTC)
  • Hahaha Worth imagining just so that in my mind I can see the look on the WMF's face if we tried to turn the platform into a donation machine through community consensus... In all seriousness though: not gonna happen. — Insertcleverphrasehere (or here) 12:31, 6 November 2017 (UTC)
  • @Insertcleverphrasehere: Evidently, you've never been on Wikipedia around December while logged out for the annual fundraising drive... :P Mdann52 (talk) 22:12, 6 November 2017 (UTC)
  • Presses nuke button - Seriously though, it is a good idea but per above wishful thinking. - Knowledgekid87 (talk) 16:24, 6 November 2017 (UTC)
  • No. Such a web site would be possible, and might be no worse than the commercial world already is, but whoever wants to run it, can and must do so entirely independently from WP or the WMF, and I do not think anyone could ethically participate in both. The problem is that our copyright permits anyone to use our material, and then add commercialism onto it, but we always knew that's inherent in the license. Personally I sometimes think we should have chosen -NC, but we didn't. DGG ( talk ) 19:14, 20 November 2017 (UTC)
  • No Absolutely not. Bad idea. Qaei 10:17, 3 January 2018 (UTC)

History - people with privileges who edited for pay

Several folks have asked if this has ever happened. I've been spending a bit of time looking at that...

apparent sock (listed at SPI): Homechap (talk · contribs · deleted contribs · logs · edit filter log · block user · block log)
apparent sock (listed in Arbcom decision June 2009): Zithan (talk · contribs · deleted contribs · logs · edit filter log · block user · block log)
crat, oversighter, admin, OTRS.
per edit count first edit in 2004.
status, Zithan blocked; other accounts not blocked, Nichalp retired; last edit on en-WP was Jan 2009 (left enigmatic note here 31 Jan 2009).
Made a 'crat here in September 2005 ; stripped by arbcom here June 2009.
joined OTRS here October 2007; removed from list here July 2009 with edit note No longer active(!)
June 2009 SPI filed and was put on hold for Arbcom, Arbcom finding is here
btw this from July 2008 looks a lot like trying to figure out how to cover their socking tracks after a goof, using the tools.
The arbcom decision spawned a long discussion at the related talk page here.
Led to a slew of AfDs eg linked from Wikipedia:Articles for deletion/Brad Sugars
Led to a mammoth RfC that ran June-July 2009 Wikipedia:Requests_for_comment/Paid_editing
admin
Status. not blocked. Still an admin. not too active per edit count, last edit was Feb 2017
per edit count, created in 2006
diff, June 2009 acknowledged editing for pay; explained here on 11 June that they work for a university and I only add content or modify content with information that is sourced directly from our publications and web-sites, or from accompanying articles.. That diff says that they gave up the bit and they did but they asked for it back in Nov 2009 log)
admin
sock of account formerly called Mrinal Pandey, renamed to Empengent (talk · contribs · deleted contribs · logs · edit filter log · block user · block log)
See SPI Wikipedia:Sockpuppet_investigations/Mrinal_Pandey/Archive (I had never looked at that before. Wow)
arbcom case Feb 2015; desysopped and banned for socking and editing for pay on behalf of a university, Indian Institute of Planning and Management
Master account (edit count) created Dec 2006
Wifione account (per edit count) created April 2009.
user rights log, made admin Sept 2010.
OTRS, autopatrol
status, indeffed Nov 2017)
OTRS (removed Oct 2017)

--(That is what I found so far. Jytdog (talk) 18:31, 18 November 2017 (UTC))

admin
Currently editing for pay through "Mister Wiki"

— (added by JJMC89(T·C) 18:56, 19 November 2017 (UTC))

New Page Patroller
Systematically marked as patrolled new pages created by one of the big UPE sockfarms.

-- added by Rentier (talk) 19:27, 19 November 2017 (UTC))

AFC reviewer
Does work for "Mister Wiki".

- (added by Jytdog (talk) 22:54, 19 November 2017 (UTC))

Other history

Had never seen this list before. Back in 2009 already somebody was tracking ads for paid editing on Elance. See User:Brumski/paid_editing_adverts. Jytdog (talk) 18:31, 18 November 2017 (UTC)

Rather than putting this list on the village pump page, how about including it somewhere under Wikipedia:WikiProject Integrity, such as a subpage of Wikipedia:WikiProject Integrity/Editor Registry, so it can more easily located again in future and kept up-to-date? isaacl (talk) 20:07, 19 November 2017 (UTC)

As I noted at the top, people in the RfC discussion asked about other people with advanced privileges (PWAPs ??) who edited for pay and I wanted to make it easy for folks participating to see. But yes it should be copied to the Integrity page. Jytdog (talk) 21:17, 19 November 2017 (UTC)
You guys should probably take care to separate your own sigs from the list of editors in the section above. ☆ Bri (talk) 00:31, 21 November 2017 (UTC)
thx, added notations and smallified. :) Jytdog (talk) 02:40, 28 November 2017 (UTC)

Current developments

In view of the current case (which is going to be accepted) at Wikipedia:Arbitration/Requests/Case#Mister_Wiki concerning an admin, the entire proposal should be reworded as:

The holding of advanced rights is incompatible with paid editing

Even if a user with advanced rights creates creates another identity for his/her paid editing (such as user:Salvidrim!), it just creates yet another perceived degree of tolerance for paid editing - and its still the same person. No one can claim to successfully manage a voluntary split personality. Kudpung กุดผึ้ง (talk) 01:01, 26 November 2017 (UTC)

  • I didn't realize this discussion was happening here, I had been commenting on the case request. I'll just basically expand on what I said there: I think that it would be a very good idea if we made users choose between holding advanced permissions or being paid to edit. To my mind it's pretty simple: if you want to accept payment for doing something on Wikipedia, you first go to WP:BN and say "I've been hired to do a thing, please remove all of my userrights" (yes, rollback and everything, right down to autoconfirmed). Maybe we should require that you describe the work you're being paid to do, or post a link to the request on Fiverr or wherever, that seems like a good idea for transparency. Then you go do your paid gig, making proper disclosures along the way, and once you're done you go back to BN and say "my paid gig is done, please give me back my userrights". Then, obviously, you don't touch that topic again. It's all done from one account so you're accountable for it, and nobody is prevented from doing paid editing if that's a thing they want to do. And if you're being paid to "manage" content on an ongoing basis, you shouldn't be entitled to any advanced permissions.
As for Pigsonthewing's concern about Wikipedians in Residence, I think it stands to reason that being paid to promote Wikipedia and facilitate outreach events is somewhat different from being paid to edit Wikipedia on behalf of a third party. The WiR program is already pretty transparent, and clearly valuable. Ivanvector (Talk/Edits) 15:43, 29 November 2017 (UTC)
  • I think this would be a very bad idea. There are far too many grey areas and corner cases and times where this would harm the encyclopaedia (making it much harder for someone to revert vandalism they happen across) - not to mention that it would encourage people with rights greater than autoconfirmed to lie about any paid editing making the problem worse rather than better. We will either lose many good editors and admins because of technical violations or the rules will be inconsistently enforced making much more of a mess than we currently have. Thryduulf (talk) 17:15, 11 December 2017 (UTC)
Support the principle that The holding of advanced rights is incompatible with paid editing. I'm not sure that lesser rights than admin really need to be covered, but it does no great harm and keeps it simple. Anything in excess of auto-confirmed rights should be covered.
And this seems to me to be consistent with the direction ARBCOM has taken. When I became an admin, the principle seemed to be that I'd be under greater scrutiny when exercising "the mop", but that's now been extended to every edit an admin makes. We should be consistent, and apply this principle to all advanced rights and positions.
But please note I'm not advocating enforcement as a solution. The spirit of wp:5P5 as I see it is, whenever we need to enforce the rules, they have in a sense already failed. The goal should be to write the rules, and build consensus supporting them, so that enforcement is rarely necessary, and so that the cases where sanctions are needed stick out like sore thumbs, because users that are here try to follow the rules whether they agree with them or not. Andrewa (talk) 22:01, 20 December 2017 (UTC)
Support Kudpung's proposal that "The holding of advanced rights is incompatible with paid editing". Once money enters the scene the motivation for every action is questionable. In Salvidrim's case, granting rights to the alternate account is (imho) indistinguishable from sockpuppetry. Regardless of the outcome at Arbcom Salvidrim's credibility and impartiality is shot. How can an admin, who accepts payment under another hat, give fair judgement on other paid editors?
A bright-line rule as proposed by Kudpung would leave no room for ambiguity or doubt, and leave no grey area for anybody to stumble into. The restriction needs to be applicable not only to Admins but to Page Movers (for suppressredirect) and Template Editors (for the ability to duck the title blacklist) at the very least. Cabayi (talk) 18:31, 23 December 2017 (UTC)
Not in this form. With the way the question is being framed so far, the proposed solution is missing the aim. The problem underlying all the situations that have been discussed so far is not the fact itself that payments have been made, it is the introduction of a conflict of interest subsequent to these payments. It is the conflicts of interest that we should strive to find ways of tackling, regardless of their form (and there are myriads ways for this to happen: personally, I think the existence of visible edit counts acts as a much stronger disincentive to keep wikipedia's purpose in mind than all the harmful money you could pump into the project). Directly or indirectly receiving payment for any forms of editing (with or without the exercising of advanced rights) can happen in a variety of situations that do not involve such conflicts of interest. How about wikipedians in residence, WMF staff or WikiEdu coordinators, should they be banned from using any advanced tools? Is it wrong for the organisers of a big student editathon to hire a wikipedian to clean up the resultant mess? Is it wrong for a user to start a crowdfunding campaign among her friends so that she can dedicate a month of her time to helping clear the AfC backlog? – Uanfala (talk) 19:27, 24 December 2017 (UTC)
  • Comment Hopefully Jimbo will make some sort of statement about the detrimental effect of these issues, along with the detrimental effect of "contributors who are very productive but also very rude to others" and other major problems that undermine the pillars of Wikipedia. Bright☀ 09:22, 10 January 2018 (UTC)

RfC on naming of Chinese railway line articles

How should the titles of railway line articles for Mainland China and the high-speed railway in Hong Kong be named? Jc86035 (talk) 09:29, 11 November 2017 (UTC)

Background (naming of Chinese railway line articles)

Most article titles for Chinese railway lines follow the structure "Place 1Place 2 Railway" or similar, though they have been inconsistently named and the naming guideline is probably a reflection of the state of articles rather than a fully consensus-based system. However, Dicklyon has recently renamed or made RMs for a number of railway lines to decapitalize them. (According to this PetScan query, out of about 270 railway lines and former railway companies, 174 are named with "Railway" and 86 are named with "railway". Dicklyon renamed all 86 of the latter this week.) Their naming should be based on reliable sources per MOS. A mix of non-capitalized and capitalized is used by sources for the more well-known high-speed railways, but more than 90% of sources use the capitalized form for the Guangzhou–Shenzhen–Hong Kong Express Rail Link (but a mix when the line is referred to as just the "Express Rail Link" or "express rail link"), and most news articles for the Beijing–Tianjin Intercity Railway use the capitalized form unless they refer to it without the phrase "intercity railway" e.g. "Beijing-Tianjin intercity route". There are very few English-language sources about the slow railways; 3 news sources use "Beijing–Kowloon Railway" and one source uses "Beijing–Kowloon railway", while others use "Beijing–Jiujiang–Kowloon [Rr]ailway". (Almost all passenger and freight lines in China are operated by China Railway and its subsidiaries, so it would probably be odd to capitalize them differently entirely based on the inconsistent capitalization of sources.) Further investigation is probably needed.

In addition, some articles are named in their abbreviated form, using only one Chinese character from each place name (e.g. Guangshen Railway instead of Guangzhou–Shenzhen Railway). Sources about high-speed lines usually use the long form. Most news articles about the Guangzhou–Shenzhen [Rr]ailway are actually about the subsidiary of China Railway which operates it, which is named with the abbreviated form. (The railway itself seems to never be in the news.) Most Google results for "Jingjiu railway" [Beijing–Kowloon] are Wikipedia articles; sources generally use the long forms. There is some old discussion in the archives of Wikipedia talk:Naming conventions (Chinese) which indicates that the long form should be used for clarity, although the highways also addressed by the naming convention have always been named using the short form (e.g. Guangshen Expressway).

Some articles are also named "Passenger Railway" instead of "High-Speed Railway". This is a result of the official Chinese names being literally translated; most English-language sources avoid "passenger railway" probably for clarity, although it's also possible that they used Wikipedia's article titles.

Note that my observation is probably incomplete and more web searches will be needed.

A B C
Should the railway line articles be named with a capitalized "Railway"? 1 capitalized not case-by-case (i.e. based entirely on sources)
Should the railway line articles be named with the short or long form? 2 short long case-by-case
Should the railway line articles be named high-speed railway or passenger railway? 3 high-speed passenger case-by-case
Should the railway line articles be named intercity railway or passenger railway? 4 intercity passenger case-by-case
Should closed/historical/heritage/narrow-gauge railway line articles (e.g. Gebishi Railway, Jiayang Coal Railway) be named the same way as open railway lines operated by China Railway? 5 yes no case-by-case
Should the current and former railway company articles be renamed to match the line articles? 6 yes no case-by-case
How should railway lines with termini in Tibet and Xinjiang etc. be named? 7 Mandarin-derived name local name case-by-case

Survey (naming of Chinese railway line articles)

  • 1B, 2B, 3A, 4A, 5C, 6B and 7C. (I am the RfC initiator.) Jc86035 (talk) 09:38, 11 November 2017 (UTC)
    See WP:JUSTAVOTE; why do you support those options?  — SMcCandlish ¢ >ʌⱷ҅ʌ<  13:31, 11 November 2017 (UTC)
    @SMcCandlish:
    • I am the initiator so my reasoning for 1B and 2B is largely outlined in the section above.
    • This needs to be double-checked, but 3A and 4A are sorted this way because the Chinese government seems to officially name high-speed lines "客运专线" (literally, "passenger dedicated line"). Some Chinese Wikipedia articles are named that way; others use "高速铁路" ("high-speed railway"). I don't know why. I have corrected "passenger line" to "passenger railway" since it is probably an editor's translation of the same phrase.
    • I !voted 5C since heritage railways may or may not be state-owned and thus may be named using a different system. Similarly, the name may be translated differently.
    • I !voted 6B since the company name does not need to be the same as and has little to do with the railway name; it would be a little like renaming c2c because the railway it operates on isn't called the c2c railway. The only operator for which this applies is Guangshen Railway (company), and the company is publicly listed internationally so it has an official English name which we don't need to change. The other operator [with an article] is Daqin Railway (company), which operates over multiple lines which are mostly not named the Daqin Railway. To be honest, this doesn't actually have much to do with the rest of the RfC, so maybe it could be removed.
    • I !voted 7B since the Chinese government apparently has an tendency to pretend that ethnic groups in the autonomous regions don't exist and only installs English-language signage based on the Mandarin Chinese transliteration rather than signage based on the Tibetan or Uyghur names. I've changed my preference to 7C.
    Jc86035 (talk) 15:30, 11 November 2017 (UTC)
  • Remove WP:NC-CHINA#Transport as a bunch of no-consensus WP:CREEP – do not expand it further with this stuff. Not only does it directly conflict with site-wide guidelines like MOS:CAPS and WP:NCCAPS, it is not actually addressing anything unique to China and is thus off-topic – just one wikiproject PoV-pushing a bunch of trivial nit-picks without consensus. I checked – there was no discussion at WT:NC-CHINA about adding any of that material, and it's just someone's opinion, i.e. a mis-placed WP:PROJPAGE essay. It's also unnecessary (as I demonstrate below), because we already have title and sourcing policies, basic naming conventions, and style guides that result in usable article names simply by following them. I'm a huge fan of consistency within reason, but this RfC is just ridiculous. In case this nonsense is kept, I've answered the RfC questions below, with actual rationales, based on site-wide rules and advice.
Details, by number:

1B, 2C (2B by default), 3C (3A by default), 4C (4A by default), 5C (5A by default), 6C (6A by default), 7C (7A by default).
Reasons:

  1. 1A is not actually an option (per MOS:CAPS, WP:NCCAPS, WP:NOR).
  2. 2C (2B by default) because these are usually descriptive names, in translation, so should be descriptive, but in the case that one is a proper name, use that.
  3. 3C per follow the sources; the choice doesn't even make sense, since "high-speed" and "passenger" are not synonyms and there are passenger lines that are not high-speed; if the railway is high-speed, use that by default as more descriptive.
  4. 4C (4A by default) per follow the souces; the choice the nom offers is another false equivalence, as there are passenger lines that are not intercity; for an intercity case, that word is more descriptive; but use whatever a proper name actually translates as.
  5. 5C (5A by default) per WP:CONSISTENCY policy, with allowance for a [translation or transliteration of a] proper name that doesn't fit the format.
  6. 6C (6A by default) per WP:CONSISTENCY and because not doing it (absent unusual proper name exceptions) invalidates the whole point of the RfC to settle on a consistent naming convention. It's utterly baffling that the nominator would pick 6B.
  7. 7C (7A by default) per COMMONNAME and follow the sources.

Important note: "I saw it on a sign" does not equate to "proper name"; signs are primary sources self-published by the agency in question, and are written in an intentionally compressed fashion; they are not natural English. And the agency's own publication cannot be used to "style-war" for overcapitalization or other quirks, since WP doesn't follow external house style of random other organizations, and these names aren't in English anyway.

This kind of instruction creep is problematic, because if even a few topical-interest wikiprojects did something like this, MoS page by MoS page as WP:TRAINS has been trying to do, then a page like MOS:CHINA would be so long no one would read or follow anything in it. We should have no MoS rules other than those that address points of style and usage that editors have repeatedly had raucous conflicts about (or which address internal, usually technical, requirements) and which are not adquately addressed by existing WP:P&G pages. MoS/AT material is not a style guide for the public but an internal problem-solving tool. Every new rule added that isn't actually needed is just a reduction in editorial leeway and pisses people off.
 — SMcCandlish ¢ >ʌⱷ҅ʌ<  13:31, 11 November 2017 (UTC)
@SMcCandlish: The last discussion about railways at Wikipedia talk:Naming conventions (Chinese) was more than six years ago. There probably aren't enough active editors to form a consensus, other than through the RM process (which probably isn't as widely trafficked as this page). I agree that some of these didn't really need to be in the RfC, but it made sense to ask them all at the same time to have a sort of more solid precedent than a RM from 2009 which ended in no consensus. It's a bit of a stretch to say that building consensus on these things is "instruction creep" and "ridiculous", since these are all (well, 1 to 5, anyway) points of inconsistency between article titles which no discussion has managed to sort out in the last decade.
I am also proposing this independent of the guideline and do not really care whether or not the guideline is changed to reflect it; I should have clarified this. I am fine with removing the guideline's section, since it only serves to reflect the status quo and has its own problems like introducing infobox title inconsistencies. Jc86035 (talk) 15:30, 11 November 2017 (UTC)
It's actually worse than that; it's a WP:POLICYFORK that contradicts the main guidelines on capitalization, among other problems.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  15:36, 11 November 2017 (UTC)
@SMcCandlish: Would it be acceptable to notify the Chinese Wikipedia of this RfC, or would that be canvassing? Jc86035 (talk) 04:28, 13 November 2017 (UTC)
I wouldn't. This doesn't have anything to do with what's done in Chinese, and zh.WP doesn't share our style guide.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  05:10, 13 November 2017 (UTC)
  • Mixing style guidelines with naming conventions1B usually, since we have site-wide consensus represented in WP:NCCAPS and MOS:CAPS to reserve caps for proper names, typically as determined by consistent capitalization in sources, and these are pretty mixed in sources as nom notes. No new guideline or instruction is neeeded; see my RFC a few sections up where nobody disagrees with following these central guidelines. For the rest, these are more like project naming conventions; I agree there are some consistency improvements that would be useful. In terms of the current state, I started with downcasing "XXX High-Speed Railway", and then "XXX Intercity Railway" after studying sources about those. I would plan to look next at "XXX Passenger Railway" and plain "XXX Railway". In many parts of the world, the latter form is typically referring to a company, and is capped, while the railway infrastructure is called a "line". So I need to look at what's going on here. Any help you care to offer will be appreciated. Dicklyon (talk) 17:02, 11 November 2017 (UTC)

Comment It is a proper name in Chinese and just lost in translation in English and by grammar it should be capitalised (the Chinese government had a system to name it, does not mean it is not a proper name, such as the First Bridge of "Long River", the Frist Road of People, or People East/West/North/South Road. Or Shenzhen Airport. Beijing International Airport. Matthew_hk tc 03:24, 13 November 2017 (UTC)

@Matthew hk: I don't think this is necessarily the case, as English grammar norms are a little different from those of Chinese. For example, the zhwiki article for Shenzhen is called 深圳市 (Shenzhen City), but our article is titled simply Shenzhen because we don't consider "City" to be part of the proper name and it's not necessary for disambiguation. Jc86035 (talk) 04:28, 13 November 2017 (UTC)
Yep.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  05:10, 13 November 2017 (UTC)
What I saw is wikipedia screw with no sense that Australia use English language and capitalize Fremantle Line [3] in their webpage and the wiki lower cap them. Matthew_hk tc 06:06, 13 November 2017 (UTC)
Yes, we "screw with" some of their styling, since they're not even consistent (see [4]) and since we go by secondary sources. Dicklyon (talk) 06:35, 13 November 2017 (UTC)
And more citation on Chinese railway: Hsü, Immanuel C.Y. The Rise of Modern China. Oxford University Press. , a history book written in English (by a guy with Chinese surname publish by a reputable university press) use Wade–Giles, uses Peking-Hankow Railway, Canton-Hankow Railway Matthew_hk tc 06:46, 13 November 2017 (UTC)
He also has "Fengtien-Peking and Tientsin-Pukow railways", which would seem unlikely if their proper names were Fengtien-Peking Railway and Tientsin-Pukow Railway. Things like "Southern Manchurian Railway track" that he has make more sense, as referring probably to the company South Manchuria Railway Company as opposed to the line. Anyway, he has a style, but it's not WP style. Dicklyon (talk) 03:16, 6 December 2017 (UTC)
Here I will comment that there is no such thing as a "South Manchuria railway" as a single line. The South Manchuria Railway operated a number of lines, of which none were called the "South Manchuria Line". For the record, they were called the Lianjing Line (Dalian–Xinjing/Changchun), the Anfeng Line (Andong/Dandong–Fengtian/Shenyang), and the Jincheng Line (Jinzhou–Chengzitong).2Q (talk) 03:35, 19 December 2017 (UTC)

Comment: If we in proper English capitalise "Hollywood Boulevard" or "Fifth Avenue" or "Crescent City" or "Brooklyn Bridge", then these cases of railways wherein 'Line' is part of the proper name need to be capitalised too. Though I'm thinking more specifically of Korea and Japan, but applicable elsewhere too, including China. Secondly, there are/were numerous railway lines in Hamgyeong Province, or in the Tohoku region ... saying "Hamgyeong line" (or "Tohoku line" etc) is not specifically referring to any of said lines, whereas "Hamgyeong Line" ("Tohoku Line" etc) is specifically referring to the one line that is commonly known by that name.

I know in China railway lines are called 鐵路 (railway) and not 線 (line), but I'd say the same thing applies. Proper names are capitalised, this is a basic and universal rule of English orthography. 2Q (talk) 02:04, 27 November 2017 (UTC)

  • Avoid instruction creep. (Basically "C" in all cases above [where not in conflict with MOS:CAPS, etc.].) WP guidelines aren't for us to neatly order the lamentably inconsistent real world; they are created as a last resort to help editors focus on improving articles rather than waste time endlessly bickering about small things without resolution. Here, I don't see a long-standing ongoing conflict that needs some WP guideline to come down and make decisions for us. Especially in this RfC, where we are asked to !vote on a list of different rules for different small sub-subjects. This requires anyone commenting get detailed knowledge for each separate issue, which an RfC is the worst way to achieve. I'd close this RfC as a bad idea no matter what the outcome. (Maybe start a separate RfC for each issue where needed.) --A D Monroe III(talk) 16:12, 30 November 2017 (UTC)

Korea exception?

Is Korea different from China? I started downcasing a few lines in Korea, but got reverted by 2Q. See discussion at User talk:Dicklyon#Undid page moves. The argument seems to be that since Korean and maybe other Asian languages have no analog of capitalization, and even though there's not consistent capping in English-language sources, we must nevertheless treat these line names as proper names. Anyone buy that? Dicklyon (talk) 03:31, 29 November 2017 (UTC)

Not on your life; the fact that CJK scripts have no case distinction means we absolutely should use lower-case here because our translations of them are just approximations and thus cannot be their proper names. We have the same rule when it comes to translating titles of published works: the translations go in sentence case. (However, the English-language title of an English-language edition of a book, or English-dubbed/subtitled English-language-market release of a film, or traditional English name of a famous artwork, goes in title case.)  — SMcCandlish ¢ >ʌⱷ҅ʌ<  13:31, 29 November 2017 (UTC)
I don't see how the Korean language has any influence here. Per COMMMONNAME, The naming we follow is based on English, not uses in other languages; we don't call Germany Deutschland. If English sources cap it, then we should, especially when the native official language has no caps. I'm sure the French Wikipedia doesn't look to English sources to determine if "Basketball" is a masculine or feminine noun, a concept English doesn't have. --A D Monroe III(talk) 15:39, 30 November 2017 (UTC)

In User_talk:Dicklyon#South_Manchuria_Railway, User:2Q makes a case for capping "Line" for Japan and Korea lines. It makes more sense than I've seen elsewhere (more than for the NYC subway lines, for instance). Comments? Dicklyon (talk) 06:06, 17 December 2017 (UTC)

US or NYC exception?

There is also some pushback on capitalization normalization of "Line" in New York, in spite of sources using lowercase a lot. See ongoing RM discussion at Talk:IRT_Lexington_Avenue_Line#Requested_move_17_November_2017. The notification of the project has brought in some local opposition based on their longstanding practice of capping "Line". Dicklyon (talk) 16:30, 29 November 2017 (UTC)

Hong Kong exception?

I've downcased the majority of Chinese XXX Railway articles, and working away on them; a few seem to be consistently capped in sources, and a few have a little pushback for other reasons (2Q also comments on some of those). But it's when I mess with things that get into Hong Kong that I find more pushback, especially on downcasing Station (e.g. see Wikipedia_talk:WikiProject_Hong_Kong#Railway_and_Station_capitalization and User_talk:Dicklyon#Why_are_you_even_allowed_admin_tools?). And I continue to get random comments from the banned/sock Russia anon for my work there, sprinkled into some of these conversations. I'm going to hold off on Japan and Korea, go slow on Hong Kong, and see how things go as I try to finish up China. Comments? Dicklyon (talk) 06:06, 17 December 2017 (UTC)

On the Hong Kong MTR stations, I've opened a mulit-RM discussion: Talk:Hung_Hom_Station#Requested_move_17_December_2017. Dicklyon (talk) 16:55, 17 December 2017 (UTC)

Strong opposition and motion for reconsideration

As the creator or editor of the vast majority of China railway articles in English Wikipedia, I am appalled and deeply dismayed that this de-capitalization exercise was undertaken with little to no input from the editors who are familiar with the content of this subject area and laid down the conventions for article in naming, as a means to help readers identify the articles they are reading and editors to help expand the subject area.

First, the naming convention which I proposed and was adopted in 2011 after significant discussion with other China railway editors, has worked. See Archive 11 (reproduced below). Until Dickylyon started de-capitalizing high-speed railway names, virtually all articles about particular railways in China had "railway" capitalized in the same way that Great Western Railway, Trans-Siberian Railway and Union Pacific Railroad have railway/railroad capitalized in their names. The capitalization signifies that the article name is referring to a particular railway, and the names of particular railways are proper nouns. Per MOS:CAPS, proper nouns are capitalized.

This section is weirdly broken and not editable, having sections inside the collapsed part. How about a link to the relevant archive instead? And did these proposals ever get adopted or documented any place, or just discussed? Dicklyon (talk) 05:16, 20 December 2017 (UTC)
And trying to edit sections after this also doesn't work so well; the edit button usually leads to the wrong section number. Dicklyon (talk) 05:53, 20 December 2017 (UTC)
I think I've fixed the problem. Someone say if that's not true. - dcljr (talk) 05:48, 3 January 2018 (UTC)
The 2011 discussion and consenus
For article names of Chinese railways, replace transliterated shorthand names with hyphenated full names

Under the current naming convention, Wikipedia English article names of Chinese railways (and expressways) follow the shorthand Chinese character names for these railways (and expressways) transliterated into English. For example, the Beijing-Shanghai Railway is named Jinghu Railway, after the shorthand of the Chinese name for this railway, 京沪铁路. Jing is the pinyin tranliteration for 京, the character used in Chinese as a shorthand for the city of Beijing. Hu is the pinyin transliteration for 沪, the character used in Chinese as a shorthand for the city of Shanghai. Beijing and Shanghai are the two terminal cities on the railway.

For ease of reference, let’s call Jinghu Railway the “transliterated shorthand name” and the Beijing-Shanghai Railway, the “hyphenated full name”. The transliterated shorthand name, while seemingly faithful to the Chinese naming method, is not helpful or effective for most English Wikipedia readers and fails to satisfy most of the objectives under Wikipedia’s article naming convention, which are recognizability, naturalness, precision, conciseness and consistency. This naming convention should be replaced by hyphenated full names of Chinese railways, which has the two terminal location references (usually cities but also could be provinces) of each railway fully spelled out and connected by a hyphen. This hyphenated name should be followed by “Railway”, capitalized because the name of each Chinese railway is a proper noun. The transliterated shorthand name could be mentioned in the article and could have a redirect link, but should not be the primary article name – for the following reasons:

Recognizabilityan ideal title will confirm, to readers who are familiar with (though not necessarily expert in) the topic, that the article is indeed about that topic. The names of most railways in China, regardless of naming method, are not familiar or recognizable to most English Wikipedia readers. When this is the case, the more descriptive name will make the railway more identifiable. For example, most English readers are unfamiliar with, say, the railway between Chengdu and Chongqing, but between Chengyu Railway and the Chengdu-Chongqing Railway, they’re much more likely to identify the latter as the railway between the two cities.

As of April 22, 2011, articles for only a handful of railways in China have been created and named with the transliterated shorthand name method. Most of these articles are for railways that many bilingual (Chinese and English) readers can recognize, such as the Jinghu, Jingguang, Jingjiu, Jingbao Railway, so the naming convention appears to be fine. Yet, once we expand the article coverage to railways that are less well-known, recognizability of names will diminish. Railways like the Funen, Kuybei, Qibei, Nenlin, are likely to be as obscure to the English reader as they are to the bilingual reader. As the number of articles proliferates, the article names will become progressively more difficult to recognize and tell apart. Try telling apart the following railways: Fuhuai, Fuxia and Funen.

Part of the difficulty is that the transliteration method obscures differences in Chinese characters and Chinese tones that help to pick apart some of those names, such as 阜淮, 福厦, 富嫩 in the riddle above. Compared to the shorthand names, Fuxin-Huainan, Fuzhou-Xiamen, and Fuyu-Nenjiang, are more recognizable. With pinyin transliteration from Chinese to English, considerable detail and discerning information is lost. Consider more examples:

  • Xiangyu, Xianggui, Xiangpu Railways all have different “Xiang” characters;
  • Baolan and Baocheng Railways have different “Bao” characters;
  • Jiaoji and Jitong Railways have different “Ji” characters;
  • Jiaoji and Jiaoliu Railways have different “Jiao” characters
  • Jitong and Tongpu Lines have different “Tong” characters;
  • Lanxin and Lanyan Lines have different “Lan” characters;
  • Qibei and Ningqi Lines have different “Qi” characters;
  • Tongjiu, Tongpu, Jitong Railways have different “Tong” characters
  • Xianggui and Guikun Lines have different “Gui” characters;
  • Yiwan and Wangan Railways have different “Wan” characters;
  • Yiwan, Yijia, and Xinyi Lines have different “Yi” characters;
  • Yuli and Licha Railways have different “Li” characters;

Many English readers may be unfamiliar with one-character abbreviations of Chinese cities and provinces that are commonly used in Chinese shorthand names for railways, Hu for Shanghai, Yu for Chongqing, Rong for Chengdu, Ning for Nanjing, Yong for Ningbo and Jiu for Kowloon. Compare Beijing-Kowloon Railway with Jingjiu Railway. Just when you thought Jing stood for Beijing, there is Jingsha Railway, between Jingmen and Shashi in Hubei Province.

Part of the difficulty is that the Chinese method itself is vulnerable to confusion due to the repetition of the same characters used to describe different location. Consider Changda (长大), Xinchang (新长), and Daqin (大秦) railways. These three lines have two pairs of Chang and Da characters in common but those two characters refer to four different cities: Changchun, Changxing, Dalian and Datong. When these homographs characters are transliterated into the English, the confusion they cause is compounded by their homophone characters. Joining the Da (大) railways, e.g. Daqin (大秦) and Dazheng (大郑), are the Da (达) railways – Dacheng (达成) Dawan (达万) Railway. Joining Chang (长) railways are other Changs such as (昌), as in the Changjiu (昌九) Railway.

Naturalnessrefers to the names and terms that readers are most likely to look for in order to find the article (and to which editors will most naturally link from other articles). How are the names of Chinese railways referred to in English publications? A search in the English news articles for Beijing-Shanghai Railway yields hundreds of results. A search for Jinghu Railway yields few to no results. In everyday use, when an English writer wants to identify a Chinese railway in English prose to an English reading audience, he/she is much more likely to use the hyphenated full name approach than the transliterated shorthand name approach.

Precisiontitles are expected to use names and terms that are precise, but only as precise as is necessary to identify the topic of the article unambiguously. Not surprisingly, the hyphenated full name is more precise and less prone to confusion than the transliterated shorthand name. For example, does Xinyi Railway refer to the railway between Fuxin and Yi County (新义铁路) or the railway of Xinyi (新沂铁路), which goes to Changxing? What about the Ningwu Railway, is it one of the railways that originates from Ningwu or the Nanjing-Wuhu Railway, whose transliterated shorthand is also Ningwu?

Concisenessshorter titles are generally preferred to longer ones. This is the only consideration where the transliterated shorthand name appears to have the edge. But this objective is far outweighed by others consideration. The hyphenated full name is hardly long by Wikipedia article name standards. Furthermore, as a rule, in Wikipedia, we do not use abbreviations as article names. Why adopt Chinese abbreviations as the official English names?

Consistency - titles which follow the same pattern as those of similar articles are generally preferred. As noted, news articles about railways overwhelmingly follow the hyphenated full name approach. Among China’s high-speed railways, the majority also following the hyphenated full-name approach, because this approach delivers more identifying information and is less prone to confusion.

It’s time to make the English article names of Chinese railways consistent, clear and descriptive. The need for hyphenated full names for Chinese railways is more pressing than it is for Chinese highways. Whereas railway names are stable, highways in China frequently have their names changed as expressways are lengthened and numbering systems are adopted. As an encyclopedia, we want to present seemingly complex information to readers in a way that is clear and consistent and easy to understand and follow. Under the hyphenated full name approach, readers can tell right away, what the two terminal cities of any railway are, and if they can recognize one of the two cities, be able to orient the railway. They will be able to tell that the Nanjing-Xian (Ningxi), Nanjing-Wuhu (Ningwu) and Nanjing-Qidong (Ningqi) Railways do not originate from the same city as the Ningwu-Kelan (Ningke) and Ningwu-Jingle (Ningjing) Railways.

For consistency and clarity, Wikipedia article names of Chinese railways should always feature the full names. In-article references can use transliterated shorthand names. The only exception may be the Longhai Line, which has become a two-character word in itself. The reason for this lengthy argument is because prior attempts to convert transliterated shorthand article names into hyphenated full names have been reversed with reference to the naming convention. ContinentalAve (talk) 15:14, 22 April 2011 (UTC)

I will refuse to agree to anything regarding railways unless something is done to expressways as well. Since expressways follow about the same convention, with the only conceivable difference being the addition of the "G__" numbering system, it makes little sense to have 2 separate conventions. Also, I am pretty sure that you fell for the pitfall of not using " " (i.e. exact phrasing) when doing Google searches. HSR, since they have been built only recently, are mentioned using the Terminus 1-Terminus 2 format in most media sources.
And with regards to "most English Wikipedia readers"... that's not the most important issue to be considered here, and probably should not be one. Precision far eclipses recognisability; you pointed this out. Full transliteration often creates disambiguation. --HXL's Roundtable and Record 00:15, 23 April 2011 (UTC)
HXL:Appreciate your prompt response.
Regarding the highway naming convention: Sure, we can certainly adopt the same full-name approach for highways. i.e. G12 Hunchun-Ulanhot Expressway instead of G12 Hunwu Expressway.
Regarding the Google searches: the point here is that more English writers use the full-name approach than the transliterated shorthand approach because the former is more natural. This is true whether we are talking newly built HSRs or longstanding regular speed railways. A search for "Beijing-Shanghai Railway" (in quotes) yields 269,000 results on Google, whereas "Jinghu Railway" (in quotes) yields only 77,000. The "Baotou-Lanzhou Railway" has 16,100 results and "Baolan Railway" has only 1,010 results.
Regarding most "English Wikipedia readers": I would not dismiss them so readily from our consideration of naming conventions. Wikipedia exists for their and our use. Two criteria in Wikipedia's naming convention -- recognizability and naturalness -- are based on the reader's experience. While it is true that many of the railway and expressways in China are currently unfamiliar to English readers (and therefore not recognizable to them), Wikipedia can help to change that through the creation of articles about them. This is why it is important for the names of these articles to be helpful, descriptive and memorable. Over time, many of the railways and expressways in China will become more recognizable. How we name them can have quite a lot to do with how quickly they gain acceptance.
Precision versus Recognizability: If I read your last point sentence correctly -- Full transliteration often creates disambiguation. -- then you're in agreement with me that using the full-names of these railways and highways creates less ambiguity than the shorthand names, not just often, but almost always.
Thank you for your attention. ContinentalAve (talk) 14:36, 23 April 2011 (UTC)
To be clear, it is not that I am necessarily opposed to the proposal, but I am concerned about some of the wording of the rationale. Indeed, I will come out and say that full spelling is required in all cases where ambiguation with even one terminus is possible (i.e. Nanjing). --HXL's Roundtable and Record 14:52, 23 April 2011 (UTC)

I am fairly neutral on the proposal; but, as one data point, there were 455 results when searching on "beijing-hankou railway" on Google Books; 26 and 35 results when searching on "jing-han railway" and "jinghan railway", respectively. (Among them, there must have been a few "pseudobooks", created by a parasitic publisher from Wikipedia pages; but the number was small enough as not to affect the overall results significantly. There were also a few hits with "chinghan", "beiping-hankow", etc., but again to few too affect the overall ratios). -- Vmenkov (talk) 15:50, 23 April 2011 (UTC)

I broadly support this. I am far from proficient in Chinese but recognise many place names, including most cities. But the short names really make no sense to me, i.e. on encountering them I would need to look for the longer full name to understand what is being referred to. I suspect only those proficient in Chinese would recognise the short names, and such people are unlikely to be using the English Wikipedia as a reference for the Chinese railway system. It seems that broader usage agrees with this, based on the searches done. There will still be redirects for those that are searching by the short names, but the full names are more appropriate for the article titles.--JohnBlackburnewordsdeeds 16:26, 23 April 2011 (UTC)

I appreciate the helpful input from everyone. HXL, I understand your reluctance to change a long-standing policy but your proposed solution of spelling out the full name only when there is ambiguity with the abbreviated name will prove to be difficult to implement. For one, many writers will not be aware of ambiguities because they haven’t considered the whole galaxy of railway and expressway names. This is why I have gone through the effort of creating a very long post with many examples to illustrate the problem. Only when you consider the Ningwu-based railways will the Nanjing-based railway names seem ambiguous. Second, as we all know, China is undergoing extensive infrastructural expansion and the number of highways and railways will proliferate and create new ambiguities. For example, Hubei and Hunan are building a railway between Jingmen and Yueyang called the Jingyue Railway. The Jingyue along with the Jingsha Railway will start to erode the distinctiveness of Jing for Beijing in English. It will be more and more difficult to tell whether the Jingyuan and Jingzhang Railways are really obscure railways linked to Beijing or somehow related to the Jingyihuo Railway in Xinjiang. If Jing can be made ambiguous, no one is safe. Third, Wikipedia is the place where old knowledge finds new life. Many historical railways in China, like the Jinghan, will have articles created for them. Their inclusion will compound the potential for ambiguity. The earlier we adopt a clear and consistent policy, the less uncertainty and difficulty there will be for article creators going forward. After all, you were the one who opposed bifurcating railways from highways! :P

Set forth below, is my proposal of the revised naming convention for the transportation section:

Transportation

When naming articles of expressways, highways, railways, railway stations, or airports in China, use the common English name if it can be determined, e.g. Karakorum Highway. Otherwise, follow these naming rules for the article name:

For roadways, highways, expressways and railways whose names in Chinese consist of two- or three-character abbreviations of the terminal cities (or other location names), do not adopt the pinyin version of the Chinese abbreviated name as the English article name. Instead, spell out the full English name of each abbreviated Chinese place name and connect them with hyphens in the article name:

For the 宁芜铁路, use Nanjing-Wuhu Railway as the article name not, Ningwu Railway.

The {[full English spelling of terminus 1][hyphen][full English spelling of terminus 2] [Expressway/Railway]} article naming format is intended to identify expressways/railways with precision and avoid ambiguity. E.g. In addition to the Ningwu Railway, there are Ningwu-Kelan and Ningwu-Jingle Railways.

The pinyin version of the Chinese abbreviated name should be mentioned in the first sentence of the article as a secondary name of the expressway/railway, and should be made a redirect link to the article. Furthermore, the pinyin version of the Chinese abbreviated name can be freely used in the article itself and in other articles. The rule above applies only to article names. Where there is ambiguity in the pinyin version of the Chinese abbreviated name, create a disambiguation page for the ambiguous name.

Nanfu Railway may refer to:

Please capitalize Expressway/Railway in the article name.

Railways

Where the pinyin spelling of a place name differs from the official English spelling of the place name (especially in the case of non-Chinese place names) use the official English spelling.

Use the same naming format for China's high-speed railways

Exceptions to hyphenated full-spelling naming format:

Where the Chinese name is descriptive, use a brief translation of the descriptive name:

Where the abbreviations in the Chinese name are no longer considered abbreviations. This usually occurs when the abbreviated name has survived changes in the underlying names.

  • 陇海铁路 - Longhai Railway not Longxi-Haizhou Railway because Longxi is no longer used to describe eastern Gansu Province and Haizhou is now part of Lianyungang
Roadways

For [[5]], add the expressway number as a prefix to the hyphenated expressway name in the article. The prefix and the hyphenated expressway should be separated by a space.

The pinyin version of the Chinese abbreviated name should be mentioned in the first sentence of the article as a secondary name of the expressway and should be made a redirect link to the article.

For National Highways that are numbered simply follow the format {China National Highway [number]}:

National Highways can be abbreviated with "G{no. of highway}", e.g. G105 as a redirect link for China National Highway 105.

Railway Station

Articles for railway stations in China should be named using the city's name (or in some cases the station's unique name— for example, 丰台火车站) followed by the English translation of the cardinal direction in the railway station name, if applicable (North, South etc.), and then [Railway Station]:

Abbreviated forms of the railway station name should be mentioned in the article's first sentence as secondary names and should have redirect links to the article name.

Airports

Airport articles should have the city's name followed by the [airport's name] if applicable, followed by [International Airport] or [Airport] as applicable:

ContinentalAve (talk) 19:01, 23 April 2011 (UTC) Revised ContinentalAve (talk) 08:05, 1 May 2011 (UTC)

I am not opposed to this proposal. Sounds sensible and reasonable for the large readership who doesn't understand the abbreviation used in Chinese. The short names are usually used in mass media. As such, I assume these will be redirects to the full hypenated names. --Visik (Chinwag Podium) 02:31, 29 April 2011 (UTC)
This proposal sounds eminently sensible and generally excellent. Hear hear! Jpatokal (talk) 10:01, 29 April 2011 (UTC)
I agree with the proposal as well. It may be appropriate, however, to explicitly say in the policy that the "two-syllable" names of railways and highway (Jinghu Railway etc) should also be mentioned in the lede of relevant article. -- Vmenkov (talk) 15:11, 29 April 2011 (UTC)
Thank you for everyone's suggestions. I have incorporated your input about the need to mention the Chinese abbreviated name in the first sentence of the article and to have redirect links created for the Chinese abbreviated name. ContinentalAve (talk) 08:05, 1 May 2011 (UTC)
By the way, you probably will need to clarify the new policy a bit once certain ambiguities are found. For one, I am not entirely supportive of reducing "Terminus A–B County" to "Terminus A–B". Secondly, cases where the article title of a terminus (i.e. X City or Y County) is not at X or Y County, respectively, due to the existence of other settlements of the same name, need to be dealt with. With romanisation, the reader cannot always know which "X" or "Y County" is being referred to. To begin with, a solution is to use "X City" in the title if there are no other officially-designated cities of the same name. I don't know about the other 2 cases for now. –HXL's Roundtable and Record 04:51, 13 May 2011 (UTC)
  • Endorse, though of course, some wording needs to be changed. My experience with disambiguating town, township, and subdistrict divisions is frustrating enough; no two counties or county-level cities in mainland China share the same name in Chinese but then when romanising, many counties and county-level cities are "repeated" across provinces when fully romanised. Applying this sentiment here, the precision point alone is enough grounds for me to support the policy change. And sorry for the delayed response; have been busy with what I alluded to above...check my contribs if you wish to know. –HXL's Roundtable and Record 04:44, 13 May 2011 (UTC)
HXL49, thank you for the endorsement, thoughtful reply and questions.
In general, the Terminal A-Terminal B naming method should follow the unabbreviated Chinese place names used to identify the terminals in the name of the railway itself, even if those place names are different from the actual place names currently used to name the places in which the terminal is located. What do I mean?
Generally, there is no difference between the place name used to identify a terminal in the name of the railway and the place name in which the terminal is located. E.g. The Yingtan-Xiamen Railway refers to the railway between Yingtan and Xiamen. However, consider the 临策铁路 Linhe-Ceke Railway. The railway was planned when the eastern terminal city was called Linhe. Linhe has since been renamed Bayan Nur, but the underlying railway name still uses the abbreviation for Linhe 临河. Since we are naming articles of the railways, not the place names, we should adhere to the Chinese place name used in the railway name and maintain Linhe-Ceke Railway, not Bayan Nur-Ceke Railway.
There are instances where the terminals of a railway are not actually located in the place identified in the terminal place name. For example, the Qiqihar-Bei'an Railway begins in the station of Angangxi, near Qiqihar but not in the city itself. Since the railway name uses Qiqihar as the terminal place name, the article name follows with Qiqihar-Bei'an Railway, not Angangxi-Bei'an Railway. In the first paragraph of the article, there should be a clarification of any differences between the location of the actual terminal and the place suggested by the terminal name referenced in the name of the railway.
Consider an opposite example, 南福铁路 Nanping-Fuzhou Railway, was built in 1956 as a branch of the Yingtan-Xiamen Railway. This railway begins in the west at the 外洋 Waiyang Station on the Yingxia Line. Waiyang is located in 来舟 Laizhou, a township of Nanping. Initially, this was the only railway near Nanping and was called the Nanping-Fuzhou Railway. Later as other railways were built into Nanping itself, the line took on 外福铁路 Waiyang-Fuzhou Railway and 来福铁路 Laizhou-Fuzhou Railway as alternate names. In English Wikipedia, an article name has been created for each of the three names. Currently, Waiyang-Fuzhou and Laizhou-Fuzhou redirect to Nanping-Fuzhou because all three names are now considered to be historical names since most of the line has become part of the Hengfeng-Nanping Railway. Nanping-Fuzhou was the first name for the line and remains the most intelligible. The point here is that the article name should follow whichever Chinese place names are used in the Chinese railway name.
Quite a few railway terminals are named after and located in counties. See Ningwu-Jingle Railway. If I understand you correctly, I don't think you are calling for this line to be named Ningwu County-Jingle County Railway, since there is no ambiguity with Ningwu or Jingle. I think the more tricky scenario you alluded to is when one of the terminal names when romanized into English is itself ambiguous. Consider the 新义铁路, which when translated under the general rule, becomes the Fuxin-Yi County Railway. But there are several "Yi Counties" in China, and this could lead to some confusion. I do not see a definite solution, but see several options:
(a) Fuxin-Yi County Railway. Leave it as is. There may be several Yi Counties in China, but only one Fuxin-Yi County Railway. When the reader clicks through, the first sentence of the article should explain which Yi County the railway connects to.
(b) Fuxin-Yi County (Liaoning) Railway. This approach completely disambiguates Yi County.
(c) Fuxin-Yi County Railway (Liaoning). This approach explains that the entire railway is located in Liaoning, which should dispel any ambiguity about which Yi County is being referred to, but might give the misleading impression that there is another Fuxin-Yi County Railway in another province.
I'm indifferent. What do you and others think? ContinentalAve (talk) 08:33, 15 May 2011 (UTC)
Who approved this new change? It was not like this before. Python eggs (talk) 01:49, 3 July 2011 (UTC)
That's the key idea behind "change". You can see through the history that a proposal was put into place back in April and nobody posted any oppositions for the entire two months that the discussion was open. See this section.  –Nav  talk to me or sign my guestbook 01:52, 3 July 2011 (UTC)
Dear Python eggs, on April 24, 2011, shortly after making this proposal, I posted a message on your talk page informing you of this discussion and inviting you to participate. I wanted to give everyone sufficient opportunity to discuss and make inputs and build a consensus before making the agreed to changes two months hence. ContinentalAve (talk) 05:38, 3 July 2011 (UTC)
Okay, I do not oppose (not support either) most names, but names like “Lanzhou–Xinjing Railway” really suck, even the Railways itself use “新建铁路兰州至乌鲁木齐第二双线” when it had to write in the long form. [Comment by User:Python eggs]
Dear Python eggs, can you explain your objection to the name Lanzhou-Xinjiang Railway more clearly? It is difficult for others to tell why you don't like this name. ContinentalAve (talk) 14:57, 4 July 2011 (UTC)
I would like to ask why User:Python eggs reverted some (or most) of my renamings of the articles, which were performed in order to fit with this new convention. Special:Contributions/Python_eggs and Special:Contributions/Heights. I would like to leave a message in light of this new discussion here before moving them back again because it seems some issue has arisen. Heights(Want to talk?) 20:26, 3 July 2011 (UTC)
Also sorry I must point up another issue. From the official chinese names of the high-speed railway lines, most of them are in the format of XY客运专线. Now I am not sure of the exact translation of this but it seems to be "Passenger Dedicated Line" or "Passenger Railway." The problem is even the larger lines which comprises of several smaller lines are also called 客运专线, for example Beijing-Harbin客运专线 encompasses Beijing-Shenyang客运专线, Harbin-Dalian客运专线, Panjin-Yingkou客运专线 (客运专线 used because I don't know what the name is). I made the effort of moving all of the larger lines to a "XY Passenger Dedicated Line" format such as Beijing–Harbin Passenger Dedicated Line and the smaller lines that are part of it, such as the Harbin–Dalian Passenger Railway, in the XY Passenger Railway format. I know this is inconsistent because in Chinese, they are both 客运专线, however one encompasses several smaller 客运专线. User:Python eggs reverted some of these back to XY High-Speed Railway such as Harbin–Dalian High-Speed Railway which I feel is incorrect because the Chinese name is 客运专线, which does roughly translate as "passenger dedicated line." Nowhere in those 4 characters do you see any reference to high-speed, albeit it is high speed. In contrast, the Beijing–Shanghai High-Speed Railway makes sense because in Chinese, the name is 京沪高速铁路, with 高速铁路 specifically meaning "High-Speed Railway Line." This is understandable and makes sense. I understand that Wikipedia is also about recognition and High-Speed would be more recognizable, but can we also come up with a consensus on how to name larger 客运专线s, smaller 客运专线, and 高速铁路, before I start moving articles again. Thank you, Heights(Want to talk?) 20:34, 3 July 2011 (UTC)
Harbin–Dalian High-Speed Railway and others

Can you please explain your rationale for moving Harbin–Dalian Passenger Railway to Harbin–Dalian High-Speed Railway. I moved all of the articles to a X–Y Passenger Railway format in order to maintain consistency. In Chinese, these lines are referred to as 客运专线, which roughly translates as "passenger dedicated line" or "passenger railway" but nowhere do I see the words "High-Speed." In contrast, the Beijing to Shanghai High Speed Railway is correct because in Chinese it is actually named 高速铁路, the words 高速 clearly indicating High-Speed.

Also, explain your rationale for reverting all of my moves for Qinshen Passenger Railway and such. Please take a read at Wikipedia:NC-CHINA#Transportation as the new naming convention is to name the articles with the termini stations, aka Qinhuangdao and Shenyang, not Qinshen.

Please explain your rationale and/or conform to naming conventions set by WP:NC-CHINA. Thank you Heights(Want to talk?) 20:21, 3 July 2011 (UTC)

No. In Chinese, it is controversy. If you search for "哈大高铁" on Google, tons of results will be returned, and many of them from official sites like xinhuanet or gov.cn. Chinese government is switching from "客运专线" to "高速铁路". Python eggs (talk) 03:01, 4 July 2011 (UTC)
I think Python eggs is trying to say that in Chinese official usage, "客运专线" is giving way to "高速铁路". But see [6] using 客运专线 from yesterday's Heilongjiang Economic Daily. It's difficult to create a consensus between "客运专线" and "高速铁路" when these lines are so new and often still not yet in operation. I can't see why one is more correct than the other. Maybe in a few years' time, one description will prevail over the other. ContinentalAve (talk) 14:57, 4 July 2011 (UTC)
Ok, so I am taking this as all of the 客运专线 should be High-Speed Railway? I was just slightly confused because before I moved all of them to Passenger Railway, the Qinshen or Qinhuangdao-Shenyang article was Qinshen Passenger Railway but everything else was High-Speed Railway. I also find government sources and government sanctioned news sources using 客运专线 and also it is weird that Chinese Wikipedia still has everything as 客运专线 Heights(Want to talk?) 00:59, 5 July 2011 (UTC)
I suggest "XXX High-Speed Railway" for all 300+ km/h lines. Recently, all 300+ km/h lines are commonly known as "高速铁路" in China, like 郑西高铁, 武广高铁, 沪杭高铁, 广深港高铁, and etc. The exceptions are Beijing–Tianjin Intercity Railway and Shanghai–Nanjing Intercity High-Speed Railway which is formally referred as "沪宁城际高速铁路". For lines less than 300 km/h, use "XXX Passenger Railway", or simply "XXX Railway" if their no paralleled old railway. (i.e. Hening Railway, Hewu Railway, Wenfu Railway, etc.) [Python eggs]
Python eggs, I think it is premature to enact such a blanket policy on the naming of high-speed railways in China until more consistent usage patterns emerge. Heights was certainly within reason to use passenger railway to describe 客运专线. The 300km/h threshold you propose creates an unclear distinction between high-speed railway and passenger railway (and passenger dedicated line) based on speed of operation, which is not necessarily true. The Wuhan-Guangzhou High-Speed Railway is still being mentioned in some Chinese press articles as the 武广客运专线. Let's wait and see how naming conventions in Chinese evolve before adopting a formal policy. ContinentalAve (talk) 14:39, 7 July 2011 (UTC)

Second, many if not most railways in China are not written about very much in English-language sources, so sources are often limited and trends may not be readily apparent. The authoritative sources such as the rail operator itself China Railways [7], China Railway Construction Corporation Limited, a leading builder of railways in China [8], as well as sources that study or follow Chinese railways closely such as the World Bank [9] and Asia Development Bank [10] tend to capitalize the word “railway”. They do so because this subject area requires greater precision.

Unlike virtually any other part of the world, rail transport in China is unprecedented expansion, with the number of railways, types of railways, railway stations, etc. proliferating rapidly. See High-speed rail in China The new railway assets are often located in the same places as older assets, giving rise to the need for greater precision in the naming of the new assets as well as the older ones.

For example, as of December 2017, there are two railways between Beijing and Shanghai: the Beijing-Shanghai Railway and the Beijing-Shanghai High-Speed Railway. A second Beijing-Shanghai high-speed railway will be built in the next five years. Consider this statement:

I’m traveling on the Beijing-Shanghai railway.

Can you tell that “Beijing-Shanghai railway” is a proper noun and therefore refers to conventional-speed railway between Beijing and Shanghai? Or is this term is referring to any of the railways between Beijing and Shanghai?

The problem is more acute with the names of railway stations. With the boom in railway construction, Chinese cities are adding railway stations. Apart from a handful of exceptions such as Shanghai Hongqiao, most Chinese railway stations are named after the city in which they are located, plus a cardinal direction, to distinguish the first railway station in the city from newer ones. Consider this statement:

The train arrived at the Beijing railway station.

Did the train arrive at the Beijing Railway Station? Or another railway station in Beijing such as Beijing South Railway Station (for now, the city’s principal high-speed rail hub), the Beijing West Railway Station (for now, the busiest railway station in the city), the Beijing North Railway Station (for day trips to the Great Wall), the Beijing East Railway Station (current undergoing expansion to accommodate the expected opening of the Beijing-Shenyang High-Speed Railway)? Or any of the other railway stations in Beijing, such as the Fengtai railway station (which gives rise to another question, the old Fengtai Station or the new one currently under construction)?

This train is running on the Beijing-Zhangjiakou railway heading to the Beijing railway station.
But on which Beijing-Zhangjiakou railway is the train running and to which Beijing railway station it is headed?
[Note: Image gallery above refactored to prevent an overwide page for some users, by dcljr (talk) 07:07, 8 January 2018 (UTC).]

Why create the confusion when capitalizing these proper nouns would make the message so much more clear? At the least, I would like to see the de-capitalization campaign implemented in English-language dominated areas.

I urge you to reconsider this deeply misguided decision to de-capitalize names of rail lines and rail stations in China. It will only create problems for editors and readers, stunt the growth of coverage in this subject area and ultimately be reversed due to user and editor complaints, as the ambiguity problems become more pronounced.

ContinentalAve (talk) 21:01, 17 December 2017 (UTC)

Broken section above

I can't edit the section above, since it contains sections in the collapsed part, so may this new subsection will work.

I don't agree that the lowercase railway, station, or line necessarily adds ambiguity. There's a big difference between "the Beijing–Shanghai railway" and "a Beijing–Shanghai railway". One is specific, the other is not. There's no difficulty in distinguishing the specific referents of "the Beijing–Shanghai railway" and "the Beijing–Shanghai high-speed railway" that would be any different with capital letters. Dicklyon (talk) 05:22, 20 December 2017 (UTC)

I think I've fixed the problem that prevented editing the section above. FYI. - dcljr (talk) 05:49, 3 January 2018 (UTC)

Also strongly oppose

The two users most strongly wanting to decapitalise are Dicklyon and SMcCandlish... I find no evidence of either of them having any knowledge of either the subjects or the languages in question. Yes, knowledge of the language isn't really relevant to en.wiki generally, but I think in this case, it's important, because, quoting SMcCandlish from above: "the fact that CJK scripts have no case distinction means we absolutely should use lower-case here because our translations of them are just approximations and thus cannot be their proper names." is patently false. The concept of a proper name is basically universal across languages; by that logic, we should also be transcribing 東城秀樹 as "tojohideki" instead of "Hideki Tojo", 毛澤東 as "maozedong" instead of "Mao Zedong", and 김일성 as "kimilsŏng" instead of as "Kim Il-sŏng" or "Kim Il-sung". A proper name is a proper name, and it per the rules of English, they are to be capitalised. A quick Google search tells me that this concept is taught in Grade 2 or Grade 3.

Regarding the capitalisation of "station", "line", and "railway" in the CJK context specifically, though, I'd make the following observations.

1. Station - I'm not at all adamant that the 'station' part be considered part of the proper name, w/r/t the contexts of Korea, Japan, PRC, and Taiwan; as far as HK is concerned, English is an official language there, so we should do whatever is most widely used in HK - to which I cannot speak to, because I don't know aught about HK's railways. As far as the others are concerned, though, I can agree that 'station' is not always an integral part of the proper name, even though it is often used like that in those languages. In some cases, however, it would be necessary to capitalise it, to disambiguate. For example, Pyongyang Station refers to one specific station in Pyongyang; there are numerous other stations in Pyongyang, including West Pyongyang Station, Taedonggang, Man'gyongdae, Rangrim, etc. To say only "Pyongyang station" is, as ContinentalAve pointed out above with a Chinese example, ambiguous, so it needs to be capitalised for clarity. And if that's done, then it should follow that it be done in other non-ambiguous cases, simply for the sake of consistency.

2. Line - this isn't applicable to the PRC, but is applicable to Japan, Korea, and the parts of mainland China under Japanese administration prior to 1945, where railway lines used 線 as part of their name. In these cases, it must absolutely be capitalised, because it is without question a proper name. In Japan, names of railway lines are for the most part taken from either one location on the line, from the region the line is in, from one character from each terminus of the line, or some other descriptor, such as

  • Aizu Line, from the Aizu region of Fukushima Prefecture;
  • ja:小松島線 Komatsushima Line, from Komatsushima, one of the termini of the line;
  • Keiyō Line, which is formed from the second character of each terminus, Tokyo (東京) and Chiba (千葉) (京葉 together is read as "Keiyō"), to form a new proper name as a specific designator for the line;
  • Sankō Line, whose name means "Three Rivers Line", but there is no station on the line with that name, but rather is descriptive of the area; this sort of name is also used for the Chuo Main Line aka Chuo Line (=Central Line), etc.

To take "Aizu Line" as an example, it is without question the proper name of one specific line, because there are numerous other railway lines in the Aizu region, such as the Tadami Line, the Banetsu West Line, the former Nitchū Line ja:日中線, etc., which makes saying "Aizu line" ambiguous - *which* Aizu line is being referred to? So - it's necessary to capitalise the 'line' in this case, too, and so by extension, even if we accept the (ridiculous) notion that these are not necessarily proper names, for consistency's sake all "XYZ Line" names should be capitalised.

Railway practice in Korea is derived from Japanese practice, as it was the Japanese who brought the railway to the Korean peninsula; to this day, the naming of lines follows the Japanese models described above, primarily using the first and third varieties, though the other two turn up, as well. Taking the Hambuk Line as an example, its name is taken from the region it is in - Hamgyeong Buk-do (buk = north, North Hamgyeong Province); like the Aizu Line example above, writing "Hambuk line", however, would be ambiguous, as there are numerous other lines in the province. Another example would be the Gyeongbu Line (style number 3 above), whose name is formed from one character from each terminus - Gyeongseong (today called Seoul) and Busan; these names are, like Keiyō Line above, new formations used specifically for the naming of the railway line in question.

This third way (with 線) was also commonly used in China prior to 1945 in areas under Japanese rule, such as for the South Manchuria Railway's lines like the Anfeng Line, or the Manchukuo National Railway's Chaokai Line, etc. These are, without question, proper names.

The PRC differs from the above in using not 線 but 鐵路 to name its railway lines, which complicates the question a bit, 鐵路 means 'railway' in Chinese; 線 means 'line' (in the general sense), 'thread', 'wire', 'route' etc. And, in China, there are both long and short forms of names for railway lines, e.g. the Beijing–Harbin railway which is also called the Jingha Railway along the third model shown above. In the latter case, for the same reasons as above, these are proper names (there are several railway lines between Beijing and Harbin, for example). Although I will maintain that "Beijing–Harbin Railway" - when referring to one certain, specific line - is just as much a proper name as "Jingha Railway" is, I'd suggest that as a compromise we can consider the long form as just a descriptor, with 'railway' left uncapitalised, but that the short form is a proper name without question and so should be capitalised. Long-form names like this are in my experience rarely-to-never seen in Japanese or Korean.

I'll admit I'm not too adamant about what we do for the PRC, as I don't really have more than a superficial interest in the post-1945 situation there, I'm just including it for completeness; however, for Japan, Korea, and the railway companies of China under Japanese rule - the South Manchuria Railway, the Manchukuo National Railway, the Central China Railway, the North China Transportation Company, and several smaller, privately-owned railway companies in Manchukuo, such as the East Manchuria Railway (note that in these cases the 'railway' must be capitalised, as it is part of the name of the company, just like Canadian Pacific Railway etc) - I will be extremely adamant on the capitalisation of 'line' in reference to specific lines.2Q (talk) 16:18, 19 December 2017 (UTC)

Write all such articles in German. That way we don't have to worry about any of this (since in German, all nouns are capitalized). –Deacon Vorbis (carbon • videos) 16:28, 19 December 2017 (UTC)
How is this in any way a useful comment? 2Q (talk) 16:33, 19 December 2017 (UTC)
Because sometimes, when faced with utter lunacy (like the amount of effort that's been spent arguing over such a minute detail in an area of such niche interest), a little humor is exactly what's needed to put things in perspective. –Deacon Vorbis (carbon • videos) 16:40, 19 December 2017 (UTC)
Fair enough. :) I agree, though, it is kinda a ridiculous thing to be arguing about. 2Q (talk) 18:35, 19 December 2017 (UTC)
@2Q:, I appreciate that you're an expert on these old Japanese, Korean, and Chinese railways. Great stuff. And I understand that it's possible that I made mistakes and downcased some things that are legitimately proper names. But it's not really clear, from your explanations; when you say "it is without question the proper name of one specific line", it's not clear why you say "proper" in there. Many specific line names in many countries use lowercase "descriptive" names, or proper names with "line" or "railway" appended. When a specific Chinese character implies a proper name, I'd need help understanding that before I say OK. And when a "... Railway" title is about a company, as opposed to a rail line, then certainly I agree it's a proper name, and if I downcased any articles about companies I apologize (we had a dispute a year ago on the Harz Narrow Gauge Railways, an article that was originally written to be about the rail lines, but was rewritten to be about the company to justify the caps). Anyway, as I said, I've done my pass; now, if I got some wrong, point those out for discussion, or just move them back. Then maybe we can learn something and come out ahead. Dicklyon (talk) 05:00, 20 December 2017 (UTC)
I suppose the clearest way I can explain it is that in Japan and Korea there is (or, "was", in the case of parts of China under Japanese rule) a practice of naming railway lines, the same way that there is a (I imagine universal) practice of naming streets in a city. So, much like we've got a Granville Street and a Trafalgar Street and a King George Boulevard here where I live, in Japan and Korea etc they name railway lines in the same way, with the naming schemes I described earlier, so you've got a Tadami Line and a Gyeongbu Line and a Musan Line and what have you. There isn't a universal analogy to this in the West, aside from occasional cases, such as the SkyTrain system in Greater Vancouver, which has the Canada Line, the Expo Line, the Millennium Line, and the Evergreen Line. But these are proper names (in the same sense as street names etc.).
I'll admit don't know enough about the situation in the PRC post-1949 to say with 100% conviction it's the same there, but the impression I have is that they do have the same practice in use there as in Japan and both Koreas, and formerly in Manchukuo and the other Japanese-controlled parts of China. 2Q (talk) 15:39, 20 December 2017 (UTC)
The "practice of naming streets in a city" is much older than the practice of treating the "avenue" or "boulevard" or "street" as part of the proper name. Over time the interpretation of what's a proper name evolves, and this is where sources come in. In most places I've looked, I see of lot of lowercase line and railway and such (but always capped street, avenue, and such). I admit that for Japan the capitalized Line seems more prevalent. But I'm not at all sure that I can accept and extend that to the older lines without English-language evidence or a better explanation of what kind of name should be considered a "proper name" when it appears in Japanese or Korean or Chinese. Dicklyon (talk) 16:30, 20 December 2017 (UTC)
"The "practice of naming streets in a city" is much older than the practice of treating the "avenue" or "boulevard" or "street" as part of the proper name" - how is this relevant, though? It is the case now, and has been since at least the beginning of the 20th century. Capitalised Line is pretty much universal for Japan and is the basically standard form used in Romaji/English writing of line names... I'm really not sure how else to explain it more clearly than I already have short of suggesting you learn Japanese or Korean; I don't mean to be rude (and I don't think I honestly believe this, either, but you know how feelings can go), but it almost feels like you're being obtuse for the sake of being obtuse... okay that said I think if you're asking me how I'd define what constitutes a proper name... I'd say: if it is written with 線 and follows one of the four schemes I described above, it's a proper name... as when talking about a line in general, Japanese and Korean will most usually use "路線" ('route'), and will most usually be writing out the names of the termini in full.
For the record then I don't care what yous all decide on for lines in the PRC (although the situation with names like "Shendan Railway" *is* the same as with "Line")... I don't really care enough to put further effort into that. But for Japan, Korea, and the Japanese-controlled railways in the occupied parts of China and in Manchukuo (namely the South Manchuria Railway, the Manchukuo National Railway, the East Manchuria Railway, the North China Transportation Company, the Central China Railway, and a number of small privately owned railways in Manchukuo) I'll dig in as long as it takes. If it's written with 線 and follows one of the four schemes I described above, it's a proper name and should be capitalised as "XYZ Line"; in these places, if it's writing about 鉄道/鐵道 ("railway"), it's either speaking in general, or about the name of a railway company - which context will make clear, and if necessary can be dealt with on a case by case basis. 2Q (talk) 17:51, 20 December 2017 (UTC)

Comment and extension to metro stations

Sorry for being late, and I just wanted to give my two cents here as a somewhat active contributor to Chinese rail transport (railway, mostly metro) articles in the past. With respect to the 2011 "consensus" that ContinentalAve referenced regarding the naming, I don't really see any debate about the lowercase or uppercase naming for the "railway" or "railway station" part, which is the current issue at hand. It seems to have been glossed over and either didn't warrant debate or no one brought it up. I would say I weakly support the move to de-capitalize the words "railway," "railway station," and "station" in all cases (railways and metro systems) for PRC articles because there really isn't consistent inclusion or exclusion of the words for "Station" or "Railway" as part of the proper name, even in Chinese. ContinentalAve brings up some good points regarding the fact that there is a greater emphasis on the words "railway station" and "railway line" as part of the proper noun in China, but is this really a big deal when we're dealing with an English audience? For example, the phrase: The train has arrived at Beijing railway station, I don't see any ambiguity in terms of does this refer to the one Beijing Railway Station or a railway station in Beijing? I think it is clear that it refers to the railway station named Beijing, and there is only one, as the other ones are named Beijing South, etc. Another point, this problem doesn't even exist in spoken language, only written language. With respect to I'm travelling on the Beijing-Shanghai railway, I again fail to see how using capitalization, as in I'm travelling on the Beijing Shanghai Railway would provide additional clarity to the average layperson who may not be aware there is a normal conventional railway and a high-speed railway. So again in terms of describing it in English it doesn't provide any more clarity by simply capitalizing it.

I also wanted to bring up an extension of this debate regarding metro stations in PRC in general. I see above that there is a debate for Hong Kong MTR stations that is leaning towards supporting the de-capitalization of the word "Station," and I just wanted clarity on the same thing for all metro systems in China. Currently right now I think the convention is to capitalize the word Station. I think again one can argue that the word "Station" is important to the proper name in a Chinese context, but really there is some inconsistency in application. For example, if I walk into a Shanghai Metro station, usually the sign overhead at the entrance will say something like Shuicheng Road Station, which includes the word station as part of the proper name. But on the platform, we just see the words Shuicheng Road on all signs (in English), and even stop announcements just refer to it as Shuicheng Road (omitting the word station). In terms of this discussion, I would like to see it extended to look at and deal with all rail and metro system-related articles in PRC to ensure consistency. In all cases, I'm leaning towards de-capitalization, just to be consistent with Wikipedia guidelines as a last resort. Again, I agree in some respects that there is likely a greater emphasis on including "Railway" or "Railway Station" as part of the proper noun in China, but the application is inconsistent at best. I don't really see how a simply capitalization issue would "stunt the growth of coverage in this area" and don't really agree that there is an ambiguity problem that would be solved simply be capitalizing.

On a last note, a very specific one, it seems above that there was agreement that in cases where the station name contains the word "Railway Station", as in the metro station named "Hongqiao Railway Station", we would leave Railway Station capitalized. In this case, I'd like to propose we move back Hongqiao railway station (metro) to Hongqiao Railway Station (metro), and possibly to Hongqiao Railway Station station, as the (metro) part seems to be confusing and doesn't really clearly disambiguate what the article is about from the title alone (metropolitan area? what is metro?). It seems this was de-capitalized as part of the massive auto-de-capitalization list that was performed. Heights(Want to talk?) 05:03, 28 December 2017 (UTC)

Thanks for pointing out the odd case of the metro station named for the railway station. I think Hongqiao Railway Station station is logically sensible, yet jarringly wrong looking at the same time. Perhaps Hongqiao Railway Station (Shanghai Metro station) would be more clear and less jarring? Dicklyon (talk) 07:10, 28 December 2017 (UTC)
@Dicklyon: But then it wouldn't be consistent with other articles in the system, which would likely all be renamed to "Name station" or "Name station (system/city?)" by decapitalizing "Station". The zhwiki article is titled "虹桥火车站站" (lit. Hongqiao railway station station). The article South Square of Chongqingbei Railway Station station has already been renamed, and being titled "South Square of Chongqingbei Railway Station (Chongqing Rail Transit station)" might imply the station's name to be "South Square of Chongqingbei". Jc86035 (talk) 09:06, 28 December 2017 (UTC)
@Jc86035: Agree, I would prefer the double use of station given that the second one is decapitalized, which right now (at least for Shanghai Metro articles) it isn't. It is also, as Jc86035 pointed out, used in Chinese, where "站站" can be used to refer to a station that's at another station. The second proposal where it would be named Hongqiao Railway Station (Shanghai Metro station) does kind of mess up the consistency, and also for other stations requiring disambiguation, we currently use the format xx Station (Shanghai Metro), i.e. Xiaonanmen Station (Shanghai Metro), so if we switch to the second format, we would need to rename these articles to xx (Shanghai Metro station) as well. Heights(Want to talk?) 15:01, 28 December 2017 (UTC)
True. I moved it back to Hongqiao Railway Station (metro) to match the others (I think). No objection here if someone has a better idea. Dicklyon (talk) 17:03, 28 December 2017 (UTC)
Okay, that works for now. I think I'd like to eventually see a broader framework or set of guidelines established for naming of all metro-related articles in Mainland China as well, so we can remove any confusion and inconsistency in naming. I guess this is a similar discussion to the one for conventional railways and we can kind of tackle two issues at once if we come to some closure. There are similar questions like:

And more specific questions like:

  • Should we always use official English names provided by the transit agency, even when they are seemingly inconsistent? e.g. some systems, like Beijing and Nanjing, like to keep the character 路, meaning road, left in Pinyin as lu, such as Zhichunlu Station and Yunjinlu Station. Others, like Suzhou, like to keep it as lu, but with a space in between, such as Lindun Lu Station. Shanghai likes to translate the character to road, resulting in Boxing Road Station. Very inconsistent. The direction right now seems to use the official English name used within the system, which I tend to prefer, even though it is inconsistent across systems. It is generally consistent within a system, but even Shanghai still has an exception in Waihuanlu Station.
  • How should the cases of metro stations at railway stations be handled? Should we use xxx Railway Station station? xxx Railway Station (metro)? xxx Railway Station (Shanghai Metro)? or something else? Heights(Want to talk?) 19:17, 28 December 2017 (UTC)
I would prefer not capitalizing "station"; no preference for "[Ll]ine" (probably defer to sources); disambiguate with system (ASDFGH moved a lot of these from system to city but not sure if there was any consensus, and systems' stations are not necessarily within city limits); use the name the company uses (since they've provided official English names); use "…Railway Station station". Jc86035 (talk) 09:15, 29 December 2017 (UTC)
As in most other countries, we should lowercase "station" and "line" when moving toward consistency (even if the "official" listing caps them). I'd avoid anything like "Railway Station station" if possible. Dicklyon (talk) 18:16, 29 December 2017 (UTC)
@Dicklyon: Would you name South Square of Chongqingbei Railway Station station and Tianjinzhan Station (天津站站; lit. Tianjin railway station station) differently from the rest? For consistency, "…Station station" is probably the best option, although merging the articles for the mainline and metro/subway stations would also work (this is already the case for some articles such as Wuhan railway station, though it might not be entirely accurate if there is no official interchange like for National Rail/London Underground interchanges). Jc86035 (talk) 06:42, 30 December 2017 (UTC)
I don't have a strong opinion on these; just don't want to see excess caps. I don't think a complete consistency is that important. Dicklyon (talk) 22:08, 30 December 2017 (UTC)
And that, right there, is the best statement in this entire thread.... complete consistency ISN’T that important. Blueboar (talk) 01:15, 31 December 2017 (UTC)

RfC: Comma or parenthetic disambiguation for "small places"

There are recurrent disputes about article titles for what could be called "small places" – churches, sporting event arenas and other venues, schools and other institutions, malls, plazas, parks, outdoor statues and monuments, railway stations, and other things to which one can go but which are structures or otherwise have an architectural component, and are not villages, cities, forests, or other large areas. Just today, for example, there was move-warring between Nieuwe Kerk, Amsterdam and Nieuwe Kerk (Amsterdam), both moves performed via WP:RM/TR despite being potentially controversial. I see stuff like this all the time, and the amount of disruption (both to article locations and to editorial tempers) has gotten to the "enough is enough" point.

Should Wikipedia:Article titles#COMMADIS be applied to such "small places" consistently, or should we continue to arbitrarily apply parenthetic disambiguation to some of them? If the latter, what determines whether to use the one style versus the other?

Background: according to WP:ATDIS policy, parenthetic disambiguation is the third (that is, quite disfavored) choice in disambiguation style, with comma-based disambiguation ahead of it as number 2, and natural disambiguation preferred over all. An argument can be made that comma style in this sort of case is actually a form of natural disambiguation because it is regularly used in everyday English (i.e., comma disambiguation that isn't also natural is really more like Robert Scarlett, 2nd Baron Abinger and Robert Scarlett, 6th Baron Abinger – an awkward formalism, though still less awkward than parenthetic). The section in this policy on comma disambiguation gives both royal styles/titles and locations as examples, but not only is this not an exclusive list, it specifically says "Comma-separated disambiguation is sometimes also used in other contexts". The counter-argument appears to be that "places" was meant to be interpreted strictly as jurisdictions, is not inclusive of structures, fields/pitches, and other "micro-places", and that "sometimes also used in other contexts" doesn't apply to them.

 — SMcCandlish ¢ >ʌⱷ҅ʌ<  05:51, 23 November 2017 (UTC)

Comments on COMMADIS scope

  • Apply COMMADIS consistently, as more in keeping with WP:CONSISTENCY and WP:NATURAL policies (not to be confused with WP:NATURALDIS, which is dependent on it), and to put an end to pointless but heated and near-constant disputation over this disambiguation trivia, which is predicated on subjective, unclear, idiosyncratic distinctions about what is and isn't a "place".  — SMcCandlish ¢ >ʌⱷ҅ʌ<  05:51, 23 November 2017 (UTC)
  • Support for all cases where there's no good reason to do otherwise. Tony (talk)
  • No objection to adding churches, parks and stations to the list. But for example this generally does not work for paintings in art galleries (or in cities). Johnbod (talk) 13:40, 23 November 2017 (UTC)
    • Sure; this isn't mean to apply to anything no one would think of a "place", i.e. something one can neither enter nor (thinking of large monuments with no doors) climb. If it's big and outside, it should qualify. More like: stuff that our language naturally disambiguates with commas qualifies generally (per WP:ATDAB policy's order of disambiguation-style precedence); but commas don't work well for small, indoor things, or for stuff that's abstract or a person, or otherwise not something we non-awkwardly use commas with in English.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  14:49, 26 November 2017 (UTC)
  • I do not get how this works for neighborhoods/sections of a city, where there is also a park or other geographical feature with the same name. Alanscottwalker (talk) 13:47, 23 November 2017 (UTC)
    • Same as for any other such naming clash: disambiguate further, probably parenthetically. The idea that "Foo Bar, Baz" and "Foo Bar (Baz)" with each term identical between the examples (i.e. Foo = Foo), is supposed to meaningfully disambiguate between (e.g.) a park and a neighborhood is silly and impractical. The fact that people have been trying this and that readers and even many editors have been confused by it is a part of why this RfC has been opened. The sensible approach is to use "Foo Bar, Baz" for the WP:PRIMARYTOPIC and "Foo Bar, Baz (park)" or whatever for the non-primary one(s).  — SMcCandlish ¢ >ʌⱷ҅ʌ<  14:42, 26 November 2017 (UTC)
  • Comma disambiguation is a relic of the fact that this is how names of populated places tend to be addressed in the real world. I think it would be absurd to apply it to objects like statues. With respect to natural features like rivers and mountains, it typically distinguishes between those features and place names that happen to include the word "River" or "Mountain". bd2412 T 05:51, 24 November 2017 (UTC)
  • Note: An editor has expressed a concern that editors have been canvassed to this discussion. (diffs: [11], [12], [13])  — SMcCandlish ¢ >ʌⱷ҅ʌ<  14:37, 26 November 2017 (UTC)
  • Consistency is not needed... What determines whether to use the one style versus the other? Discussion and local consensus. Blueboar (talk) 15:11, 26 November 2017 (UTC)
    That doesn't seem to be particularly meaningful. This is a discussion, and WP:CONLEVEL specifically exists to prevent a "local consensus" from making up its own rules that conflict with site-wide policy like WP:ATDAB.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  14:38, 29 November 2017 (UTC)
I’m not saying that a “rule” should be made at a local level... I’m saying that the “rule” is: “There are several acceptable forms of disambiguation”... and the determination of WHICH acceptable form of disambiguation is most appropriate to use in any given article has to be made at the article level... on a topic by topic basis. Blueboar (talk) 13:04, 3 December 2017 (UTC)
  • This RfC seems a poorly framed (i.e., unclear) attempt to make policy based on edge cases. In general, I really, really do not understand why some editors have such an irrational dislike for parenthetical disambiguation. Personally, I think parenthetical disambiguation should be the default EXCEPT in those cases where there is a commonly used natural language title. Parenthetical disambiguation makes it clearer to readers what part of the title is the actual name of the subject rather than some arbitrarily appended term to disambiguate. So, I think that would place me firmly in the oppose camp. olderwiser 15:25, 26 November 2017 (UTC)
    Cognitive dissonance. It seems "unclear" to you, and you "don't understand" and think there's something "irrational" going on because you've made an incorrect assumption that this has something to do with likes and preferences. In reality, it's about how to apply the WP:ATDAB policy more consistently, to avoid continual pointless dispute on the matter. By way of analogy 1: You can harbor a dislike of a particular rule in Texas hold'em poker and wish that the game were a little different, but you'll still strenuously object when one of your opponents cheats under the rules as-written. Analogy 2) Your argument is effectively indistinguishable from "Kosher and hallal are weird nonsense. I don't get why these people hate pigs and have emotional issues with dairy. It's irrational that they won't eat my pepperoni pizza." It has nothing to do with emotional preferences, but with wether the food you put in front of them complies with rule systems they take seriously.

    I personally don't mind parenthetic DAB at all. I'd be quite happy if we eliminated all other options. But we have a four-tier system of DAB, with parenthetic in next-to-last place of preference, and that's what consensus has decided we collectively want. Analogy 3: Don't show up to a football game with a basketball and complain about all this kicking and grass and lack of a hoop.
     — SMcCandlish ¢ >ʌⱷ҅ʌ<  14:45, 29 November 2017 (UTC)

    I stand by the assertion that this is unclear (not only that it seems so). You want to read WP:ATDAB policy as being more hierarchical than it is or than how others interpret it. Sorry, I remain unconvinced. Ignoring your deprecating asides as off point and irrelevant, I continue to maintain it is more beneficial for readers to clearly mark the disambiguating terms with parentheses rather than make implicit suggesting that the comma term is a part of the name. olderwiser 16:18, 30 November 2017 (UTC)
  • Close per WP:FORUMSHOP. See Wikipedia talk:WikiProject Trains#RfC: UK railway station disambiguation. --Redrose64 🌹 (talk) 21:24, 26 November 2017 (UTC)
    • Nonsense. That's an only tangentially related discussion, primarily about word order, for one topic+country intersection. This is about a general principle across all topics, site-wide.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  14:36, 29 November 2017 (UTC)
So what was the objection to advising those participating in that specific discussion that a discussion of the 'general principle' had now been initiated (and would outrank the local discussion)?Rjccumbria (talk) 16:48, 30 November 2017 (UTC)
I don't know. Where is this objection of which you speak, so we can look at it?  — SMcCandlish ¢ >ʌⱷ҅ʌ<  10:53, 3 December 2017 (UTC)
  • There is absolutely nothing wrong with comma disambiguation for these places. It should be applied as it has always been applied. Consistently according to consensus (e.g. in most Commonwealth countries, the consensus is and has long been to use commas). -- Necrothesp (talk) 14:20, 29 November 2017 (UTC)
  • I have several issues:
    • I agree with Bkonrad in believing that my esteemed colleague, SMcCandlish, is mistaken in asserting that, because in WP:ATDIS policy, parenthetic disambiguation is listed third, it is a "quite disfavored" choice in disambiguation style. In fact, WP:ATDIS says, "When deciding on which disambiguation method(s) to use, all article titling criteria are weighed in," and then it lists 5 methods. There is no basis for concluding that these methods are listed in order of most-favored to least-favored.
    • The topic heading here is vague. Streets and roads are long and narrow; are they small places? For example:
    • Schools are typically disambiguated with parentheses, see, e.g. Lincoln High School.
    • It was recently decided that rail lines should use parentheses disambiguation.
    • "X, state" implies that X is the name of a locality within a state, for example, Syracuse, New York. We should avoid using comma disambiguation when it incorrectly implies that something is a locality.
    • In conclusion, I think this proposal should be quietly forgotten, i.e.,
    • Close. —Anomalocaris (talk) 10:20, 3 December 2017 (UTC)
  • Use parenthetical disambiguation for geographical objects which are not, as Wiktionary says, "inhabited areas" (place § English § Noun 1.3). While both would be correct but strange if inserted into the middle of an English sentence (and assuming we can't use "in place" as a disambiguator), using parentheses would marginally help with some consistency in naming for classes of physical objects which are disambiguated by things that are and are not place [inhabited area] names, such as railway stations. Jc86035 (talk) 15:13, 3 December 2017 (UTC)
  • Prefer comma disambiguation when it would be a natural way to describe a place in a sentence. As Jc86035 says, some "would be correct but strange if inserted into the middle of an English sentence"; the comma-disambiguated ones that would be correct and not strange should be preferred that way. I would think this would apply to a lot of Main Streets and railway stations. Dicklyon (talk) 16:17, 3 December 2017 (UTC)
  • Close. I cannot see how any one rule is going to fit well for all purposes, places, and regional styles; the reasonable exceptions may well outweight the "majority". "Small places" is imprecise, likely to create more EW, not less. Maybe this RfC could be broken down in a few manageable sub-cases (like the railway naming), but not one rule to ring them all. --A D Monroe III(talk) 18:04, 3 December 2017 (UTC)
  • Close with "no consensus". As per Anomalocaris, there is more than one way to disambiguate, and the comma is not always the natural way. This entire RfC seems to be another attempt by SMcC to make everyone follow the rules as determined by him or else. Useddenim (talk) 14:45, 29 December 2017 (UTC)
  • Oppose per WP:CREEP. Andrew D. (talk) 18:14, 3 January 2018 (UTC)

Extended discussion of COMMADIS scope

What are you raving about, McCandlish? There has only been a single move, which I performed (not by WP:RM/TR), at Nieuwe Kerk, Amsterdam, to what you admit (behind the usual smokescreen of verbiage) is the right title. You might be thinking of Oude Kerk, Amsterdam, which is where it has long been, until some well-meaning type briefly moved it to Oude Kerk (Amsterdam), to agree with the Nieuwe Kerk as it then was, and I moved it back (via a WP:RM/TR request). The vast majority of churches are disamed with a comma, and rightly so. No "move-warring", still less "pointless but heated and near-constant disputation", & nothing "potentially controversial", Johnbod (talk) 13:22, 23 November 2017 (UTC)

I decline to address uncivil characterizations like that. If I say this is about a long-term pattern of conflict, then I mean that. The fact that you don't like one example has no bearing on the RfC other than maybe some additional examples would have been in order. At this late a date, there'd be no point.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  16:48, 16 December 2017 (UTC)

Are these "small places" actually places, or are they just things which happen to have a fixed place because they're too big to move easily? For example, Forres railway station just moved. (Must update the article...) The term "Forres railway station" now applies to the new facility (even though they built new platforms rather than shifting the old one), suggesting that the article's topic is an object rather than a place. There is an argument for COMMADIS applying, but I don't think it's an obvious consequence of "small places" being a subset of "places". Certes (talk) 15:18, 26 November 2017 (UTC)

@Certes: See also wiktionary:place#noun. I think you could look at this debate as entirely based on which sub-definition of "place" is supposed to be meant. Jc86035 (talk) 15:21, 3 December 2017 (UTC)

RFC on forming possessive form of singular names, MOS advice simplification

Should we simplify the advice of the WP:Manual of Style to choose between a pronunciation-based option and a uniform "add apostophe and s" option, in favor of just the uniform approach, since the pronunciation-based approach is complicated, seems to be misunderstood, and is hard to apply? Dicklyon (talk) 02:36, 12 December 2017 (UTC)

Specifically, the proposal, based on the discussion at WT:MOS#Apostronot, is that the nearly three hundred words of the existing MOS:POSS under the heading Singular nouns be replaced with this text that paraphrases the advice in University of Oxford Style Guide:

For the possessive of singular nouns, including proper names and words ending with an s (sounded as /s/ or /z/, or silent), add 's: my niece's wedding, James's house, Cortez's men, Glass's books, Illinois's largest employer, Descartes's philosophy. If a name already ends in s or z and would be difficult to pronounce if ’s were added to the end, consider rearranging the phrase to avoid the difficulty: Jesus’s teachings or the teachings of Jesus.

Note that most modern English guides recommend an approach close to this, though often with a short list or small category of exceptions. Please comment, support, or oppose. Feel free to propose alternative simplifications if neither this proposal nor the status quo seems ideal. If you prefer exceptions, what is the list or how will it be determined? Dicklyon (talk) 02:36, 12 December 2017 (UTC)

Comments on singular possessive form

  • Support as much simpler and easier to understand and explain; would avoid the pronunciation arguments that the current MOS:POSS generates, and reflect common usage MapReader (talk) 06:10, 12 December 2017 (UTC)
  • I've always found this rule from the University of Oxford's style guide to be very clear and useful. I'd support this change. Killiondude (talk) 07:09, 12 December 2017 (UTC)
  • Support (preferably without the second sentence, since pronunciation varies widely). This is the sensible "please stop fighting about this" approach, and is very clear and simple both for editors and more importantly for readers. The "sometimes just use ' by itself" styles are ambiguous, inconsistent, confusing, and lead to frequent dispute, while the "consistently use 's" style is understood by everyone, and 100% clear on whether something is a singular or plural possessive. Verbal pronunciation-based ideas about how to punctuate are of no relevance on Wikipedia, which is not a broadcast medium. Such "rules" (which sharply conflict in both specifics and rationales from publisher to publisher) are found in regional style guides, but do not make any sense in an international encyclopedia, because pronunciation of things like Jones's and Texas's vary on more than one axis (both syllabification and, often, /s/ versus /z/ – varying not only by dialect but by individual word/name). Modern style guides are increasingly shifting to a simple "just use 's" rule, including The Chicago Manual of Style (with some nitpicks [some of which are not even self-consistent – even CMoS has some editing gaffes] in the 17th ed., University of Oxford Style Guide, and various others. Those that want some kind of "odd exceptions for ' by itself" variance are mostly either old, or are written for a fixed audience with known dominant pronunciation patterns. We have no need of the rather tortured "make a special exception for ..." stuff found very randomly and inconsistently in various off-WP style guides (when not based on regional pronunciation, they're usually based on the traditionalism of "Jesus'" and "Moses'" in the King James Version of the Bible, which is written in late Middle English, while Wikipedia obviously is not).  — SMcCandlish ¢ >ʌⱷ҅ʌ<  11:25, 12 December 2017 (UTC); revised 14:24, 14 January 2018 (UTC)
  • Support but allow occasional exceptions if contemporary English reliable sources are (mostly) consistent in using just '. Above all don't edit war about it. Thryduulf (talk) 13:43, 12 December 2017 (UTC)
    I was assuming it went without saying that the normal approach of preserving format for citations and quotations would continue to apply. Other than that, I doubt that there are any words where an alternative format is consistently used; even Jesus's is very common nowadays MapReader (talk)
  • Support This is the only sensible version. No need for a list of exceptions, just rephrase the sentence if you don't like how it sounds. --Khajidha (talk) 13:46, 12 December 2017 (UTC)
  • Support. This is great.The current MOS, with two options, one unconditional and the other depending on pronunciation, with the one to be used depending on who's edited the article first, couldn't be better designed to generate editor disputes. The new proposal is so much better. — Preceding unsigned comment added by 2a00:23c5:5a4c:c400:d093:4f95:a3d0:abdb (talkcontribs)
  • Support per University of Oxford style guide linked above. --SarekOfVulcan (talk) 15:42, 12 December 2017 (UTC)
    Just to be clear, this is the "University of Oxford Style Guide", not one of the "professional" guides published by Oxford University Press, which it states it is not trying to compete with, but does differ from a bit. Dicklyon (talk) 16:35, 12 December 2017 (UTC)
    Thanks, edited to clarify. --SarekOfVulcan (talk) 18:57, 14 December 2017 (UTC)
  • Comment - in the example, I don't understand why it's recommended to add 's for "Glass's books" while it's recommended to rewrite "Jesus's teachings". What's the difference? Both end with a hard s sound, at least how I pronounce them. And maybe it's different in different places, but wouldn't "Jesus's teachings" and "Jesus' teachings" be pronounced the same? Ivanvector (Talk/Edits) 18:55, 14 December 2017 (UTC)
  • Your last sentence is a good point. I suggest that multiple editors corner their respective priests/pastors at church on Sunday and ask them how they pronounce the possessive of "Jesus" in their sermons. And report back here afterwards. If "Jesus's" is good enough for Father Bob and his congregation, it should be good enough for Wikipedia. ―Mandruss  19:49, 14 December 2017 (UTC)
  • Jesus's is certainly good enough for a range of reputable sources including the Daily Telegraph, the Atlantic website, Newsweek magazine, and the Guardian, as well as a whole batch of Christian sites in both the U.S. and Europe. MapReader (talk) 20:59, 14 December 2017 (UTC)
  • That being the case, even if the last sentence is retained, which I will probably oppose as a cost:benefit fail, "Jesus's" is a crappy choice for an example. ―Mandruss  21:06, 14 December 2017 (UTC)
  • Nevertheless the proposal delivers 90% of what you are arguing for, and the option to re-word a phrase is always there, whether flagged by the MOS or not. WP MOS proposals are littered with examples of the good failing for want of the best, and hopefully editors will recognise that a leap forward is progress even if not perfection in a single bound? MapReader (talk) 22:55, 15 December 2017 (UTC)
  • I stated support for "as written" as second choice. That means that, absent a consensus for my first choice, my !vote is no different from yours. Thus, this is not a case of "better is the enemy of good". But there is no chance of that consensus if nobody is willing to be the first to !vote for it. ―Mandruss  05:12, 17 December 2017 (UTC)
  • Yep. I've changed my own stated preference to match yours, since I hold the same views; all the second sentence does is shift the point of contention instead of removing it.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  14:24, 14 January 2018 (UTC)
  • Many guides discuss exception for names already ending with two sibilants, like Jesus and Moses; quite different from Glass. And if you would pronounce Jesus' the same as Jesus's, you are evidence for the fact that this distinction is super confusing. Dicklyon (talk) 20:24, 14 December 2017 (UTC)
  • No, that's the key point, the ' is silent (in those style rules, like ours, that are based upon pronunciation). Listen to the Velvet Underground song Heroin, the line containing Jesus' son. Pronounced the same as Jesus son. Indeed pretty much the only argument for the ', given the potential ambiguity it creates, is the supposed difficulty of pronouncing 's (in certain limited circumstances). Yet, as SMcC says above, WP is not a broadcast medium. MapReader (talk) 20:46, 14 December 2017 (UTC)
Is that a point of difficulty with the instructions? I've always read constructions like Jesus's and Jesus' as both sounding like "Jesuses", although it occurs to me that I would pronounce something like "Jesus' son" as you said in your example. I've also wondered why it became standard to use s' at all, figuring it's just one of those weird English things. Like how in Shakespearean-era English in a phrase like "all are punished!" the word "punished" is pronounced with three syllables (pun-ish-ed), where for it to be pronounced like we do these days it would be written "punish'd". That is, just something weird that evolved into (or out of) the language. This is probably way off-topic. The point is, if people don't agree on how to pronounce these things, then a standard based on pronunciation will fail. I don't know if this is a widespread case: it's what I'm used to, but it could still be a rare thing. Ivanvector (Talk/Edits) 21:37, 15 December 2017 (UTC)
The only argument for not adding the 's, which is the standard approach in written English, is the link (in some style guides) with pronunciation. As soon as you divorce pronunciation from the written form - already a common approach, English being full of irregularities - you may as well always just add 's for the written possessive. As you say, we would be better off without a style guide within WP that tries to link punctuation with pronunciation, given how much the latter varies around the world. MapReader (talk) 03:43, 19 December 2017 (UTC)
  • Comment - If a name already ends in s or z and would be difficult to pronounce if ’s were added to the end, consider rearranging the phrase to avoid the difficulty: Jesus’s teachings or the teachings of Jesus. - Why does it matter whether it's difficult to pronounce (for some people)? How often do people read Wikipedia articles aloud? Are readers going to spend a significant amount of time struggling to "pronounce" "Jesus's" in their minds? ―Mandruss  19:35, 14 December 2017 (UTC)
    You're right, and the group of us that discussed it on the MOS talk page did consider going a step further and recommending simply always adding 's. The final proposal we ran with retains a small part of the existing link to pronunciation, particularly for sensitive words like Jesus - but through the option of re-ordering the phrase (which is always open to editors anyhow). MapReader (talk) 20:51, 14 December 2017 (UTC)
    To answer this would take quite awhile and involve the mechanics of how people actually perform the process of 'reading'. Short version: Internal voice can trip up reading as much as external voice. See Subvocalization. If its hard to say, it can be hard to read. Only in death does duty end (talk) 09:16, 15 December 2017 (UTC)
    That is not an argument for omitting the 's. I get "tripped up" more by Jesus' than by Jesus's—my language processing center needs the 's sound to make it a possessive.
    Regardless, even if there is some subvocalization benefit that is so minute that we need academics to tell us it exists (and that has yet to be shown, anyway), I weigh all benefit against its cost and I believe that that second sentence is a cost/benefit fail for the project. Editor time is a finite resource; there will never be enough of it to do everything, so priorities must be set and some less important things must be allowed to slide in favor of more important things. The editor time spent arguing, edit-warring, and RfCing about this (and more editor time dealing with the disputes at DRN, ANI, AN3, etc) would be editor time not spent doing things that benefit readers more. ―Mandruss  20:24, 15 December 2017 (UTC)
  • Support first sentence only per my comments above. I fully support the use of guidelines to eliminate unjustifiable battlegrounds, and the second sentence does the opposite. It will not be a good use of community time to engage in debates about the degree of difficulty in pronouncing "Hughes's"—replete with academic/pedantic references to sibilants and such—especially considering that readers are not required to pronounce it. Support as written as second choice, as that would still be a marked improvement. ―Mandruss  21:46, 14 December 2017 (UTC)
  • Oppose anything more: I am extremely unfamiliar with "'s" being added to possessives ending with an "s"; it looks really weird. In that regard, I am completely against anything that fully discourages the use of "s'". If—however—it is evidently becoming common (and I have missed it), by all means give editors a choice. Sb2001 14:19, 15 December 2017 (UTC)
    Adding 's has always been the most common thing, for most names ending in s. I've never seen a style guide that said generally not to, have you? A lot of people do confuse the rules from plurals that end in s, however, which may be the case with your own familiarity. For examples, see the history of the Steve Jobs article; every now and then someone comes along and claims they were taught that Jobs's would be wrong; but by all style guides I've ever seen, it's right and preferred. Still, some of the cited sources do use Jobs', so we quote them that way. Neither of the alternatives recommended by our MOS or most guides would sanction that. Dicklyon (talk) 02:02, 17 December 2017 (UTC)
    I cannot say I have ever consulted a style guide on this—it has never been disputed. I have always written "s'", and haven't been questioned about it. Most of my grammar, etc, comes from education. The teacher who introduced me to possessives must have adopted this style. Sb2001 01:00, 20 December 2017 (UTC)
    See here for some recent previous style guide and dictionary discussion, before the RfC. See also long list of previous discussions going back to MoS's earliest period. The précis is that style guides since at least Strunk & White's The Elements of Style have advised consistently using apostrophe-s, while some have made various inconsistent exceptions but decreasingly do so, and various news publishers have preferred dropping the s under various circumstances to save space but they also don't do it consistently.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  14:44, 14 January 2018 (UTC)
  • Oppose standardising this completely. As there are still style guides that recommend checking the pronunciation [14], we don't need to force editors to write "Mephistopheles’s" against their will. Our MoS should not recommend something and then say "if it looks weird to you, rephrase it". Instead, allow non-weird possessives. —Kusma (t·c) 21:55, 15 December 2017 (UTC)
    You are of course free to write it any way you please. The MOS does not force editors to do anything. But if someone moves it toward MOS compliance, let it go, OK? That's all we ask. Dicklyon (talk) 03:58, 16 December 2017 (UTC)
    Unfortunately, in reality, no one is free to write anything any way they please because MOS does force editors to do it the MOS way -- and it's why one editor can easily lord over another editor with [[MOS:SAYS]]. Pyxis Solitary talk 12:14, 23 December 2017 (UTC)
    I can't even imagine how I could force you or another editor to write the way the MOS recommends. Dicklyon (talk) 00:49, 24 December 2017 (UTC)
Off-topic digression about editors who delete content based on MoS-related arguments
  • Every time an editor swoops into an article to delete or change content with [[MOS:SAYS]] as the reason, he's using MOS to force editors to write content in a manner that complies with MOS. Sometimes it's legitimate, but sometimes MOS is used by assholes who spend their life nitpicking articles as self-appointed MOS enforcers. Pyxis Solitary talk 03:59, 26 December 2017 (UTC)
    I'd like to see one example of an editor referring to themselves as a "MOS enforcer". Primergrey (talk) 05:42, 27 December 2017 (UTC)
    I'll bet you thought you had a perfect riposte. But I suggest you re-read what was actually written. Pyxis Solitary talk 03:26, 28 December 2017 (UTC)
    So how do you decide which it is? Legitimate attempt to bring an article more into accord with en.w's MOS, versus just nitpicking self-appointed enforcers? And how does that force anyone else to write one way or another? Dicklyon (talk) 04:11, 26 December 2017 (UTC)
    Experience, with certain editors who shall remain nameless. I've seen editors wipe out content, for example, and point to MOS as the basis. But when you read what MOS actually says, the "basis" was a personal interpretation of MOS. And these are editors who, when you look at their history, are habitually involved in ANIs. (Having a system in place for resolving disputes is laudable, but Wikipedia also needs a simple 'EditorName+ANI' search function so that everyone can find out how contentious some editors are.) MOS in a Webopedia offers a measure of uniformity in its articles (sections, sources, links, images, et al.). But nitpicking, for example, is when an editor removes a name from an infobox because the article does not also contain a source for the name, and gives MOS as the reason for the deletion — when what he should have done is add a 'citation needed' template so that it stands out and another editor can then find a source. And then when you look at the history of the editor that deleted the content, you see that he's been swooping through numerous articles, making the same or similar edits to them.
    How can MOS be used to force someone to write one way or another? All you have to do is rewrite what that someone contributed and use [[MOS:SAYS]] as the reason. Maybe it was poorly written, and that's legitimate. But sometimes it's just another editor's preference for how something should be written. And that, in itself, sends a message. (And this discussion is not a means to an end. And is going nowhere. Because there's nowhere to go.) Pyxis Solitary talk 04:40, 27 December 2017 (UTC)
    Unless a change per MOS can be shown to harm the article, it should be left alone. If there is disagreement about whether it harms the article, that's why we have article talk pages and consensus. All of this can and should be resolved with mutual respect like any other issue. Hyperbolic and inflammatory references to swooping into articles (how does one "swoop into" an article, exactly?) and "assholes who spend their life nitpicking articles as self-appointed MOS enforcers" have no place in discussion or in one's thinking, smack of WP:PA and WP:OWN, and are themselves harmful to the project. Period. ―Mandruss  04:57, 26 December 2017 (UTC)
    "have no place in discussion or in one's thinking, smack of WP:PA and WP:OWN". And here is a perfect example of how WP guidelines can be abused.
    WP:PA doesn't apply to a generalized comment where no specific, individual editor is targeted in a comment. WP:OWN doesn't apply when a generalized comment does not involve an article.
    Saying that my comment smacks of "WP:PA and WP:OWN" is a veiled attempt to intimidate me. Until I say "So and So is an asshole" — WP:PA is null and void. Until I say "I don't want editors doing this and that to this article" — WP:OWN is null and void. I don't play games with WP guidelines and I don't use WP guidelines to apply pressure on another editor. And unlike the behavior and attitude I've witnessed from many editors since Day One ... I don't walk on water. Pyxis Solitary talk 03:21, 27 December 2017 (UTC)
    "Smack of" as in "smells like" as in "not far removed from". You acknowledge this yourself when you point out the distinctions between what you're saying and an actual violation of these policies. Primergrey (talk) 05:50, 27 December 2017 (UTC)
    Pyxis, you appear to be mixing up "the MoS" with "isolated disruptive editors I have a problem with and who deleted some content I would have kept". That whole block of invective is just is off-topic, since it has nothing to do with apostrophes and possessives. PS: The search function you want already exists; go to WP:ANI, and at the bottom of the "Noticeboard archives" navbox there's a search field.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  14:24, 14 January 2018 (UTC)
Pyxis is obviously confusing "writing" with "editwarring to prevent rewriting", confusing "I want to write how I want to write" with "I want to stop anyone else writing how I don't want to write in articles on my watchlist", and forgetting WP:MERCILESS. If you write "Amy Jones's", as advised by Chicago Manual of Style, et al., and Pyxis happened to have originally put "Amy Jones' " in there, under the old and confused/confusing MoS guidelines, it's Pyxis who wants to "swoop into an article to delete or change content ... to force editors to write content in a manner that complies" with a PoV position. This sort of thing is precisely why we have WP:OWN policy. — SMcCandlish ¢ >ʌⱷ҅ʌ<  14:24, 14 January 2018 (UTC)
Kusma, "there are still style guides that recommend checking the pronunciation" is a faulty notion. Style guides are not in any way consistent in doing so (other than the major academic ones, on which MoS is based, are all moving to using " 's" consistently. Purported rules in the other direction I've seen (in old style guides, news journalism ones, and obscure ones) are to: use the apostrophe alone only with "Jesus" and "Moses" specifically; do it it for all Greek and Latin names; for "names from antiquity"; for everything ending in the character "s"; for everything ending in the character "s" or "z"; for everything ending in an "s" sound, for everything ending in an "s" or "z" sound; for anything ending in those sounds but only if a following /əz/ sound would be dropped from it [by that publication's target audience]; for anything that already has sibilants in both the final and penultimate syllables; and more besides. WP has no particular target audience, and pronunciation varies, widely, by region even in the same country. The only practical solutions here are what Dicklyon proposed, or Mandruss's shorter version without any "rewrite" suggestion. While editwarring about this doesn't rise to the level of a huge public controversy like the kind that end up with their own ArbCom case, it's still frequent. And it's always a facts-versus-opinion issue (what style guides that WP cares about say, versus WP:IDONTLIKEIT / WP:IDONTKNOWIT), and essentially the same debate again and again and again; preventing such perennial drain on editorial productivity and collaboration is why we have a style guide.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  14:24, 14 January 2018 (UTC)
  • Support I think clearer instruction in the MOS would be beneficial to the project as a whole, (hopefully) eliminating one point of confusion/contention. At the very least, perhaps we can restrict this conflict to a single thread here as opposed to a myriad of article talk pages. Personally I have always cringed at the singular s-apostrophe construct, but I have noticed a marked increase in its usage of late, especially in more casual writing. CThomas3 (talk) 03:53, 28 December 2017 (UTC)
    • Some variant of it is commonly found in news style, but WP is not written in that style as a matter of clear policy at WP:NOT#NEWS. Its common in that field because journalism prizes compression over clarity due to print constraints (WP:NOT#PAPER), and is usually (aside from massive publications like The New York Times and The Guardian) written for localized audiences with predictable publication patterns. While use of the bare apostrophe has declined outside journalism, it seems to have increased in news, probably because of merger of broadcasting and print news operations, with internal consolidation of their style guides (pronunciation cues like using "Texas' " instead of "Texas's", in particular markets, has long been a feature of writing for teleprompters). We cannot predict how people are going to want to pronounce things.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  14:24, 14 January 2018 (UTC)
  • Support per initiator. Jc86035 (talk) 09:45, 29 December 2017 (UTC)

Closure?

With over 80% support, a formal close does not appear to be needed. I'm make the proposed change at the MOS and see where we go from there. Dicklyon (talk) 02:32, 8 January 2018 (UTC)

Should Wikipedia have and maintain complete lists of airline destinations?

See Category:Lists of airline destinations.

These 444 pages are lists of every single city each of these airlines fly to. Should Wikipedia be hosting this content or is it a case of Wikipedia is not a directory? 22:28, 1 January 2018 (UTC)

  • It is my belief that these were created in good faith by somewhat over-eager fans of aviation. These lists provide far more information than is needed for a general-knowledge encyclopedia and to my mind amount to free advertising for the airlines, although I'd again like to stress that I do not believe that was the intent behind them.
An explanation in the main article on an airline of what region an airline operates in and what cities are its hubs is more than enough explanation, if readers desire further information they can follow the links to the airlines own website, which is far more likely to be accurate and up-to-date anyway. There is an important distinction between information and knowledge. Wikipedia strives to provide knowledge, and is explicitly not a directory or catalog, which is just information. I therefore believe a community discussion of whether we should retain this content is in order. Beeblebrox (talk) 22:28, 1 January 2018 (UTC)
  • No. Well summed up by Beeblebrox. I can't imagine this would be possible to keep current indefinitely anyway. –Deacon Vorbis (carbon • videos) 23:19, 1 January 2018 (UTC)
  • Well, I just looked at one - the um, list was started 14 years ago! and it was pretty up-to-date - what are you going to do with them? Alanscottwalker (talk) 23:25, 1 January 2018 (UTC)
  • wow. I'd no idea we had that. I just looked at a few (per Alanscottwalker) and they look to be in good shape. Some in really good shape. So I have no problem with us keeping these as long as they can be kept up. So yes I suppose. Hobit (talk) 00:01, 2 January 2018 (UTC)
  • Can we somehow port these over to Wikivoyage? bd2412 T 00:12, 2 January 2018 (UTC)
  • Question: How is this any different from all our super-detailed info about railway, bus, streetcar, subway, and other transit destinations? The only obvious differences are the mode of transport and distance covered (sometimes – but there are very short flights and very long railway lines). A less obvious distinction is that it's easier to change flight patterns and routes of service, so they will change more often, so these lists will need more maintenance. We have lots of lists that need regular maintenance, so again: how it this case different? All that said and asked, I have no particular objection to the idea of moving the info to WikiVoyage, if that site is still really alive. Just makes me wonder what else should move there if we go that route [pun intended].  — SMcCandlish ¢ >ʌⱷ҅ʌ<  01:53, 2 January 2018 (UTC)
    • There isn't one, which is why the examples you give should also be rewritten, trimmed, and/or removed. James (talk/contribs) 14:38, 2 January 2018 (UTC)
    • WP:OTHER is no argument either way. Having said that, I agree that WP:NOTADIRECTORY deserves more respect than it gets and the whole lot probably need an axe job. — Cheers, Steelpillow (Talk) 19:01, 2 January 2018 (UTC)
  • Obviously not. This is what NOTDIR is for. Regardless of how "current" these lists are, they do not belong here. If another site or project wants them, they can have them; we are CC-licensed, after all. James (talk/contribs) 14:38, 2 January 2018 (UTC)
  • Comment – See previous (10+ year old) deletion discussions here and here. –Deacon Vorbis (carbon • videos) 15:13, 2 January 2018 (UTC)
  • Comment Is this any different from the "airlines and destinations" section present in almost every article about a commercial airport? As much as I like the sections because they give one an idea of the "reach" of an airport, I can't come up with a policy-based argument for keeping one but not the other. – Train2104 (t • c) 16:41, 2 January 2018 (UTC)
  • No - As BD2412 suggested above, the information should somehow be copied over to Wikivoyage. - Knowledgekid87 (talk) 16:44, 2 January 2018 (UTC)
  • Perhaps re-run the old deletion noms? See what happens? -- Alanscottwalker (talk) 16:50, 2 January 2018 (UTC)
  • No: might be ok at Wikivoyage but not here, for the reasons given by the OP. - Sitush (talk) 16:57, 2 January 2018 (UTC)
  • I think no. The lead content in say Aerolíneas_Argentinas_destinations can be merged with Aerolíneas_Argentinas but the list itself is not needed. Galobtter (pingó mió) 17:05, 2 January 2018 (UTC)
  • No: But I bet you, if these are deleted, editors will try and include the information in just as much excruciating detail in the articles proper on the airlines in question. At least this way its corralled out of the main articles. Only in death does duty end (talk) 17:06, 2 January 2018 (UTC)
  • I'm not worried, we deal with these kinds of things all the time. - Knowledgekid87 (talk) 17:09, 2 January 2018 (UTC)
  • (edit conflict) I think we can avoid that problem if we move these to Wikivoyage, and then put up prominent crosswiki links to inform editors and readers that this is where they can be found and updated. bd2412 T 17:11, 2 January 2018 (UTC)
  • I don't have a problem at all with the well-maintained ones, and have often used the destinations lists in airport articles. Just like most other transportation related articles, they are typically up to date, well maintained and useful. Wikipedia is not only a "general purpose encyclopaedia", but in addition contains vast amounts of specialised knowledge. I can't see a huge difference between lists of this type and many of our sports statistics pages -- both are specialised and require frequent updating. There may be interesting content to add to many of the lists (reasons for opening and closing of certain routes, or which routes were bought when some other operator collapsed). The historical destination lists seem to me to be a possibly quite valuable resource. Removing all those pages will throw out a lot of encyclopaedic material; not worth it just because some of them feel like they might not belong. —Kusma (t·c) 17:10, 2 January 2018 (UTC)
  • Is there a way to separate the historical ones then or include the information via prose in other articles? If I were looking for what plane took me where I would inquire a travel agent, not Wikipedia. - Knowledgekid87 (talk) 17:13, 2 January 2018 (UTC)
I do think that since changes in destinations do receive coverage it kinda makes sense to have it. Galobtter (pingó mió) 17:14, 2 January 2018 (UTC)
  • No, for two reasons. A) Listcruft, B) Too difficult to keep up to date. Reyk YO! 17:16, 2 January 2018 (UTC)
  • Yes It seems likely that these lists have been spun off from the airline articles as they have grown and developed. If there is scope for improvement in the way we do this, this this should happen in an organic way, rather than being disrupted by some crass deletionism, which has already been tried and failed. WikiVoyage would be hopeless as a substitute. It doesn't have pages for individual airlines and so does not appear when you search for such information, where our pages do. Wikidata might be better as a repository because their data is more comprehensive and better structured as a database. Exploring this possibility should be done in a constructive rather than destructive way per our editing policy. Andrew D. (talk) 17:28, 2 January 2018 (UTC)
  • "Crass deletionism" is not a useful argument, just as "crass inclusionism" is not. - Sitush (talk) 17:32, 2 January 2018 (UTC)
  • Yes, despite wanting to say no, because Wikivoyage ought to be the more natural place for this sort of thing. Problem is, the editors at Wikivoyage disagree with this assessment! In early 2017 a decision was made to not host information about airlines or destinations due to concerns about how much there would be to maintain, and because they aren't attempting to maintain similar sorts of information about bus or train lines. There are other reasons, too. See wikivoyage:Talk:Airlines for more of that conversation.
But therein lies the reason why this information is probably okay to stay on Wikipedia -- we do maintain extremely comprehensive information about destinations served by train and bus lines all over the world. Random example: List of Toronto Transit Commission bus routes The long-standing existence of lists of routes suggests to me that Wikipedia has long accepted consensus around the idea of providing information about destinations. I guess I just don't why rail & bus would be fine, but airline would not -- servicing destinations is the intrinsic purpose of these businesses, right? A transit company/agency that didn't serve destinations wouldn't even be notable, right? Warren -talk- 03:06, 3 January 2018 (UTC)
  • I stopped reading at WP:OSE as WP:NOTDIRECTORY is a policy used here. As I said if I wanted to see what airline took me where I would go-to a travel agent. - Knowledgekid87 (talk) 03:16, 3 January 2018 (UTC)
  • No but WP:OSE and WP:CCC does. Each case is different, you are comparing a train lines to airline destinations which change frequently. - Knowledgekid87 (talk) 03:53, 3 January 2018 (UTC)
  • If Wikivoyage decided some time ago not to host these, perhaps we can ask them to reconsider. Obviously there is a community of interest willing to maintain them. Maybe those editors would be willing to maintain them on a sister project. bd2412 T 04:41, 3 January 2018 (UTC)
  • Also, we are not obligated to do something just because Wikivoyage have decided not to do it either. Reyk YO! 05:51, 3 January 2018 (UTC)
  • Nobody's disputing that. Warren -talk- 05:59, 3 January 2018 (UTC)
  • Move to wikidata is what I say.. —TheDJ (talkcontribs) 09:36, 4 January 2018 (UTC)
  • No. Wikipedia is not a travel guide, and it's all but impossible to verify through reliable sources many destinations, as the airlines themselves consider many route alterations to be routine and therefore don't publicise them beyond altering their ticket-selling algorithms online. And that is what also defeats the WP:OTHERSTUFF argument of "but what about train stations and bus routes, we cover them?" above: train stations very rarely change, and when they do, there are news articles about it (because new stations have to be built, communities fret about losing their stations, etc.), and bus routes are also very stable things that can be easily sourced to reliable sources (at least in part due to the fact that you don't buy tickets from Bus Stop A to B, you instead look up where stations are). - The Bushranger One ping only 02:00, 6 January 2018 (UTC)
  • No I agree with above comments that Wikipedia is not a directory, and is not maintained like a directory - these types of lists are likely to become outdated. SeraphWiki (talk) 02:19, 6 January 2018 (UTC)
  • No, for the sole reason that Wikipedia is not a directory nor it is a travel guide. Ajf773 (talk) 09:17, 6 January 2018 (UTC)
  • No - if we aren't a directory (and we shouldn't be) then we shouldn't have directory pages. We're also not a travel guide of course. Doug Weller talk 14:59, 8 January 2018 (UTC)
  • No, particularly since destination cities frequently change. It is fair to have a list of major hub airports for an airline (eg Delta having Atlanta, etc.) but that probably can be in the article on the airline and doesn't require a list. --Masem (t) 15:03, 8 January 2018 (UTC)
  • No. Unmaintainable and hence useless and even worse: misleading. Staszek Lem (talk) 00:01, 9 January 2018 (UTC)
  • Comment - Well it appears that we have a consensus here against having lists of airline destinations. The next step would be AfD which is going to last another week (possibly more). I feel this should be closed now as the same arguments are going to be repeated in the AfD discussion anyways. - Knowledgekid87 (talk) 16:15, 10 January 2018 (UTC)
Agree that the next step is for this to go to s “formal” AFD... if only to ensure wider consensus and notification. Blueboar (talk) 16:22, 10 January 2018 (UTC)
  • Comment what an odd position to adopt, all of you who said "it's going to be too difficult to maintain", that could apply to any large article of temporally-sensitive data. Moreover, that's why we have templates like {{as of}}. This definitely opens the door to AFDs for articles such as London Buses route 159. The Rambling Man (talk) 16:37, 10 January 2018 (UTC)
That should go too. Its not remotely as notable as London Buses route 161. Only in death does duty end (talk) 17:02, 10 January 2018 (UTC)
Why would it do that? In this case, we are not a dumping ground for travel destinations. - Knowledgekid87 (talk) 17:05, 10 January 2018 (UTC)
There is nothing wrong with article London Buses route 159. Staszek Lem (talk) 18:41, 10 January 2018 (UTC)
  • No Obviously Wikipedia is not a directory; not for collecting indiscriminate factoids; and not a travel guide. I am surprised all these are on Wikipedia. It is problematic to find acceptable sourcing so all these fail WP:N per WP:GNG --Steve Quinn (talk) 19:15, 10 January 2018 (UTC)
  • No Given the ephemeral nature of this information, it is unlikely to be able to be useful. --Jayron32 19:19, 10 January 2018 (UTC)
  • This is the sort of information that is at best moderately useful if we can guarantee its accuracy, and actively harmful if we cannot. We cannot. Use an external link to the airline or airport, as appropriate to the page in question. —Cryptic 19:38, 10 January 2018 (UTC)
  • hell no As above, I can see listing major hubs, in the airline's article, but every destination? A classic example of what WP:NOTDIR was supposed to forbid. Mangoe (talk) 14:38, 17 January 2018 (UTC)
  • No per WP:NOTDIR. Gimubrc (talk) 14:53, 18 January 2018 (UTC)
  • No per WP:NOTTRAVEL. MarnetteD|Talk 20:16, 18 January 2018 (UTC)

Early removal of a merge tag

Are there situations where a {{mergeto}} tag may be removed before the close of the merge proposal?

To me, it's intuitively obvious that the tag and the proposal should come and go together, and stating that at WP:MERGE should be unnecessary WP:CREEP. But intuitive obviousness is often a matter of opinion.

This is currently a matter of contention at Erica Garner, who recently died.

A merge proposal has been open for ​3 12 days and the Opposes have a strong lead. I am abstaining from the !voting as my only strong feelings there are about process. While WP:MERGECLOSE appears to suggest a default duration of 30 days, a A move to close was made at +17 hours based on that lead. Also in dispute is how early the proposal should be closed—I don't think anyone advocates the full 30 days—but I would like to limit this to whether the tag may be removed before the close. If not, I would like to ask whether something to that effect should be added at WP:MERGE.

Those who want to remove the tag say that it is derogatory and/or disrespectful to the recently deceased article subject to advertise to readers that her notability is in dispute. ―Mandruss  10:02, 3 January 2018 (UTC)

The merge proposal is losing 83-17%, having only increased from 72-28% the first time people requested an early closure. It has a large turnout and the discussion is a clear case of WP:SNOW, on what is an article receiving substantial traffic at present. As another editor commented at Talk:Erica Garner: "In this case, the tag is suggesting that this person's life did not matter; that they were a person of no account; merely their father's daughter. This implication seems likely to give offense to the relations and acquaintances of the subject and so it should not be maintained any longer than is necessary. Common decency, as specified by the policy, now requires that the tag be removed."
I would go further and suggest that it is likely to cause obvious, pointless offence to a large proportion of our readership of this article, being that it concerns a prominent figure in the civil rights movement. There is no possible chance of this proposal succeeding at this stage, but this allows for a couple of editors, in the face of overwhelming consensus, to force every reader of this article to see those couple of editors' view about the subject before they get to read our actual article about her. The only argument for doing this is "because we can". Having it up for another week, or two, or three, has zero chance of altering the result - but it means that they force every reader to see what they thought of the subject for that extra bit longer. This disregard for consensus and for at least the spirit of the BLP policy shows the uglier side of Wikipedia.. The Drover's Wife (talk) 10:20, 3 January 2018 (UTC)
This discussion is why I think we should have far fewer maintenance tags (aimed at involved editors) in article space (aimed at readers). Readers with no intention to edit should not be bothered by these kinds of messages that say nothing about the content quality of the article they are reading (in contrast to insufficient sourcing type of messages for example that give a warning about article quality). Arnoutf (talk) 13:04, 5 January 2018 (UTC)
It is simply false to say that The only argument for doing this is "because we can". In point of fact, that is one argument that has not been forwarded. Therefore you're either being intentionally misleading or suffering from WP:IDHT. Likewise disregard for consensus - there is no consensus by any definition I've ever seen. Now I'll leave this to objective outside observers; I didn't come here to continue the debate with you. ―Mandruss  10:35, 3 January 2018 (UTC)
You've argued that because it is a possible interpretation of policy to force it to remain there for 30 days in spite of the WP:SNOW opposition and ethical concerns, it should - that's the only argument you've given. That sounds like a lot like "because we can" to me. I think this is the first time in all my time on Wikipedia that I've ever heard someone try to argue that more than 80% opposition to a proposed merge with 25 people responding isn't consensus for Wikipedia purposes, so that's, uh, a fairly unique take. The Drover's Wife (talk) 10:57, 3 January 2018 (UTC)
(Personal attack removed) I have cleared stated twice[15][16] that I am not opposed to a close on 8 January, 70% short of 30 days. I also stated in the opener here that this thread is not about when to close anyway. It's clear enough that you are not here to debate in good faith. ―Mandruss  11:09, 3 January 2018 (UTC)
I have redacted that gross personal attack. Do not re-add it. ♠PMC(talk) 11:23, 3 January 2018 (UTC)
It was a sincere question, but not essential to my comment and I'll defer to your admin status. ―Mandruss  11:26, 3 January 2018 (UTC)
It's sincerity has nothing to do with offensiveness - questioning someone's mental ability is offensive and a personal attack. Galobtter (pingó mió) 11:45, 3 January 2018 (UTC)
  • No - For circumstances in which a removal of the tag prior to close is proposed (or seems appropriate), a close of the discussion itself is preferable. If the discussion is not sufficiently developed as to facilitate a close, it is not sufficiently developed to allow removal of the tag. - Ryk72 'c.s.n.s.' 11:44, 3 January 2018 (UTC)

The whole issue here was that Mandruss alone was trying to prolong the close, and thus keeping the tag on the article, which gave rise to the above dispute about removing the tag first. The simple alternative to any grand meta-discussion here is that when you have WP:SNOW opposition to an attempt to merge the article of a highly-trafficked article about someone who has recently died, the decent thing to do is to close the damn merge bid (for all the reasons listed) - in which case one never has to argue about getting the tag off the article.

I suspect it is probably a necessary evil to have such a tag in situations where there is a realistic notability dispute, and I agree with Ryk72 on that point. But it's a bit moot: this kind of dispute is only ever going to arise in this way again if someone - as Mandruss did here - tries to prolong a close to keep the tag at the top of the article in a WP:SNOW situation. The Drover's Wife (talk) 11:47, 3 January 2018 (UTC) ────────────────────────────────────────────────────────────────────────────────────────────────────The proposal has been uninvolved-closed[17] and the tag has been properly removed. While I disagree with a close after ​3 12 days regardless of the numbers, I am not appealing it and as I've said this thread is not about when to close. The close statement includes: "... the meta-discussion related to this at WP:VPP#Early removal of a merge tag can be continued". Since I opened this for opinions on the policy question about early removal of merge tags, rather than being dispute resolution for that specific situation, I would like to see this discussion continue to something resembling a community consensus. This is not likely to be the last time a situation like this raises its ugly head.
I continue to disregard attempts by The Drover's Wife to personalize this issue. ―Mandruss  11:51, 3 January 2018 (UTC)

The answer to the meta-situation is pretty obvious, as Ryk72 said above: if there is actually no consensus, it should stay, and if there is a consensus, it should be closed. Attempts to prolong the discussion in a WP:SNOW situation merely in order to keep the tag on should be stomped on. Easy. It can't be separated from what happened here because there's no issue (from any side) unless someone does what you did here. The Drover's Wife (talk) 12:03, 3 January 2018 (UTC)
there's no issue (from any side) unless someone does what you did here. The tag was re-added by at least three other editors[18][19][20] and a fourth editor voiced support for my position on the talk page.[21] That's about the tag removal; on the issue of when to close, I had support from two editors[22][23] including one who does a lot of uninvolved closes. Thus, your attempt to make this appear as if I'm alone in this, with the correct assumption that nobody will take the time to look deeper, is yet another display of bad faith distortion of the situation. In stark contrast, I haven't tried to make it appear that you're alone in your position. If you have any credibility left here, people aren't paying attention.
Further, Ryk72 supported my view, not yours. They clearly said that the tag should not be removed before the close.
Please, can we end this counterproductive personal bickering and get more outside opinions on the policy question?Mandruss  12:50, 3 January 2018 (UTC)
  • If everyone in the Erica Garner merge discussion had accepted that the discussion was an example of a Snow-close then we all could have saved a large amount of time and effort arguing. I'm still unclear as to why Mandruss refused to accept that the approximately 85/15 balance of opinion, from a large number of editors, was not an example of Snow-close? MurielMary (talk) 10:50, 4 January 2018 (UTC)
  • If everyone in the Erica Garner merge discussion had accepted that the discussion was an example of a Snow-close then we all could have saved a large amount of time and effort arguing. Absolutely, tons of time could be saved if nobody ever disagreed on anything. Your point is? The concept that a discussion should remain open for some minimum amount of time regardless of the numbers is not one I invented. That minimum is something about which experienced and reasonable editors can and do disagree. That's what happened here, and it will continue to happen because Wikipedia does not like to put exact numbers in guidelines.
    Anyway, for something like the fourth time here (I've lost count), this thread is not about when to close but about whether the merge tag may be removed before the close. Thanks largely to off-topic comments that people understandably don't care to slog through, we've had exactly one outside opinion. ―Mandruss  16:53, 4 January 2018 (UTC)
    Re. "The concept that a discussion should remain open for some minimum amount of time regardless of the numbers is not one I invented" – in fact it was, invented by you in this particular case I mean, see discussion below and retraction above. The actual guidance, "If there is a consensus against the merger, or if there is no consensus or no discussion and you don't believe that it is appropriate to merge the pages, then please remove the merge proposal tags and, if necessary, close any discussion", has no provision of a minimum amount of time: the minimum amount of time to keep the discussion open only applies when there's a reasonable chance the merge proposal might succeed, which was evidently not the case in the cited example. --Francis Schonken (talk) 13:21, 5 January 2018 (UTC)
  • The "merge" tag on the article should not have been removed until the merge discussion was formally closed, with the closer responsible for removing the tag. I would treat it like an AFD tag - the tag should not be removed until the AFD is closed. --Masem (t) 16:57, 4 January 2018 (UTC)
  • Since the reason for the tag is to solicit participants to the discussion so a consensus can be established, it would defeat the purpose of the tag to remove it while the discussion is still ongoing. The instructions for the {{merge to}} template describe when the tag can be removed; if any additional wordsmithing is desired, it can be done there. isaacl (talk) 17:21, 4 January 2018 (UTC)
  • @Isaacl: Not that I intend to change anything after only 36 hours and three comments (even unanimous ones)—but would the template doc have as much weight as WP:MERGE? ―Mandruss  05:34, 5 January 2018 (UTC)
    • I thought about it, but honestly I don't think anyone disputes the general principle that the tag should remain until the discussion is closed (the objections above are arguing that, in that specific case, the discussion should have been closed), and so it feels like unnecessary effort to expand Wikipedia's guidance on merging further. isaacl (talk) 05:53, 5 January 2018 (UTC)
  • Yes, per the current WP:MERGECLOSE guidance plenty scenarios are thinkable (and have been applied in practice) where a {{mergeto}} tag can be (and was) removed before the close of a merge proposal. Clues in the guidance, e.g. "... and, if necessary, close any discussion" (emphasis added): the "if necessary" indicates it is *not always* necessary to formally close a merge discussion. Example: Talk:Bach-Werke-Verzeichnis#Merge? indicates a merge tag has been in the article and was removed without formal close. --Francis Schonken (talk) 06:32, 5 January 2018 (UTC)
    @Francis Schonken: As you know, consensus is not about raw numbers; if it were, we would vote instead of !vote. In the absence of an uninvolved such as yourself, how is it decided whether a close is needed? If there is some percentage threshold above which SNOW is self-evident, where is that number documented so that we're all on the same page with respect to it? Are we to assume that it's totally impossible for 80%+ of participants to be wrong in their interpretation of vague, complex, nuanced, and self-contradictory policy? Is the "minimum-time-open-regardless-of-numbers" concept something I just invented in your view?
    To be clear, I have no objection to skipping the close when there is substantial agreement that it is not necessary. That substantial agreement did not exist in this case, so the close correctly was not skipped and the tag should not have been removed before the close because 2 or 3 editors felt the tag was disrespectful to the deceased and her family. Guidance should say something like "The tag should remain on the article until the proposal is closed or there is substantial agreement that no close is necessary." ―Mandruss  07:03, 5 January 2018 (UTC)
    This removal of the merge tag (edit summary: "removing merge tag as no consensus reached") was completely conforming to the MERGECLOSE guidance ("There is no required 30-day discussion period. ... if there is no consensus ... and you don't believe that it is appropriate to merge the pages, then please remove the merge proposal tags ..."). The additional "... and, if necessary, close any discussion" is in this case an appreciation left to the one removing the tag. If they don't think the discussion needs a formal close, then they don't. And that's where it should have left mainspace for at least (!!!!) 24H to allow talk page discussion to see if a consensus on re-introducing the tag could be reached.
    The edit that re-introduced the merge-tag a few minutes later was starting an edit war: no consensus to re-introduce the merge tag had been established on the talk page in the mean while. So it is very simple: you can't edit war over the presence of a merge proposal tag in mainspace. And it would be necessary to rewrite the MERGECLOSE guidance to allow such edit-warring. Which is of course not going to happen.
    "Lack of consensus" + "one editor not believing that it is appropriate to merge the pages" is enough to remove the tag, per the current guidance, and that should have been sufficient to prevent an edit war repeatedly (and without diligent talk page discussion) re-introducing the merge tag in this case.
    The rest of your proposal works remarkably less well to prevent edit-warring. --Francis Schonken (talk) 07:41, 5 January 2018 (UTC)
    If your analysis is correct, it's yet another example of a policy so convoluted as to be missed by three uninvolved experienced editors in this thread, and incomprehensible to the average editor, thus ensuring perpetual conflict, edit warring, and time-consuming trips to dispute resolution venues for something that should be able to be handled locally. It's an argument that was not made by any editor at the article, by the way, so none of them were aware of it and understood it either. I specifically asked for p&g support for their actions and got none. Among a dozen or so editors involved in this, including the other three outside commenters in this thread, it appears you're the first who understands this. Do you see any problem with this situation? I sure as hell do, but after over 4 years and 39K edits I can't say it surprises me much. ―Mandruss  08:07, 5 January 2018 (UTC)
    Nah, the guidance is as simple as can be: don't edit-war over the presence of a merge tag in mainspace. If there's disagreement, it takes no more than one person to remove the merge suggestion tag, and that's where things stay in mainspace until if and when a talk page consensus says something different, or sufficient time has elapsed to start a new merge proposal. Nah, the proposal to have a discussion closure every time someone suggests a merge is unnecessary red tape, and has many more levels of complexity than the current all in all very simple rules.
    Yeah sure, experienced editors may fail to grasp the simpler rules while being much, much more experienced in the complexer cases (takes many sorts of people to write an encyclopedia). No reason to make rules more complex in areas where they can be kept simple. --Francis Schonken (talk) 08:31, 5 January 2018 (UTC)
    Call it simple all you want; the bottom line is that it's too complex, too opaque, too inaccessible, or too [fill in adjective here] for 11 out of these 12 editors. The objective has to be a set of p&g that enables average editors to do the right things, most of the time, without consulting the wise men on routine processes, and with a minimum of conflict. I don't see how you can say this approaches that objective. Do you consider me and the others to be anomalies?
    If I really put my mind to it, I think I might be able to understand and absorb your analysis and apply it correctly in the future. The problem is that I had to spend a couple of hours on this page to even get to this point, and there are another _0,000 editors at my level or lower. It would take years to educate half of them on this question alone; in the meantime, we have repeats of this conflict and many others like it, and we continue to bleed good faith editors who are just too damned frustrated to continue, surrendering the project to bad faith editors who don't care much about policy anyway. I remain bewildered that anybody can look at this and say it's the best we can do. ―Mandruss  09:18, 5 January 2018 (UTC)
  • Re. "...WP:MERGECLOSE appears to suggest a default duration of 30 days..." – it doesn't. It explicitly says "There is no required 30-day discussion period". It does not "suggest" the opposite of what it explicitly says. There's no need to make this more complicated than it actually is. --Francis Schonken (talk) 10:23, 5 January 2018 (UTC)
    The word "default" implies "not required". The two statements are therefore not inconsistent. But no matter: In this case I stated I was not opposed to 9 days, and would have accepted even less if not for the New Year's holidays. Your correction does not affect my last few comments above. ―Mandruss  11:28, 5 January 2018 (UTC)
    WP:MERGECLOSE has two "special" rules each involving a 30-day period and a complete lack of objections to the proposed merger; after which it is made *explicit* that no conclusions for a default period can be drawn from these special cases (and certainly not in the case most participants object). So please read: "There is no required 30-day discussion period". Nor 30 days, nor any other period is suggested as a default in the case there is an immediate response mostly consisting of opposes. Not anywhere in the WP:MERGECLOSE guidance. The actual guidance might be easier to parse if not starting from ideas that really aren't there. --Francis Schonken (talk) 12:16, 5 January 2018 (UTC)
    Per my 09:18 UTC comment, this is no longer about my understanding, if it ever was. You're missing the much larger point. If editors should be able to understand the guidance, that doesn't change the fact that they do not—unless we eleven are all anomalies who somehow happened to converge on this case—and the latter is what matters out there in the real Wikipedia world. Something needs to change, and that can't happen if editors like yourself keep insisting that there's nothing wrong.
    But, sigh, this is probably too meta for this page, and I'm not inclined to embark on a one-man crusade elsewhere, so I'm prepared to drop it. If she dies, she dies. Thanks for the convo. ―Mandruss  12:38, 5 January 2018 (UTC)
    Disagree, this is still about your misgivings regarding the guidance. In the OP you posted "... WP:MERGECLOSE appears to suggest a default duration of 30 days ...", which it doesn't – and which steered this discussion somewhat off-topic from the outset. You didn't retract that statement from the OP, so that we could reboot this discussion somewhat less entangled in prejudiced directions. --Francis Schonken (talk) 12:58, 5 January 2018 (UTC)
    Retracted. Effect on the larger issue: none. See ya. ―Mandruss  13:02, 5 January 2018 (UTC)
  • No, especially not for such a bogus reason as a subjective sense that a template announcing a discussion is personally "disrespectful" to the subject. That's utterly ridiculous. Just close the merge discussion (with consensus to merge, with consensus to not merge, or without consensus, which amounts to no merge per the status quo principle). Removin the tag early is half the job, guaranteed to be controversial, and just leads to pointless F'ing drama. Don't do it. If you have consensus to remove the tag, you have consensus to close the discussion. If you're already involved in the discussion, then don't be a WP:JERK and invite dispute about the validity of the close; let someone else deal with it, or again there will be pointless F'ing drama. We have an entire noticeboard for requesting closure, at WP:AN/RFC, and if you indicate that it's a WP:SNOW, then someone will usually close it pretty quickly. Remember, WP:NODEADLINE.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  09:42, 9 January 2018 (UTC)

Article-space template messages should require starting a talk page discussion

Too often I see editors add something like {{globalize}} or {{confusing}} to the top of an article without explaining why and without trying to fix the issues. As a result, the messages are left at the top of the article for months (or years). I believe that for an editor to place a template message at the top of a page, they should have to also create a talk page discussion explaining what needs to be fixed.

I was surprised to see that this policy has not yet been implemented. Further, I can't seem to find any guidelines surrounding the use of these template messages at all. I welcome your thoughts. AdA&D 19:19, 5 January 2018 (UTC)

@Anne drew Andrew and Drew: WP:DRIVEBY says that non-obvious tagging should be explained on the talk page. Is that what you're looking for? RudolfRed (talk) 19:31, 5 January 2018 (UTC)
WP:DRIVEBY is something I certainly agree with, however it is an essay, not a guideline. I would propose a template guideline which states that all newly added cleanup templates must be explained in the talk page. Better yet, promote Wikipedia:Template messages/Cleanup to guideline, and strengthen its language against "drive-by tagging". AdA&D 19:46, 5 January 2018 (UTC)
  • Remember that anyone can start a talk page discussion... even “you”. If someone leaves an unclear “cleanup” tag, and you can’t figure out what needs to be fixed... you can go to the talk page and ASK. Don’t wait for the other guy to do the right thing... do it yourself. Blueboar (talk) 20:11, 5 January 2018 (UTC)
    I'm aware of that. I just think that the onus should be on the tagger to explain their reasoning. AdA&D 21:41, 5 January 2018 (UTC)
  • I would oppose making this a policy, per WP:CREEP. If I can't figure out why a tag has been placed and the editor placing it hasn't made any effort to explain, I just remove it. I've been doing it for eight years, it doesn't seem to have been a problem yet. Ivanvector (Talk/Edits) 20:15, 5 January 2018 (UTC)
    • I agree with your diagnosis, but it is certainly a problem, as there are editors who think that placement of tags is a right, not just another edit that anyone can revert.  There was an RfC on WT:V whose closure basicly concluded that WP:BRD applies to tag placements, [24]Unscintillating (talk) 04:04, 7 January 2018 (UTC)
  • {{globalize}}, {{technical}}, {{coi}}, {{unbalanced}}, {{systemic bias}}, {{unfocused}} and some others have instructions in their documentation stating that the talk page should be used to describe the issues at hand. The way we present this request varies significantly from template to template; maybe it'd make sense to add an encouragement to open a talk page discussion on more templates, or at least to standardize the language a little bit more across more templates. This doesn't require changing policy and it may help increase the amount of actionable information. Warren -talk- 01:01, 6 January 2018 (UTC)
  • Here is another case, in which I reverted with the edit comment "unclear templates" without getting either BRD or any clarification.  In looking at just the COI tag, it has two talk page requirements that were disregarded.  Unscintillating (talk) 04:35, 7 January 2018 (UTC)
Eh, I happened to add {{Globalize/Eng}} at Ordinal number (linguistics) recently (without even seeing this thread). I didn't start a discussion on the talk page, because it seemed really obvious to me: it's a linguistics article about something that's not language specific, yet the article only covers English. I could have started a talk page thread, but I don't know what that would accomplish. And I just don't have the expertise to improve it, myself. So yeah, often times discussions are helpful, but sometimes there's just not much point. –Deacon Vorbis (carbon • videos) 05:11, 7 January 2018 (UTC)
 
I don't see much point in trying to make talkpage explanations "mandatory". It really wouldn't change much. The current situation is that you can just go ahead and remove any tag lacking an apparent purpose, that wouldn't change. Currently the next step is that you can optionally leave a question or notification to that person that you removed the tag... that would change to an optional warning. Currently if someone engages in persistently and egregiously bad tagging, we can topic ban or otherwise sanction them for disruptive editing. That would change to... a stronger basis to topic ban or otherwise sanction them. And I see zero chance we're going to apply swift and firm enforcement on something like this. The proposal here just isn't going to change much. If an article is badly or mysteriously tagged, just remove it. If that editor wants to reassert their tag then they are going to have to show up and explain it (or risk sanction for unexplained editwarring to restore it).
However we could certainly try to make some of the template instructions more emphatic. Instructions on the template-docs aren't as effective as text on the live template. We really don't want to bloat the size of template messages, but templates which particularly suffer from this problem might try to squeeze in something short like "Unexplained tags may be removed", or references to talkpage explanations may use worlds like "need" or "should", or use "must be explained on talk" in conjunction with removal if not explained. Just don't expect or imply that failing to leave a talkpage message might be enforceably-prohibited. Alsee (talk) 09:04, 8 January 2018 (UTC)
  • While people certainly should do this, I don’t believe it should be mandatory. Personally, when I see this and don’t see the problem, I just remove the tag. Beeblebrox (talk) 00:38, 9 January 2018 (UTC)
  • Yup. In a lot of cases the tags are old, the article has been fixed, but no one took the last step and removed the tag. --NeilN talk to me 00:48, 9 January 2018 (UTC)
    • Or the problems are obvious, and don't need a talk page discussion. Headbomb {t · c · p · b} 00:52, 9 January 2018 (UTC)
  • Nah. This would just be an excuse to remove 99% of dispute and cleanup templates.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  09:29, 9 January 2018 (UTC)
  • Oppose- most of the time it's obvious what the tagged problem is from looking at the article. There's nothing to be gained by placing yet another obstacle in the way of content maintainers. Reyk YO! 09:50, 9 January 2018 (UTC)
  • Unnecessary – but if you see a tag and can't figure out what's it's trying to tell, just take it out. Dicklyon (talk) 04:08, 12 January 2018 (UTC)

Frontloading leads of articles on conservative organizations with negative criticism

I've noticed a pattern where articles on conservative/right wing organizations often have lengthy criticism, talk about specific controversies, or labels from their opponents tacked on to the lead while left wing counterparts have more generic descriptions and praise for awards. See Breitbart News, Conservapedia, One America News Network, and Drudge Report talk page for example. Compare Daily Kos, Rational Wiki, Democratic Underground, and Huffington Post.

Some specific examples

The site has published a number of falsehoods and conspiracy theories,[9][10][11][12] as well as intentionally misleading stories.[13] Its journalists are ideologically driven, and some of its content has been called misogynist, xenophobic and racist.

the channel has risen to greater prominence due to its pro-Trump coverage.[7] Robert Herring, Sr., founder and CEO of the network, has ordered producers to promote certain types of content, such as pro-Trump stories, anti-Clinton stories and anti-abortion stories, and minimize stories about Russian interference in the 2016 presidential election.[7]


When you confront editors about this their usual rationale is that everybody agreed with it some day in the past, or that they googled a few links that says what they want and that proves there is an objective consensus for what they're putting in.

I propose that criticism in controversial political articles be preferentially confined to its own section, or if not possible not in the lead, or at the very least some sort of higher standard be imposed on what criticism is allowed in the lead and how its phrased and that editors who want to preferentially frontload conservative organization articles with negative press but not leftwing organization articles provide stronger evidence for their claims than random search engine results. IE just because you can find a link from WaPo and the Huffington Post saying Breitbart News is very mean doesn't necessarily mean its universally agreed on and worthy of being stated as straight fact right at the top and almost the first thing you read about the site on a supposedly unbiased encyclopedia. Jarwulf (talk) 05:09, 6 January 2018 (UTC)

Something like MOS:LEAD? Jack N. Stock (talk) 05:41, 6 January 2018 (UTC)
The issue isn't that the organizations you mentioned are "right-wing", it's that they all actively court controversy, and their chosen methods of presenting themselves result in significant criticism. Wikipedia's article on Cato Institute, for instance, doesn't have the problems you mention because their public statements and publications are significantly less tendentious than Drudge Report. When a subject is mostly notable for its controversiality, then you have to accept that Wikipedia's coverage of that subject is mostly be focused on that. Warren.talk , 06:30, 6 January 2018 (UTC)
That still doesn't meant the lede should be frontloaded with the criticism/controversy around the group prior to the basic facts about the group though the criticism still should be in the lede. This is necessitated by the need to be impartial. How a group is seen by other groups is a matter of subjectivity and should follow want can be objectively stated about the group. (However, I know there are a number of editors that insist that if several media sources critize a group , that should be treated as a fact, which is not how we should work). --Masem (t) 06:59, 6 January 2018 (UTC)

I suggest we all reject participating in politicization here. Any labeling of article-subjects as liberal or conservative is irrelevant. Jarwulf has listed two sets of generic articles, suggesting one set may be written with negative bias and/or other set may written with a positive bias. Wikipedia's NPOV policy is that we summarize what Reliable Sources say about each topic, in rough proportion to significance and coverage of each viewpoint. To support those concerns Jarwulf quoted some content from the first set of articles. The copy-paste includes ref-numbers, however I pulled up the list of sources that those numbers represent:

  • L.A. Times
  • Associates Press
  • NBC News
  • CNN
  • FactCheck(*3)
  • Politifact
  • Snopes
  • Washington Post

If Jarwolf believes those sources are unreliable, or believes they are undue weight and do not reflect prevalent coverage present in a multitude of uncited Reliable Sources, Jarwolf can go to those articles and challenge that content. We have RFCs, other dispute resolution mechanisms, and administrative intervention available if editors are unwilling or unable to respect the applicable policies.

As for the articles which Jarwolf asserts are written with a favorable bias, Jarwolf can to go to those articles and demonstrate a comparable level of critical coverage in a comparable number and quality of Reliable Sources for any content they wish to add. We have RFCs, other dispute resolution mechanisms, and administrative intervention available if editors are unwilling or unable to respect the applicable policies.

There appears to be nothing to discuss here unless and until Jarwolf actually deals with policy issues and addresses sourcing for content they want to add/remove at particular articles.

If the issue turns out to be dissatisfaction with what Reliable Sources are (or aren't) writing about various topics, then that is an issue that we cannot and will not fix on Wikipedia. Wikipedia has a strong and deliberate bias for summarizing what Reliable sources say. Alsee (talk) 09:09, 6 January 2018 (UTC)

Agree with that. Objective criteria should be presented and using reliable sources and especially checking sites like Snopes or Politifact or FactCheck sounds like a good way of going around the business. Wikipedia is not the encyclopaedia of mumbled pleasantries. Noticing things is fine, but that means nothing unless you can show it is something in the real world rather than your own mind. Dmcq (talk) 10:51, 6 January 2018 (UTC)

The reason that Breitbart News' article begins that way is that, whether you agree with them or not, an overwhelming consensus of independent reliable sources describe the site in that manner. Your problem is with the sources, not with Wikipedia. If you believe that all of the reliable sources cited in the lede of Breitbart News are biased, then you are simply editing the wrong website and Conservapedia is thataway --->. We are not here to right the great wrong that you believe exists in mainstream media sources. NorthBySouthBaranof (talk) 19:00, 6 January 2018 (UTC)

As I suspected nobody here has any actual defense other than what I predicted; that a handful of googled citations equals definitive proof of some phantom consensus. Let me do what nobody else here is doing and provide actual specific logical arguments and evidence for my claims instead of mindlessly posting links to generic template guidelines. If I do a google search for "breitbart is a right" vs a search for "breitbart is a far" I get almost double the results. How exactly do the omniscient maharajis of wikipedia KNOW that 'far right' and 'racist and misogynist' are the 'overwhelming consensus' for describing the site? Snopes 'part of the consensus we don't question even if it might be wrong' has an Alexa rank in the 2000s while Breitbart which is not part of the 'consensus' has a rank of 200. 'But oh Breitbart is not reliable! (whatever that means)' Yeah well the omniscient maharajis have no problem packing articles which references from sites which have tons of criticism for bias and flawed reporting and nakedly partisan sources that proudly state their political alignment.
Look I'm not asking for removal of criticism. Or even partisan sources. All I'm asking is that a partisan editor (left or right) be held to a higher standard. Some vetting before being allowed to plant their flag on a article and put 'X is a naughty bad meanie mean dum dumb![1]' as the first sentence just because they found a HuffPo article that says so, and close down all discussion contesting it. Keep statements from openly partisan sources off the lead. Keep criticism off the lead. Directly attribute them rather than stating their insults as fact in the lead. Have some sort of logical basis for determining consensus other than 'HuffPo and WAPO is all I and 70% of editors read so they're the consensus'. I dunno. Do something that will actually make this place's selfprofessed neutrality meaningful. Or don't I guess, I'm just trying to offer some helpful advice. Take it, or leave it. Nobody takes this place's political articles seriously anyways so you are welcome to stay the course and accelerate wikipedia's rightful place in the rubbish bin of 8th grade poly sci teachers Jarwulf (talk) 23:34, 6 January 2018 (UTC)
Jarwulf if as you describe someone puts that kind of criticism in the lead based on just a HuffPo article, you might have to contest it but you should ultimately win. (Unless the article-subject is barely notable and HuffPo is one of the only sources that exist.) There are various policies, guidelines, and ManualsOfStyle that may be relevant, but the main one you are looking for is Undue weight. The lead should summarize the body of the article, and the body of the article should reflect significant and prevalent views present across the available Reliable Sources. The Breitbart article contains at least 215 sources (some key refs contain multiple sources). A significant portion of those sources are devoted to establishing the Breitbart's ideological stance and the widespread critical commentary about it. Controversy and criticism *are* some of the most noted and noteworthy things about Breitbart. If you look at an article such as National_Review, it doesn't have any criticism in the lead. If someone were to add a flame-throwing HuffPo piece to the National Review lead, that would be flagrant Undue Weight. You would be absolutely justified in reverting and citing policy. If the other editor is combative, there's RFCs and other dispute resolution mechanisms which should ultimately result in policy compliance. Alsee (talk) 22:00, 7 January 2018 (UTC)
  • I've been trying to argue what you have been asking for - in that our ledes should progress from the most objective, neutral facts, then into subjective praise or criticism of the topic - to be impartial and neutral. It's not about removing a wide-spread opinion from the lede, but presenting the lede in the order from objective to subjective matters. You see this all throughout most topics on WP (such as highly praised films or books, highly decorated soldiers and officers, proficient athletes and academics, etc.) where the subjective aspects are left for last. The only class of articles where this is completely flipped is anything on conservative/right-wing politics, and it is because of the resistance you speak to. It is claimed "but these people are notable for being bad people", which is not content of issue to include in the lede - the lede at some point needs to ID why the person or group is notable, and for those that are constantly barraged by press criticism, that is it. But it should be after establishing the neutral, objectives facts of the topic rather than frontloading. --Masem (t) 00:30, 7 January 2018 (UTC)
Agreed, this doesn't necessarily have to be a full formal policy change. Maybe just a reminder for overzealous editors. But it appears to be a systematic problem which is why I'm bringing it to general attention here instead of like some people suggested by running around like a hamster trying to convince self appointed lord after self appointed lord of each individual article. I'm not necessarily opposed to 'overwhelming consensus' but if you're going to regularly be stuffing in juvenile insults and tangents about specific controversies disproportionately, in what is supposed to be a generalized descriptive lead, we're going to need a bit more to go on than random hits on a fishing expedition in Google. I raised some points here and so far nobody I've seen has bothered to specifically respond to them, or seem to really care. So, I guess its open season on certain articles and you can tack on any rambling criticism you want at the top in there if you can google it up. Because its the 'overwhelming' consensus and 'self evident reality' cause a majority of editors say so. Whatever, I just offered some suggestions. Jarwulf (talk) 11:49, 7 January 2018 (UTC)
While this sounds plausible, I don't think it is true. If you look at WP articles on pseudo-science journals, for example, I believe you will normally find cautionary labels early in the lede. The same for extreme-left political parties, etc. My suspicion is that some editors only notice the cautionary labels when placed on articles that, by their own individual or fringe POV, they feel should not be so labelled. In those cases (only), such editors appeal for "objectivity" in the lede. Then they use false parallels with HuffPo or WaPo - which operate according to much more conventional journalistic standards - to confuse the issue. ---- — Preceding unsigned comment added by Newimpartial (talkcontribs) 01:46, 7 January 2018 (UTC)

In the words of Stephen Colbert, "reality has a well-known liberal bias". This isn't true in general, but in the world of American politics, it certainly is truer than not. Conservative outlets like the National Review are now the exception, not the norm, especially in the age of Trump. Headbomb {t · c · p · b} 02:12, 7 January 2018 (UTC)

I don't really think changing the policy would be helpful. The lede should follow WP:RS and subjective criticism should probably not be stated as objective fact in any part of the article, but clearly attributed as an expert opinion that is critical. Something like publishing a conspiracy theory would, however, not be a subjective criticism per se, because it should be verifiable - they have either done this or not. The majority view of WP:RS would have to be discussed on talk pages - a policy-based exclusion of anything "negative" from the lede would introduce its own POV and WP:FALSEBALANCE problems.SeraphWiki (talk) 02:40, 7 January 2018 (UTC)
  • (edit conflict) It is true what Alsee has stated. The coverage in the ledes and elsewhere in these these articles is based on the proportion of coverage received in independent reliable sources. Also, the lede is supposed to be a summation of what is in the article. And since these are well developed articles with controversial material, I have to think that what is in the lede is further discussed in the article. Also, I am pretty sure in all these cases, there was discussion and agreement before placing the material in the article proper and in the lede. As stated above, psuedo-scientific topics and extreme-left political persons and parties get the same treatment. There is no single editor with an agenda going around promoting a point of view. Or several editors with an agenda each working on an article, promoting a point of view. ---Steve Quinn (talk) 02:44, 7 January 2018 (UTC)
As an observer from afar I probably shouldn't put my oar in, but from that distance the most obvious point about negativity in the lead of WP articles on US right-wing mouthpieces is that it is not just greater than for their equivalents on (what passes for) the left; it is also greater than for the former mouthpieces of the NSDAP. It would seem eminently reasonable for the lead of the WP article on Völkischer Beobachter to note (with support from reputable sources) that "it published a number of falsehoods and conspiracy theories, as well as intentionally misleading stories. Its journalists were ideologically driven, and some of its content has been called misogynist, xenophobic and racist." But it contains no such health warning. That disparity seems worrying, but it is not an argument for not pointing out -at proportionate length- negative aspects of current publications. Rjccumbria (talk) 03:59, 7 January 2018 (UTC)
It depends on what it is most noted for in reliable sources. As WP:LEAD says we should say why a topic is notable. And if you look at Conservapedia or Breitbart News where the OP specifically went to complain, their leads do describe them as the secondary sources on balance do. Can anyone find a reliable secondary source that has a good word for Conservapedia? IT is notable because it publishes twaddle like that Einstein's Theory of Relativity promotes moral relativism. And is anyone really going to stand up and say Breitbart News is anything but far right and publishes all sorts of fake news? The stories they are notable for have a common theme of being made up or heavily edited and them having to pay out damages. It is what they are notable for. Dmcq (talk) 14:04, 7 January 2018 (UTC)
  • Fixable by applying WP:UNDUE, which means a) removing excessive dwelling on criticism (especially that which is only coming from the far-left quarter) from conservative-subject articles' leads, and b) inserting more mentions of (general and well-supported, not just far-right) criticism into the leads of lefty-subject pages.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  09:29, 9 January 2018 (UTC)
  • Comment -- Hello, I think that the phrase "X organization has caused controversy" is generic. What hasn't caused controversy? Everything has detractors, especially in politics. Our focus should be in improving the descriptions of the respective controversies (who, when, why), not on whether X is considered controversial or not (short answer: yes). --NaBUru38 (talk) 20:28, 18 January 2018 (UTC)

RfC: Is "telenovela" a suitable disambiguator?

Should we allow "telenovela" to be used as a disambiguator? There was recently a discussion at Wikipedia talk:Naming conventions (television)#RfC: Telenovela disambiguation which, despite being fairly thoroughly discussed among a number of topically interested editors, failed to come to consensus, and the closer specifically directed that a broader discussion would be needed to resolve the matter. --woodensuperman 09:15, 9 January 2018 (UTC)

  • Oppose. "TV series" is sufficient. A telenovela is still a TV series. We do not allow other genres of TV series to be disambiguated in this way (sitcom, soap opera, etc, etc), so WP:CONSISTENCY is an issue. This is not sanctioned at WP:NCTV, and despite the recent RfC which resulted in no consensus to add this as a disambiguator, the poorly worded close means that despite there being no consensus to allow this, articles can remain at a title which goes against our naming convention guideline. --woodensuperman 09:15, 9 January 2018 (UTC)
    • Comment. While we're at it, it might be a good time to discuss the use of "miniseries" also. --woodensuperman 09:38, 9 January 2018 (UTC)
  • Oppose per WP:USEENGLISH and WP:OVERDAB. Woodensuperman is exactly right; this would open the door to "Foo Bar (soap opera)", etc., and even to use of non-English labels for these things.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  09:26, 9 January 2018 (UTC)
  • Comment Just to point out that most telenovela have been disambiguated as such for quite awhile. The main argument being that telenovela is a format rather than a genre - the genre being soap opera. We don't disambiguate by genre but we do by format (sometimes). A no-consensus result means that there would be no consensus to change these from the status quo (already disambiguated as telenovela). Only in death does duty end (talk) 09:30, 9 January 2018 (UTC)
I disagree. A "no consensus" close means there is no consensus to change the guideline, and article titles which go against the guideline should be moved in line with it. There has never been consensus to allow "telenovela". --woodensuperman 09:37, 9 January 2018 (UTC)
Guidelines are not binding policy and can (and are) ignored regularly. You would need actual consensus to mass-rename a bunch of articles beyond 'this guideline says so' when they have been stable for a significant period of time. (FWIW I actually think they should be disambiguated as TV series, as the technical differences between tv-series, soap operas, telenovela's are a matter for categorization, not disambiguation) Only in death does duty end (talk) 09:40, 9 January 2018 (UTC)
What Woodensuperman said is absolutely what it means. It is not possible under WP:CONLEVEL policy for the failure of a minor discussion on a backwater page to even come to a consensus, to magically transform into the overturning of an actual site-wide guideline. That's ass-backwards. RM discussions and RfCs about moving articles are the consensus discussions to move the articles, so what you're saying must happen is happening. I.e., you're making a point that isn't a point. Finally, there is no principle that a mistake that has languished for a long time cannot be corrected. We regularly – like every single day – move badly named articles to comply with WP:AT policy, the WP:MOS guidelines, the WP:DAB guideline, and/or the naming conventions guidelines, more often than not via the WP:RM/TR speedy process. PS: Since you actually say you agree with the proposed change, please do not post devil's-advocate stuff like this. It's a waste of other editors' time.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  09:49, 9 January 2018 (UTC)
While I generally agree with you, the main problem is there are already exceptions in the relevant guideline which indicates it is not a hard and fast 'generally accepted' for everything. Just most things. More than a few of the policies and guidelines which include exceptions state that others not listed may exist, because nothing is entirely documented to that level of detail. If the relevant guideline were so hard and fast, a bulk-rename request should have sailed through. That no one attempted it suggests less than absolute confidence. Only in death does duty end (talk) 14:41, 9 January 2018 (UTC)
As I mention above, perhaps now is the time to get rid of the exception for "miniseries" too. "TV series" can work equally well for these, and usage of "miniseries" is not universal, and could be controversial, especially when it is used for non-US shows. --woodensuperman 14:47, 9 January 2018 (UTC)
I would also agree that's probably a good idea. Telenovelas have more in common with miniseries in structure (apart from the obvious one - length) than standard TV-series. And a guideline that doesn't include exceptions is less difficult to wriggle around. Only in death does duty end (talk) 14:51, 9 January 2018 (UTC)
  • Oppose - there is no call for one particular genre to be an exception to a WP:NCTV guideline. The same problem exists for articles named with (anime). Why are these exceptions just because they originate in non-English countries/languages? The argument that this is a "format" vs a genre is flawed as no one can define this "format" in a way that doesn't also fit other (TV series) unless you bring up language, storyline types, or run length - all of which could apply to any other TV series. None of these is sufficient. -- Netoholic @ 10:02, 9 January 2018 (UTC)
  • Oppose per SMcCandlish and Netoholic. Would lead to endless special pleading and wheel warring. James (talk/contribs) 13:47, 9 January 2018 (UTC)
  • No. (This is phrased as a yes/no question, people, not as a proposal to support or oppose). Per our article, similarly formatted shows are called different things in different places around the world. Taking this to the extreme would produce a whole host of different disambiguators for each one, which is silly compared to using what they're all common examples of. –Deacon Vorbis (carbon • videos) 14:02, 9 January 2018 (UTC)
  • Oppose "TV series" is fine, we shouldn't use the show's genre unless all other options are taken (eg two shows, from the same country, from the same year, with the same name, then we'd have to distinguish by their style). --Masem (t) 14:49, 9 January 2018 (UTC)
  • No per others. Same for miniseries, (anime) in MOS:ANIME etc. Genre is vague and creates complexity- having it all as TV series is simple and consistent. Galobtter (pingó mió) 07:30, 11 January 2018 (UTC)
  • No, per discussion above. Although I've been neutral on this, and can see an important cultural component in various usages of the terms, consistency does favor labeling Wikipedia articles on fictional television series with the same descriptor. Article text itself should still allow use of the term, and hopefully no objection to in-text usage will arise based on this RfC. Randy Kryn (talk) 13:08, 11 January 2018 (UTC)
I don't think anyone is suggesting that we stop using it in article text, or indeed as a category name - we happily use "sitcom" or "soap opera" in this way. --woodensuperman 13:55, 11 January 2018 (UTC)
  • oppose my views are identical those already expressed BURLEY-XXII 07:32, 15 January 2018 (UTC)
Other discussion
Although it's been discussed in this RfC, I don't think the use of the term "miniseries" is being decided here. That seems like another discussion, as miniseries has a meaning in English related-but-separate-from "TV series". Randy Kryn (talk) 14:06, 11 January 2018 (UTC)
Agree, let's keep on topic. -- Netoholic @ 04:59, 12 January 2018 (UTC)

Barnstars and wikiproject control

FYI: Pointer to relevant discussion elsewhere

Please see Wikipedia talk:WikiProject Wikipedia Awards#Barnstar bureaucracy

While I posted this notice initially at WP:VPMISC, the fact that this raises questions about WP:CONLEVEL, WP:OWN, and WP:EDITING policies makes me think it should be "advertised" here as well. I'm reminded (albeit the stakes being much lower) of the sharp distinction between Wikipedia talk:Identifying reliable sources (medicine) and Wikipedia talk:WikiProject Medicine. While the wikiproject started that guideline, it doesn't own it, and decisions about it are made by everyone in the community who cares to participate, without having to sign up as a "member" of a club.

I have for years had concerns about the level of bureaucratic control exerted by the awards wikiproject across several awards-related pages that are not under "Wikipedia:WikiProject Wikipedia Awards/...", and their invention (and enforcement by revert) of pointless voting processes about them, also known as barriers to entry. Now they're redirecting the awards talk pages to their own wikiproject talk page, and I think this bears some community consensus consideration.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  11:29, 9 January 2018 (UTC)

Dead mergers

If I propose that articles be merged (as I have at Talk:Pixel density and Talk:MTR Fare Adjustment Mechanism) and (almost) no one ever comments, is the correct procedure to merge the articles anyway, remove the merge templates and close the discussion as "no consensus" (which would be true but next to useless), nominate the smaller article at AfD, or…? Jc86035 (talk) 16:23, 9 January 2018 (UTC)

IMHO just boldly do it yourself, and there's no need to close it - just add a note that you have done so. Galobtter (pingó mió) 16:25, 9 January 2018 (UTC)
Probably the only rule is that there's no need to formally close the discussion. Other that, it's down to common sense. Depending on how well you know the subject area and how confident you are in the need for a merger you can either perform the merger straight away, or try to get more eyes on it: relevant wikiprojects can be helpful, and so can the major contributors of the articles concerned. AfD should ideally be a good place too, but it's likely that the discussion will get drowned in a sea of procedural comments about AfD being only for deletion). – Uanfala (talk) 02:11, 10 January 2018 (UTC)
WP:MERGECLOSE suggests that you can merge if nobody objects within 30 days. It doesn't require that anyone supports the merger proposal, only that nobody objects. Personally, I will wait much longer, but typically more than 30 days makes no difference. If nobody has objected in 30 days, you can be reasonably sure nobody will ever object. You can close the discussion with outcome as merge. Jack N. Stock (talk) 02:25, 10 January 2018 (UTC)
Merge proposals don't get picked up by the article alerts, so depending on how many watchers the articles have and what a proportion of those passing by are likely to comment, there are varying degrees to which the lack of objections can be taken as a meaningful sign. – Uanfala (talk) 02:41, 10 January 2018 (UTC)
So take the BRD approach - merge them; if someone reverts your merge discuss the issue with them (and anyone else who happens to join in). עוד מישהו Od Mishehu 15:09, 10 January 2018 (UTC)

Disambiguation of adjectives: a missing guideline

Please join Wikipedia talk:Disambiguation#Disambiguation of adjectives. Staszek Lem (talk) 00:26, 11 January 2018 (UTC)

In brief: Bayesian econometrics is in Bayesian (disambiguation), but Long bow is not in Long (disambiguation). My guts tell me why this is so, but is this conforming disambiguation guideline? Staszek Lem (talk) 00:29, 11 January 2018 (UTC)

MEDRS

More and more I get worried about the application of WP:MEDRS on articles. That articles about health need to be true and reliable, I can agree with. But I have seen MEDRS being used against articles only remotely related to health, like Organic food. The group mostly using MEDRS is in fact strangling articles with the application of MEDRS, by not allowing any alternative source than "western medical sources", even with exclusion of agricultural universities in case of the prior mentioned Organic food. This is going way over the top and is preventing solid, reliably sourced information to be added to articles.

To my opinion, the working of MEDRS should be severely restricted. The Banner talk 18:22, 11 January 2018 (UTC)

"Severely restricted" so that editors can add poorly sourced medical claims? There are no "western" medical sources (or indeed "eastern" medical sources), just good medical sources and bad ones. Good sources follow MEDRS; bad ones don't. Peter coxhead (talk) 18:34, 11 January 2018 (UTC)
  • When MEDRS is used against the mechanical construction of lightbulbs, you already know which editor is responsible!
MEDRS is terse, and its simple warning against primary sources and the need for secondary review is well-intentioned, but is all too frequently used instead as an excuse for bullying by a handful of editor. WP:PRIMARY covers much the same ground: a single source might be reliable and competent, yet we also need to guard against POV issues. MEDRS though keeps being used to simply strip sources even when the content involved is objective and unchallenged.
And yes, edit-warring is edit-warring, even when the editor is "right". The exceptions for it are narrow and focused on vandalism, absolutely not the sort of ref-weighing content issues here. Andy Dingley (talk) 18:37, 11 January 2018 (UTC)
  • Looking over the history of Organic food, I can't see a single mention of MEDRS in any edit summary since 2015 (and that was by yourself); likewise, looking through the talk page archives I can't see a single mention of MEDRS since this thread three years ago. Why is this suddenly now an issue? ‑ Iridescent 18:50, 11 January 2018 (UTC)
    • Because I gave up on that article... My username is The Banner, not Don Quixote. The Banner talk 18:57, 11 January 2018 (UTC)
    • @Iridescent: Probably this --NeilN talk to me 19:05, 11 January 2018 (UTC)
      • If that's the case, Periodontitis is undoubtedly a medical article by any conceivable definition, so I'm not quite sure what the issue is. ‑ Iridescent 19:06, 11 January 2018 (UTC)
        • That article also shows that by a conflict about MEDRS, there is promptly a tagteam pushing MEDRS. Usually ending in a block for the editor who dares to have a different opinion. The Banner talk 19:14, 11 January 2018 (UTC)
          • That is the same text under discussion on Talk:Periodontitis#Text? Jo-Jo Eumerus (talk, contributions) 19:26, 11 January 2018 (UTC)
            • Assuming the content at Talk:Periodontitis#Text is what's in question, then WP:MEDRS is a red herring; no matter what the topic was, we'd look askance at an editor referencing their own book and linking to a bunch of their own YouTube videos. (The publisher of the book looks at first glance suspiciously like a hyper-fringe outfit, too.) ‑ Iridescent 19:38, 11 January 2018 (UTC)
  • Can we get back to the issue presented at the top: the misuse of MEDRS and a wish to reduce the working field of it? The Banner talk 22:22, 11 January 2018 (UTC)
Please give a specific example of what you object to. Peter coxhead (talk) 23:02, 11 January 2018 (UTC)
I left it for a few year, due to threats of blocks when I continued to be critical. But just a few here: Talk:Organic food/Archive 3#WP:MEDRS, Talk:Organic food/Archive 2#Recent Study from Newcastle, Talk:Organic food/Archive 5 and Talk:Organic milk. The Banner talk 00:24, 12 January 2018 (UTC)

Yup this is the issue right here. A user is trying to push their own hypothesis into Wikipedia based on sources from the early 1900s and Youtube videos they made.

User:The Banner is here helping them[25][26]. Neither one has joined the talk page discussion I started to address the concerns I have raised.

This reply appears to imply that The Banner wishes to push fringe points of view within health care based on very poor references. Their current editing appears to be WP:POINTY from a dispute from three years ago... Not impressed.

Maybe a topic ban will be required. Doc James (talk · contribs · email) 00:39, 12 January 2018 (UTC)

  • The problem with organic food in general is that it has been co-opted by big business and the holistic nutjobs they sell to. 'Organic' food was originally (and still is in parts, but its getting fainter by the year) about the environment. Less pesticides, less intensive farming etc. It had very little to do with health effects on people. Sadly the general public were/are largely not interested in paying more for food that has no benefit to them in the short term, and only benefits the environment in the long term, so in an attempt to make it marketable (and profitable) it was gradually turned into some sort of health food. Which is why now MEDRS has to be applied to it. Because you cant walk into a supermarket without some organic product touting non-existant or poorly researched health benefits. So really, if you don't want organic food to come near MEDRS, I suggest you take it up with organic food manufacturers. Only in death does duty end (talk) 08:51, 12 January 2018 (UTC)

It doesn't matter whether MEDRS applies or not - the principle simply comes from WP:DUE and WP:NPOV. Medical reviews summarize information, allowing us to know what is due or not. Fringe viewpoints are fringe viewpoints whether MEDRS applies are not; sources can't be cherry-picked to push a POV, whether MEDRS applies, and articles on organic food also need to be "true and reliable". Galobtter (pingó mió) 09:01, 12 January 2018 (UTC)

  • The request for a topic ban by Doc James is typical for the bullying you get when you challenge MEDRS.
  • And yes, Galobtter, I agree that organic food needs independent and reliable sources. That is why I am amazed that reliable sources, for instance from agricultural universities, are shot down with a claim that they do not satisfy MEDRS. How many medical magazines will publish about farming? The Banner talk 11:14, 12 January 2018 (UTC)
Agricultural universities may be reliable for the agricultural aspects, not the health aspects. Do you have an example of where an agricultural university was rejected as not MEDRS for a non-medical claim? Only in death does duty end (talk) 11:19, 12 January 2018 (UTC)
Ow, they are there. But with the threat of a topic ban it is loud and clear that the Cabal in unwilling to change even a hairbreadth. Too bad for the reliability of Wikipedia due a systematic bias. I admit defeat against the cabal. The Banner talk 17:09, 12 January 2018 (UTC)
@The Banner: A number of people disagreeing with you is not a Cabal. Considering requesting a topic ban on the basis of your editing behavior is not "bullying". If you do not understand why MEDRS is in place, perhaps it's better to stay away from medical topics. Kleuske (talk) 19:32, 12 January 2018 (UTC)
Start wondering why MEDRS is in place for agricultural subjects and not just for medical subjects. The Banner talk 19:41, 12 January 2018 (UTC)
You still haven't provided an example of MEDRS being applied inappropriately. Natureium (talk) 19:46, 12 January 2018 (UTC)
If an article (on any subject) makes medical claims (such as "this, that or the other is good/bad for your health") MEDRS is applicable. This has been explained before. Kleuske (talk) 13:05, 13 January 2018 (UTC)
Sources can be reliable for one aspect but not for other aspects. Also like I said, DUE and all that - a few papers or whatever from agriculture universities have to be given due weight. Galobtter (pingó mió) 11:35, 12 January 2018 (UTC)
  • All of this is why attribution is so important... there is a HUGE difference between saying “X is good for your health” and “Y claims that X is good for your health”. The first is a statement of fact, and requires a high level of source scrutiny... we need extremely reliable medical sources (as outlined in MEDRS) to verify the statement... the second is a statement of opinion, and appropriate verification does not require the same level of source scrutiny. This isn’t to say that every claim should be included (UNDUE is always a factor in determining what claims should and should not be mentioned)... simply that the type of source that is acceptable for verifying an attributed opinion is different from the type of source that is acceptable for verifying an unattributed statement of fact. An opinion can be total bullshit... and yet may still be noteworthy enough to mention in an article. The key to mentioning opinions is attribution... to make it clear to the reader that the opinion IS just that... an opinion. Blueboar (talk) 14:48, 13 January 2018 (UTC)
Replacing "X is good for your health" by "Y says that X is good for your health" (not "claims" as per WP:CLAIM) requires it to be balanced by "there is no reliable evidence to support this". If there is reliable evidence, then "Y says" isn't needed. My experience is that believers in Y's views usually object to this balancing as much as they do to leaving Y's views out. Peter coxhead (talk) 15:50, 13 January 2018 (UTC)
I think the OP is right that MEDRS has been used in an overbearing way. I've seen this at various herbal and biological articles over the years. The main problem is that there is a certain group that tries to make everything "medical" even when it is not. A medical claim would be that a certain herb cures cancer in humans, yes. But reports that the herb is being investigated as an anticancer drug on a research basis should not be subject to MEDRS requirements. We need merely indicate it is research. Likewise, if the herb was traditionally used as an antipyretic, say, (traditional use of herbs against cancer is at best rare ... not sure if it happened at all) we should not need to cite a MEDRS source in order to tell readers that it was used for this purpose for centuries as prescribed by Aulus Cornelius Celsus or described in the Synoptic Essentials of the Golden Cabinet; we should just print the history without hindrance. If people want to assume the historical use was valid or that the ongoing research will pan out, that's their problem and not ours. Wnt (talk) 22:19, 18 January 2018 (UTC)

Question about WP:VERIFY

I am currently reviewing Kid A for GA. Three sources have caused concern for me in reference to WP:VERIFY. Two radio interviews are given with a date and a station. However, as far as I can see, there is no legal way to verify the contents of these interviews. Can they therefore be considered reliable sources? A similar question is raised about a promotional interview CD that was sent to the music press by Radiohead's record company. WP:VERIFY states that just because a source is hard to come by, it should not automatically be thrown out. However, in this case, I would say that it is borderline impossible for a regular person to come by this source by legal means. A YouTube video of the audio exists, as does a transcript on a Radiohead fan page. I would however consider both of those as not-reliable sources... Any thoughts? Zwerg Nase (talk) 17:37, 14 January 2018 (UTC)

Just for the benefit of the discussion, audio and transcripts of pretty much all these interviews, including the radio interviews, are easily available on YouTube and fan sites. For example, here's the audio of the interview CD mentioned by Zwerg. So in that sense it's very easy to verify them. But yes, I suppose technically these are illegal copies of the original sources, so I don't know what that means for verifiability.
I think you could make the same argument about old magazines - how is someone supposed to verify a claim made in a decades-old magazine without resorting to checking online scans or transcripts? You could track down an old copy on eBay, but that's not always straightforward. Popcornduff (talk) 03:13, 15 January 2018 (UTC)
The Magazine Rack at the Wayback Machine is a useful resource for finding scanned copies of old magazines. It tends to favour computing and gaming magazines, but you can find complete scans of a lot of other stuff. Ensign Magazine (official JC LDS publication), over 1,000 issues of Sports Illustrated, old issues of Playboy, the Austin Chronicle, etc. Warren.talk , 05:15, 15 January 2018 (UTC)
There are libraries and other archives that keep copies of old magazines. Please remember that sources do not have to be online. 86.17.222.157 (talk) 11:48, 15 January 2018 (UTC)
I'm sure that the BBC keeps archive copies of all its broadcasts, at least since the relevant date here, but I don't know if it's possible for members of the public to get to get access to them. I can't speak for KCRW, but would be surprised if it doesn't keep copies, and again I don't know if these can be accessed. 86.17.222.157 (talk) 11:48, 15 January 2018 (UTC)
It looks like it is possible to get access to the BBC archives. 86.17.222.157 (talk) 12:05, 15 January 2018 (UTC)
Another approach for a case like this would to ask whether the information is WP:DUE. If the only source is a radio interview with no known and legal means of verification, perhaps the information should be removed. If no one has thought to publish or refer to the assertion elsewhere, mentioning it may be dubious. Also, people make mistakes when speaking in an interview so facts that cannot be verified elsewhere such as the name of a person or a date should be regarded as suspect. Johnuniq (talk) 22:37, 15 January 2018 (UTC)
This reminds me of an issue we had on the macOS article recently, where one editor was really insistent that the "X" in "Mac OS X" was a homage to the X in Unix. Their source? An opinion segment in a single BBC broadcast. Because of the BBC's international rebroadcast restrictions, I couldn't even verify that source. This is really hard to justify on topics that receive widespread global coverage, like Kid A or Mac OS. Sure, we have the folks at WP:RX to facilitate access to hard-to-reach sources, but it shouldn't be necessary most of the time. Warren.talk , 07:14, 16 January 2018 (UTC)
But... again, the sources in question are extremely easy to verify because they're abundantly reproduced online. The question is whether the fact that listening back to an interview on YouTube is technically piracy means we have to discount it as a source. Popcornduff (talk) 07:21, 16 January 2018 (UTC)
Indeed, I think we have touched upon what we in German call "the poodle's core". I had hoped that there were clear policies regarding such issues, but apparently, there are not and eventually, the decision comes down to me as GA reviewer? Zwerg Nase (talk) 09:25, 16 January 2018 (UTC)
As I'm the guy who added these sources in the first place, I'm biased, so take this with a pinch of salt... but the way I see it, the WP:VERIFY guidelines state "Do not reject reliable sources just because they are difficult or costly to access", and there seems to be nothing else relevant on the page, so I think it's OK. You might want to ask more on the WP:VERIFY talk page, and it seems like it might be a guideline thing to have a decision about for future cases. As for the WP:DUE concern, I see nothing in that guideline to advise against using these sources either: most things mentioned in promotional interviews aren't reproduced elsewhere, that's normal and doesn't discount their reliability. Popcornduff (talk) 09:54, 16 January 2018 (UTC)
Just one quick comment: I brought this discussion here because the WP:VERIFY talk page specifically says not to discuss such matters there. Zwerg Nase (talk) 10:22, 16 January 2018 (UTC)
Good to know! Popcornduff (talk) 11:52, 16 January 2018 (UTC)
The correct place if you have an issue regarding the reliability of a source in context is WP:RSN. Only in death does duty end (talk) 11:48, 16 January 2018 (UTC)
@Only in death: I thought about putting it there, but since I was going for an answer wether there was a particular policy about this, I went for this one. Feel free to move this debate, if you feel it should be over there. Zwerg Nase (talk) 09:50, 17 January 2018 (UTC)

RfC at Wikipedia talk:Manual of Style#RfC: Linking to wikidata

An RfC has been initiated at Wikipedia talk:Manual of Style#RfC: Linking to wikidata. Please comment there, not here. --Francis Schonken (talk) 06:51, 16 January 2018 (UTC)

Question about Manual of Style/Trademarks

I would like to ask for detailed explanation of the following part of the Manual of Style/Trademarks: "Follow standard English text formatting and capitalization practices, even if the trademark owner considers nonstandard formatting "official", as long as this is a style already in widespread use, rather than inventing a new one."

Does it mean that capitalization of trademarks should always follow standard English capitalization rules or should the editor always search what the usage of the trademark is and then decide? Thank you! --Jan Kameníček (talk) 10:37, 16 January 2018 (UTC)

As a general rule, one should start by reviewing how sources independent of the trademark owner tend to refer to the trademark. If there is more than one formatting variant that is widely used, then the variant that most closely resembles typical English formatting should be preferred. Dragons flight (talk) 11:04, 16 January 2018 (UTC)
In other words... we don't necessarily use the trademark's "official" capitalization (as seen on packaging or advertising)... we use whatever capitalization is most commonly used by independent sources. For more on this, see our WP:COMMONNAME policy and the WP:OFFICIALNAMES supplement. Blueboar (talk) 14:25, 16 January 2018 (UTC)
I'd disagree with this interpretation. I'd say that you should start by following the standard English capitalization rules, and use this as long as this is a style already in use elsewhere. We shouldn't necessarily use the most common style. Also WP:COMMONNAME is not relevant, as this is a style issue, not a naming issue. --woodensuperman 15:30, 16 January 2018 (UTC)
I originally understood it the same way as Woodensuperman, but decided to ask. What is more, there are cases when some trademarks are not mentioned by any independent sources (one example here: [27]). Such companies are not notable to have a separate article, but sometimes may be necessary to be mentioned in articles on other subjects. --Jan Kameníček (talk) 21:07, 16 January 2018 (UTC)

Obscene (and irrelevant) trans-wiki results

Seriously?

I searched for "DC Baltimore area". What the hell is this?! Is there no filter at all on the "from our sister projects" results? Given the very obvious risk of finding the search text in a citation to a random adjective?

If we can't filter out obscene trans-wiki results because Wikipedia is not censored, can we at least check that the Wiktionary page title references the search term, and not just some random text somewhere on the page?Chi Sigma (talk) 19:18, 16 January 2018 (UTC)

What is obscene is a matter of opinion. No algorithm can filter based on such highly subject criteria. Ruslik_Zero 20:04, 16 January 2018 (UTC)
A search for one of America's largest metropolitan areas returns a list of places that have been "fuxated" by "niggers", but that's okay because we can just blame The Algorithm? Chi Sigma (talk) 20:19, 16 January 2018 (UTC)
It's obviously horrible language but part of what Wiktionary does is catalogue horrible language. I agree that a mundane search of a common, everyday topic should not return shocking things--see WP:EGG. Do you have in mind what a solution would be? ―Justin (koavf)TCM 20:28, 16 January 2018 (UTC)
Yes, I suggested it above, at the same time as acknowledging that Wikipedia is not censored! Chi Sigma (talk) 20:34, 16 January 2018 (UTC)
You are correct that return is clearly moronic, if it is not intended to be racist, in which case it is racist. Alanscottwalker (talk) 20:42, 16 January 2018 (UTC)
The only *technical* solution would be to remove the quotations from the searched text in the cross-wiki search, and given the way that Wiktionary determines what a quote is ( *# at the beginning of the line, that strikes me as technically difficult and not worth it. Another surprising result... search for "capstan cucumber". Naraht (talk) 21:45, 16 January 2018 (UTC)
I don't believe for a second that that's the only technical solution. If I'd searched for "John Seegentaler" and the suggested Wiktionary entry had been "murderer", someone at Wikipedia would very quickly be getting locked in a room with a copy of Search Optimisation for Dummies. Chi Sigma (talk) 22:06, 16 January 2018 (UTC)
You could try mw:Talk:Cross-wiki Search Result Improvements. I don't know who reads it now. Registered users have the option "Do not show search results for sister projects on the search results page" at Special:Preferences#mw-prefsection-gadgets. I'm not saying it's a good solution. PrimeHunter (talk) 22:57, 16 January 2018 (UTC)
  • This is a valid complaint. Don't start with the not-censored stuff please: that applies to articles, not search. We did not include Commons in search because of things like searching for "fruit loops" yielded (until very recently) a naked porn star taking a bath in fruit loops and milk. Keeping search family-friendly is important, because people expect not to have to see racial obscenities when they are searching for the national capital region of the United States. Given the number of school children who do use this website, that is a very real concern. There is a difference in allowing Wiktionary to document it, which isn't our concern, and making it so unsuspecting readers get it put in their face for no clear reason when they were not looking for it. Prohibiting the former is censorship, removing the latter is giving a damn about our readers. TonyBallioni (talk) 23:09, 16 January 2018 (UTC)
    • There is a meaningful distinction between shock images and shock text. I agree that we should try to control when both appear but it's a much bigger deal if an inappropriate piece of media pops up from commonplace searches versus a word. ―Justin (koavf)TCM 23:27, 16 January 2018 (UTC)
      • Let's be clear what we are talking about: hate speech. There is a big difference between obscenities (I swear like a sailor) and hate speech, and I don't particularly care if the Klan and the neo-Nazis don't think that niggerfuxated isn't hate speech, it is. For those who don't want to click the interwiki link, the English Wiktionary defines the word as: (slang, derogatory, offensive, ethnic slur) Ruined by black people. A hypothetical person of colour (or any person) should not have to worry about hate speech coming up in Wikipedia search results when they search for the Baltimore DC metro area. We should obviously document the word in Wiktionary: that is part of that projects mission. We should also make sure that our readers aren't forced against their will to see something that they wouldn't reasonably anticipate and that is hate speech. TonyBallioni (talk) 23:46, 16 January 2018 (UTC)
        • If we can control the Algorithm, then the solution is to make sure words pulled from Wikitionary are not from that site's category of "offensive terms" (which this one falls into). However, I throw out the case that maybe I was using en.wp's search to find offensive terminology, in such a case, having the current search results that may include offensive words would actually be helpful. The question becomes a balance of being sensitive to readers (I agree, not censorship in this case), and being useful. I don't know what the right answer is. --Masem (t) 23:55, 16 January 2018 (UTC)
          • Agreed, it would be useful if people were searching for an exact match. I think the concern isn't so much this specific case, but what it tells us could also happen. What random search terms are going to bring up homophobic and anti-Semitic slurs? Controlling the algorithm would be the best option, but if that isn't possible, I do think we may need to revisit including Wiktionary in our cross-wiki search results: there is a text/image distinction I'm willing to make, but at some point, the text search result also have the potential to both do wrong by our readers and also to make a PR nightmare, which would not be good for the site. TonyBallioni (talk) 00:00, 17 January 2018 (UTC)
            • The shock value of the word is only half the problem. If you took that screenshot and replaced "niggerfuxated" with its definition "ruined by black people", it wouldn't be an improvement. When a user searches for a concept that could be an article title, and you give them a single Wiktionary entry, what you're saying is "here is Wiktionary's interpretation of that search term". Businesses would pay a fortune to have their web page be the top search result for "DC Baltimore area"! If you were a white supremacist trying to sabotage Wikipedia, boosting "ruined by black people" up the list of search results for "DC Baltimore area" is exactly the way you'd go about it. Chi Sigma (talk) 00:02, 17 January 2018 (UTC)
              • I was literally just thinking this. TonyBallioni (talk) 00:09, 17 January 2018 (UTC)
                • Thank you for reassuring me I'm not being a snowflake! I'm a British non-snowflake though, so I shall be back in 9-10 hours. Chi Sigma (talk) 00:19, 17 January 2018 (UTC)
                  • We are always going to have this problem. As number of user-driven projects across separate servers, it is very easy to inject something COI-ish or POV-ish into a sister project that will show up by happenstance on en.wiki; we do not allow this and take action against those that game the system, but the only checks are human-driven and outside our ability to automatically patrol. It's the unfortunate part of being on an open wiki.
                  • I don't know if it is possible to change the algirithm but lets say it is and we can force it to omit "offensive terms" from wikt. At that stage, we'd need to come to consensus to understand if we put more weight in avoiding having readers hit with inappropriate terms when randomly search, vs the usefulness of finding such offensive terms if purposely research them. The algorithm can't make that determination, it would only follow what orders we give it. That would be a question we should be asked. My gut is that we'd prefer to avoid seeing readers see these bad hits, but we should assert consensus while determining what is possible via this algorithm. --Masem (t) 00:26, 17 January 2018 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────I'm not very technical, but would it be so difficult to make the algorithm:

  1. Get the search result from Wiktionary
  2. Look for the Wiktionary page title in the search string
  3. If it isn't there, truncate the search string at the first space, thus leaving only the first word
  4. Try again? Chi Sigma (talk) 10:58, 17 January 2018 (UTC)
I think this would help not give irrelevant results in wiktionary - even ignoring the offensiveness the result is still utterly irrelevant Galobtter (pingó mió) 11:03, 17 January 2018 (UTC)

Wiktionary is interesting for search indexing. I guess when entering DC baltimore, the result you'd expect on wiktionary would be wikt:Baltimore, but this includes neither DC nor the word Area, thus making it a significantly less likely search result for that particular combination. I think some reweighing needs to occur there. Not sure who is on the search team these days... —TheDJ (talkcontribs) 17:18, 17 January 2018 (UTC)

The search team is still around. I reached out to the PM and engineering manager to see what can be done. CKoerner (WMF) (talk) 19:34, 18 January 2018 (UTC)
Task filed. Looks like this result happens on Wiktionary as well. A possible fix has been proposed, but some testing will need to be done. CKoerner (WMF) (talk) 19:59, 18 January 2018 (UTC)
This is good. I like this. Thank you User:CKoerner (WMF)! Chi Sigma (talk) 21:23, 18 January 2018 (UTC)
Too complicated. There isn't any Wiktionary entry you'd expect to get from "DC Baltimore area". It's not a string that makes sense to search Wiktionary for. Pick one of the three words at random, or don't show a Wiktionary entry, surely? Chi Sigma (talk) 21:07, 17 January 2018 (UTC)
  • This is more WMF doing shit without consensus and fucking things up . Jytdog (talk) 07:30, 18 January 2018 (UTC)
    • Noted. How do you suggest we go about discovering what the consensus is? Does posting something on the policy village pump not constitute a request for comment from which a consensus can emerge (if anyone cares)? Chi Sigma (talk) 07:47, 18 January 2018 (UTC)
    • This was discussed here and only enabled after community consensus, see Wikipedia:Village pump (policy)/Archive 135. —Kusma (t·c) 13:07, 18 January 2018 (UTC)
      • Thanks for pointing me to that discussion! User:DTankersley (WMF) wrote: "We’ve also changed the search query to be title only for the Wikivoyage and Wikiversity projects, rather than full text searches." Is there a reason it's not title only for Wiktionary too? There didn't seem to be any consensus about it in the votes to add Wiktionary results, only a consensus that they should be added. If it's easy to change it to title only, do that! Chi Sigma (talk) 15:34, 18 January 2018 (UTC)
I don't see anything wrong with this search behavior, nor with the output. That happened to be Wiktionary's best effort to find "DC and Baltimore area". It is probably an extremely uncommon thing to have happen. There is a way to fix it: define wikt:BC and Baltimore area for Wiktionary. The fact that it is common enough a phrase to search for means it is common enough a phrase to define, using abundant search results for it.
I realize that Wikipedia is out of step with our totalitarian Masters who rule from the thrones of a few corporations, imposing a Chinese model of the internet protested only, ironically, it would seem, by the surviving organ of the Fourth International. But Wikipedia has the potential to be as obstructive and unchanging as the Socialists, if we try, and to do so would be truly a service to the world. Wnt (talk) 22:28, 18 January 2018 (UTC)

Red links on English Wikipedia

I'm thinking about this for quite a while, finally think it's better to make a discussion. I actively read three different languages of Wikipedia frequently, namely English, Japanese and Chinese. One thing I noticed here is that English Wikipedia seems like to actively avoid using Red links.

Take Japanese game series, The Idolmaster as an example. This game has a major release (more like sub-series) called "The Idolmaster Million Live!", which hasn't have an English article yet. Without much doubt, it is a worth one and will have one eventually, so I won't say it falls into the criterion of "articles that are not likely to be created and retained in Wikipedia". But none of the seven mentions of this name in this article is (red-)linked.

Furthermore, at the bottom of the page, The Idolmaster Million Live! is not even included at all in that {{The Idolmaster}} template. It feels like people intentionally do not include it in the template, despite being a major release of this game series, just because the article doesn't exist (yet).

I understand one example doesn't say much, but it matches my experience here. So my questions, before I go and modify such articles,

  1. is it the correct practice for in-article text to avoid red links, like in case of the example shown above? I read Wikipedia:Red link briefly and my gut says no, but further explanation is welcome.
  2. is it the correct practice to avoid red links by not including non-existing articles at all in the template, assuming the article is important enough for such template? I haven't find the relevant policy page for this.

Thanks! --fireattack (talk) 17:45, 18 January 2018 (UTC)

The correct practice, or at least what I have been doing, is to have red links in article prose but not navigational tools such as the hatnotes, templates, and the see also section. Emir of Wikipedia (talk) 22:34, 18 January 2018 (UTC)

Technical

Archive-date parameter

Edits (rather than the text of edits) being imported into Wikipedias of other languages

(Before the heading title above raises false alarms that my account's login credentials have been somehow compromised, they have not. This issue appears to involve some sort of (new?) MediaWiki importation tool.)

I've been editing Wikipedia for a long, long time, around a decade and a half, during which many articles I wrote or contributed to have been copied and pasted and translated into Wikipedias of other languages. That's fine/great; no problem! I'm happy/delighted to share the results or work product of my edits in other languages! But I just encountered something new and different.

I was just given a welcome message to the Bihari Wikipedia by another user, thanking me for my edits there. This surprised me as I don't speak or understand the Bihari languages, so why would I ever have edited there? So, I checked bh:Special:Contributions/Lowellian. And I recognize those edits: I did make those edits, but I made those edits to the English Wikipedia, not the Bihari Wikipedia!

After poking around the page histories some more (and navigation is difficult due to the aforementioned fact that I don't understand Bihari, so I have to do some informed guesswork clicking on links), for example https://bh.wikipedia.org/w/index.php?title=Template:Countries_and_territories_of_Southeast_Asia&limit=500&action=history, I can see that my edits have been somehow "copied" from the English Wikipedia to the Bihari Wikipedia, and in a way different from a normal page move: normally, when a page is moved, the edits are also moved with it so that each edit still only appears in one page history (unless it was a copy-and-paste move, in which case the text of the edits but not the edits themselves get copied/moved). But this situation appears to be something different, in which my edits are now duplicated so that the same edit history appears on both the English and Bihari Wikipedias, accredited to me.

This is fundamentally different from normal copying-and-translation of articles into other languages since that copies the prose/text (the work product of edits) rather than the actual edit history (the edits themselves). This concerns me because those page histories make it look like I have been editing the Bihari Wikipedia when I have never done so. I don't want, for instance, people complaining to me about edits I made on another-language Wikipedia that I had no knowledge of and did not make. (This is different from normal copying/translation of articles into other-language editions, since normal copying/translation doesn't make it look like I directly edited those other-language editions.)

This all appears to be done by some sort of (new?) MediaWiki importation tool? Can someone in the know provide background for what all is happening here?

Lowellian (reply) 22:42, 12 December 2017 (UTC)

@Lowellian: from bhwiki's log I can see that @SM7: has imported these using the normal transwiki import process. This part is OK and normal. phab:T179832 describes some of the intricicies of imported usernames and how it is being dealt with. — xaosflux Talk 23:32, 12 December 2017 (UTC)
Okay, I don't really understand the issues described in phab:T179832 or whether they apply to this specific case, but maybe someone can at least clear this up for me: if you look at https://bh.wikipedia.org/w/index.php?title=Template:Countries_and_territories_of_Southeast_Asia&limit=500&action=history, some edits are marked "imported>" followed by the username. My problem is that my edits, at least, seem to have been imported without even that "imported>" designation, as if I made the edits directly to the Bihari Wikipedia, when I did not. My edits should be marked "imported>" if they were imported. Is this something that has been looked at and fixed so that it won't happen in the future? —Lowellian (reply) 23:41, 12 December 2017 (UTC)
See meta:Help:Import for the feature. It's from 2003.[28] You can select English as interface language at Special:Preferences at a foreign wiki. This may make it easier: https://bh.wikipedia.org/wiki/Special:Preferences?uselang=en. I don't know when an edit will say "imported>". I haven't seen that before so the anomaly may not be that it's "missing" from you but that it's shown for some of the others. PrimeHunter (talk) 00:02, 13 December 2017 (UTC)
The import process recently got a few enhancements, which is what phab:T179832 was talking about.
When importing edits, the importer must specify the source of the import, and can choose whether imported edits by users who exist in SUL are attributed to the local account for the user or in a fashion like "en>Example" that links to the source wiki from the edit history.
Of course, we also have over a decade of imports that were done under the previous system, where edits were attributed to a local user even if that user didn't exist. A cleanup script is being run on the servers to update the attribution to the SUL user where possible and with a "imported>" prefix otherwise. Since Lowellian's account is in SUL, they were attributed to that SUL account. BJorsch (WMF) (talk) 02:00, 13 December 2017 (UTC)
Thanks for the explanation. In that case, I would like to strongly make the following suggestion: in all cases when edits are imported, including for SUL accounts, there should always be some sort of marker/designation in the page history that the edit is an import in order to avoid the incorrect implication that the editor made that edit directly to that particular language-edition Wikipedia. It is inconsistent and misleading that only some users' imported edits are marked as imported while other users' imported edits are not marked as such, and unfair to make users look like they were spamming English edits onto Wikipedia editions in other languages when they did not do so. —Lowellian (reply) 02:38, 13 December 2017 (UTC)
The best place to make suggestions is in Phabricator. The best indication would probably be a tag. But note there's no way to reliably identify all past imported edits. Anomie 14:07, 13 December 2017 (UTC)
See also Wikipedia:Requests for page importation where we handle requests to copy histories TO enwiki from elsewhere for reference. — xaosflux Talk 23:36, 12 December 2017 (UTC)

Local accounts attached without a visit (and welcomed without an edit)

Today I have been getting Welcomed on both the Latvian and Kazakh wikis. I have never edited over there. I checked my contribs over there, but nothing shows. Could this be part of the same issue [ the previous topic about imported contributions ]? Bit of a coincidence that they both happened today and it has never happened before. — Insertcleverphrasehere (or here) 07:26, 13 December 2017 (UTC)

This is exactly what the previous topic is about. These welcome messages are being triggered by your edits being imported over to other-language-edition Wikipedias without your knowledge, making you look like a new editor to welcomebots, so they start leaving you welcome messages. Everyone complaining here, please add your voice to that topic if you have complaints about how this process is happening. It is wrong that edits from the English Wikipedia are being imported over to other-language Wikipedias without any indication that those edits are imported. —Lowellian (reply) 21:16, 13 December 2017 (UTC)
It happened on the Punjabi Wiki as well... What is going on here? — Insertcleverphrasehere (or here) 10:38, 13 December 2017 (UTC)
Insertcleverphrasehere, local wiki accounts get attached to your global account the first time you visit that wiki while logged-in. All three of lv:, kk: and pa: were attached to your account this morning. On some wikis you automatically get a welcome message the first time you log in. So I don't think this has any relation to the topic of imported edits (and have therefore separated this topic from that section). --Pipetricker (talk) 11:41, 13 December 2017 (UTC)
Turned out I was wrong about that. --Pipetricker (talk) 10:56, 17 December 2017 (UTC)
I wonder why all three happened today though? Must be the rollout of some kind of welcome bot. — Insertcleverphrasehere (or here) 11:47, 13 December 2017 (UTC)
As Pipetricker said: "local wiki accounts get attached to your global account the first time you visit that wiki while logged-in. All three of lv, kk and pa were attached to your account this morning." According to Special:CentralAuth/Insertcleverphrasehere you visited a large number of wikis for the first time today. Many users have been confused by such welcome messages in foreign languages. I have thought about suggesting at meta to ban welcome messages to users who have no edits at a wiki and didn't create the account there but just had it created automatically by viewing a page. PrimeHunter (talk) 11:55, 13 December 2017 (UTC)
Well, I definitely didn't visit all of those wikis today. I did however submit a SQL Query on Quarry for the first time, which required me to authorise it on Mediawiki, which is probably related? Still strange though. — Insertcleverphrasehere (or here) 12:04, 13 December 2017 (UTC)
That's unrelated. I have done no such thing recently and was welcomed on three wikis also. :) --Izno (talk) 12:23, 13 December 2017 (UTC)
Izno, are you saying the SQL query is unrelated to the attachment of a number of local accounts at about the same time, despite Insertcleverphrasehere not having visited those wikis? --Pipetricker (talk) 14:04, 13 December 2017 (UTC)
Yes. --Izno (talk) 15:41, 13 December 2017 (UTC)
Actually, it probably is related. The process of attributing those old imported edits to the SUL account includes creating the local account for the attribution to belong to, which would trigger the welcome message on wikis that do automated welcome messages on account creation. Anomie 14:10, 13 December 2017 (UTC)
Probably related to the topic of imported contributions, that is. --Pipetricker (talk) 16:46, 13 December 2017 (UTC)
I'm seeing this too. Of the 32-and-still-rising wikis that Special:CentralAuth/Cryptic says I attached in December 2017, I've only ever been to two - Gujarati Wikiquote and Persian Wikivoyage, and those only afterward, because I can'tcouldn't get the notifications for the welcomebot messages to go away no matter what I try. —Cryptic 14:50, 13 December 2017 (UTC)
(In case that crops up for anyone else - what finally worked was logging in directly on those wikis and checking off the notification at Special:Notifications, not just the dropdown on the sidebar.) —Cryptic 15:21, 13 December 2017 (UTC)
I also got two or three notifications. Emir of Wikipedia (talk) 14:55, 13 December 2017 (UTC)
CentralAuth shows many accounts being added. Emir of Wikipedia (talk) 15:01, 13 December 2017 (UTC)
I notice now that ilo.wikipedia.org was attached to my account tonight, when I was asleep and my computers were turned off. It's not in my browser history previous to that, and I have no contributions there (and have received no welcome). --Pipetricker (talk) 15:10, 13 December 2017 (UTC)
My wuu.wikipedia account was created 45 minutes ago when my computer was turned off. There is clearly some current process creating accounts at other wikis without user action, maybe releated to work on phab:T179832: "Handling of imported usernames". I don't currently have edits registered at wuu:Special:Contributions/PrimeHunter but maybe there are old imported edits somewhere which have not been added to my contributions. PrimeHunter (talk) 16:05, 13 December 2017 (UTC)
Yes, there is some current process, as I stated in the section above. See phab:T181731 for the task about it. I note that the script is already done with all the "small" wikis. The wikis still in progress or pending are dewiki, enwiki, eswiki, fawiki, frwiktionary, hewiki, huwiki, itwiki, jawiki, kowiki, metawiki, nlwiki, nowiki, plwiki, ptwiki, rowiki, ruwiki, svwiki, thwiki, trwiki, ukwiki, viwiki, wikidatawiki, and zhwiki. BJorsch (WMF) (talk) 00:40, 14 December 2017 (UTC)
If the script is still pending for larger wikis, then those future runs should be stopped and held off until the problems people are complaining about are fixed. As a starting point, per User:Anomie's suggestion above, it should tag imported edits of SULs as imports instead of misleadingly implying that they were normal edits to Wikipedias of that particular language-edition. —Lowellian (reply) 06:33, 14 December 2017 (UTC)
Something should be done. See Wikipedia:Village pump (miscellaneous)/Archive 57#Rogue bot or what on other language wikipedias where I raised this. Andrewa (talk) 10:18, 14 December 2017 (UTC)
I see those things as honestly unnecessary. It causes a one-time notification on a per-wiki basis where any of your edits have been imported. Given that there are only 20 wikis left, spending time now would only prevent finishing the task while waiting for the extra work that is already planned-for down the road. --Izno (talk) 12:26, 14 December 2017 (UTC)
The problem is not really the welcome notifications. That's just a side effect / symptom of the ultimate cause and real problem, that we are being attributed, without our permission, to edits that we did not make. —Lowellian (reply) 20:58, 14 December 2017 (UTC)
We made our edits to articles which according to the licences we agreed to can be copied provided they are attributed. So it seems to me we agreed to the copies being attributed to us. (Maybe I misunderstood what you mean, but any way if it isn't a technical issue the tech Village pump isn't really the place to discuss that.) --Pipetricker (talk) 23:26, 14 December 2017 (UTC)
Attribution has multiple components: who wrote something, what was written, when it was written, and where it was written. The problem is that imports without tagging misrepresent one of those components: where it was written. These attributions aren't accurate because they are edits made to a specific wiki that are now being attributed as edits to a different wiki. And this is certainly a technical issue: it started out as a technical question asking why certain unusual behavior was being noticed, and it has continued as a technical discussion that includes how to, on a technical level, get those edits properly attributed; see the comments below where Xaosflux works out a technical solution to add tagging. —Lowellian (reply) 23:40, 14 December 2017 (UTC)
When you make an edit, above the edit box there is a notice containing the sentence "Work submitted to Wikipedia can be edited, used, and redistributed—by anyone—subject to certain terms and conditions." So by making the edit, you implicitly gave permission for reuse. Checking those T&Cs, I see that attribution allows several alternatives; one of them is "or c) a list of all authors". By crediting each individual edit to the person who made that edit, even if that edit was on another wiki, sufficient attribution is given. --Redrose64 🌹 (talk) 11:21, 15 December 2017 (UTC)
No, it isn't, and the legal language being quoted here only says that reuse and redistribution is allowed with proper attribution, which actually supports my point. Wikipedia allows reuse and redistribution with proper attribution, and the problem here is that the attribution is wrong. Redistribution copies text without claiming that the text was originally written directly to the copy. An attribution that claims someone wrote something somewhere that they did not write it (directly to the copy, instead of somewhere else that is then reproduced by the copy) is a fundamentally incorrect attribution, particularly when, as in this case, the copy is only a partial, non-identical copy, being in a different language. Copying over text from one wiki to another is not the same thing as claiming someone wrote directly to a wiki that the person did not. —Lowellian (reply) 22:32, 19 December 2017 (UTC)
  1. I see you have twice listed four alleged requirements for proper attribution. The policy at Wikipedia:Copyrights#Re-use of text says that attribution under CC-BY-SA has exactly one requirement, namely that you must "provide credit to the authors". It further says that "a list of authors" (even if just plain text), is adequate. Do you believe that the policy is wrong? Can you find anything in Wikipedia:Text of Creative Commons Attribution-ShareAlike 3.0 Unported License that requires, for example, that attribution include "when it was written"?
  2. Why does it actually matter to you that your revision has been copied from the enwiki database over to another one, without saying "copied from this other database" on it? Do you think that someone (who?) will think you've done something disreputable, as a result of omitting such a label? If you're familiar with the 5 Whys analysis, then I'm very interested in the "fifth why", or the underlying problem.
WhatamIdoing (talk) 20:19, 20 December 2017 (UTC)
Exactly, attribution must "provide credit to the authors". That is the problem: when a credit claims someone wrote something somewhere that they did not write it, then that credit is wrong, since the actual editor is the import script, not the person claimed by the import script. Consider the following example: Alice adds the text "lorem ipsum foobar" to an article. Bob copies that "lorem ipsum foobar" text and then pastes it into another article. Alice may be the originator of the text, but the edit history would correctly show Bob, not Alice, as the editor who added it to the second article. If that text is disputed on the second article, then Bob, not Alice, is accountable for adding that text on the second article. But here, the import script is breaking that standard and instead giving the false appearance that Alice was the editor who added the text to the second article, so that Alice becomes the person who is then held accountable.
False attribution is false attribution; it should be corrected without any further justification being needed. I would think that accuracy and truth are fundamental to the goals of Wikipedia as an encyclopedia. That said, at the very least, these wrong credits also give the false appearance that the author is spamming a wiki with text in the wrong language for that wiki. On top of that, different wikis have different stylistic guidelines regarding things like formatting or titling conventions. This gives the false appearance that the author is ignorant or willfully ignoring those guidelines and conventions. Furthermore, what if text added is controversial? The author could then potentially be accused of, for example, POV-pushing on a wiki that the author has never even edited.
Lowellian (reply) 22:03, 20 December 2017 (UTC)
Is there an example of "false attribution"? You might copy the URL of a diff from a history page on another Wikipedia. Lots of fake books are sold by scammers who have copied various articles. They usually include a list of authors from the history pages to comply with the re-use procedures, so your user name may be printed by them. It's not false attribution. Johnuniq (talk) 23:45, 20 December 2017 (UTC)
Let's have a look at a page that Lowellian created - Template:Undated (Revision history) and the same at bh.wikipedia - bh:टेम्पलेट:Undated (Revision history). Other people made edits, and checking the lists together, there is a remarkable correspondence, apart from one or two users like Enterprisey / APerson which can be explained as a username change back in May 2016. Oh, I see that I'm in both lists too. Did I make this edit? There's no denying it, guilty as charged. Did I also make this edit? Well, it says that I did, but I don't recall ever making that edit on that wiki. However, if that edit is going to be credited to anybody, I'd rather that it was credited to me and not to somebody else pretending that it was their idea. Am I kicking up a stink? No. --Redrose64 🌹 (talk) 23:57, 20 December 2017 (UTC)
If these attribution issues don't bother you, that's fine, but please don't just dismiss others' concerns as "kicking up a stink". I'm not the only one who has raised concerns about the behavior of these imports. Why is it so terrible to have an imported edit be credited to both the original author and the import script via an automated tag? Automated tagging doesn't hurt you in any way, while it improves the situation for those who do care about proper attribution. That's all I'm asking for: that the import script should place a tag indicating, in addition to the original author of the text, that the edit is an import, so that there is a way to distinguish between edits made directly and edits that are imported. —Lowellian (reply) 22:49, 21 December 2017 (UTC)
Do you see the imported edit as saying not only "Lowellian wrote this", but actually "Lowellian personally placed this content on this wiki"?
I don't think that's what's intended. The point is to identify who owns the copyright, not which software database you originally placed the content in. (In your example, the copyright holder would be Alice, not Bob; if Bob copied Alice's text from one article to another, then Bob needs to include an edit summary that identifies either who originally wrote the text or which article it came from). WhatamIdoing (talk) 18:02, 21 December 2017 (UTC)
Having the implication be "this user personally placed this content on this wiki" is not intended, but it is what is happening. That is why it is so important to have some sort of tag indicating that it's an import rather than something written directly. —Lowellian (reply) 22:49, 21 December 2017 (UTC)
Who do you think interprets it that way? Not you, of course, because you already know that's not what happened. Not the admin who imported it, or the regulars at any wiki where importing edits is typical, because they already know how it works. So who do you think would be both aware of these imported edits (i.e., not >99.9% of readers) and honestly confused by it? WhatamIdoing (talk) 01:28, 22 December 2017 (UTC)
The only reason that I even know about these imports is because of those welcome alerts that drew me into this issue. I've been an admin over a decade and still didn't even know about of this import mechanism until I started asking questions in this discussion, which makes it very likely that >99.9% of editors aren't aware there is an import mechanism and upon seeing those untagged edits while examining edit history (which will become ever more common as those wikis grow in the future and more and more editors join and edit) would think they were regular edits and not know that they were imports. This issue is fresh in the minds of the editors here in this discussion right now, but we cannot expect editors outside this discussion to be aware of it years from now. That's why we need a tagging mechanism, so there will be not be any long-term future confusion. —Lowellian (reply) 23:01, 22 December 2017 (UTC)
If you're a regular editor at a wiki where this is done, then you will have seen this in dozens of articles at your wiki. If you don't know, you'll ask, and one of the other regular editors will tell you.
This has been done for years at the German Wikipedia. It looks like you've got about 10 imported edits there for every "real" one you've made directly. The numbers are very similar for me. Apparently, neither of us have ever been asked about those imported edits. I don't think that I've ever seen a question or complaint about an imported edit, and I assume that's true for you, too, or you'd have already known that it was possible to import edits. I therefore think that it's reasonably safe to assume that the likelihood of some hypothetical future editor yelling at us for doing something "wrong" on another wiki is pretty close the actual experience of it never having happened before in all these past years. WhatamIdoing (talk) 07:10, 23 December 2017 (UTC)
Actually, that you're saying that this has been done for years at the German Wikipedia actually raises another issue about there being no way from the edit history to tell when the imports were done. But to get back to the original issue, only a very small number of my edits have thus far been imported to the German Wikipedia, concentrated on a few articles. It is not reasonable to conclude from a small number of imports that that there aren't going to be complaints as the number of imports grows. And I will reiterate that fundamentally, attribution should be correct without needing to be justified. Tagging imports helps the situation for those of us who care about this attribution issue and has no effect on those who do not care, so there's no reason not to do it. —Lowellian (reply) 17:22, 23 December 2017 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── You've had about 200 edits imported to the German Wikipedia so far, which the median editor would likely not describe as a small number, and about as many again across some other wikis (one at tewiki, two at arzwiki, three at gdwiki, orwiki, and lmowiki, six at mlwikisource, eight at hiwiki and simplewiki, 10 at elwiki, 12 at the testwiki, 15 at maiwiki, 20 at bhwiki, 24 at knwiki, 34 at mlwiki, and 52 at the English Wikibooks, for anyone who's keeping count).

And, as the edits are attributed to you, I suggest again that the attribution is already correct. It appears to be your personal preference for attribution to say which wiki you happened to be using at the time your original edit was saved, but I have found no actual requirement to do so. I'll cheerfully admit that I'm wrong on that point when you quote me a line from the license that says that attribution must include information about which sub-domain of which website you first posted your copyrighted content to, rather than just your name.

This is where the disconnect seems to be. You seem to have gotten the idea that there is only one "correct" way to provide attribution, and that this One True Way™ requires four specific details, and the current system provides only three of them. I can find no source that supports your belief that anything more than your username is required. For that matter, I can't even find out whether your alleged requirement of "where it was published" refers to the physical location where it was published, the legal/copyright location where it was published, or the name of the larger work that it was included in. (There is, after all, a big difference between "printed in China", "published in the United States", and "published as part of the Anthology of Something", and (given the realities of printing costs) all three of those might be simultaneously true for any given work.) So at the risk of sounding rather Wikipedian about this, please cite your sources. I've cited mine: the license doesn't mention any requirement beyond identifying (in some fashion) the human who originally created and licensed the work in question, and which work is so licensed. WhatamIdoing (talk) 03:49, 27 December 2017 (UTC) ────────────────────────────────────────────────────────────────────────────────────────────────────

The sources you cite do not support the argument that untagged imports are providing proper attribution. You've cited a license that says that for redistribution, credit must be provided to the authors. But this isn't a simple case of redistribution, and credit has not been provided to the authors. Redistribution should not change the meaning of the underlying text; if it does, then it is not just redistribution, but new authorship. Let's say Alice adds to the article on the planet Earth the text that "The subject of this article is the third planet from the sun," a true statement. Bob copies that same exact text ("The subject of this article is the third planet from the sun") to the articles on Pluto and on mathematics: those statements have now become, respectively, false and absurd. Should Alice be held accountable as a liar or vandal for text that she originated but whose meaning Bob altered by placing it on a different article? No.
Is Bob or Alice the author of that text on Pluto or television? It is at least as much Bob as Alice; Alice may have originated that text, but by placing that text in a different context that changes its meaning, Bob has also become an author. Similarly, since these import scripts are copying text to different articles in different contexts, the import scripts are also an author, and the attribution is wrong when it only credits the originator of the text, since the text no longer has the same meaning in this different context. This is why imports need to be tagged as such for proper attribution.
Lowellian (reply) 00:51, 30 December 2017 (UTC)
Again: Where are your sources, the ones that allegedly support your claim that "Lowellian wrote this" (complete with a link to your account, so that everyone knows which Lowellian we're talking about) does not "provide credit to the author"? I see repeated assertions and a whole lot of IDONTLIKEIT, but I also see zero sources behind those assertions. Can you please provide any (single) plausibly reliable source to back up your personal opinion? WhatamIdoing (talk) 20:06, 2 January 2018 (UTC)
I have absolutely provided a source: the license, which requires credit be provided to the authors. Where are your sources, the ones that allegedly support your claim that the entity posting an edit is not an author? I see repeated assertions and a whole lot of IDONTLIKEIT, but I also see zero sources behind those assertions. Can you please provide any (single) plausibly reliable source to back up your personal opinion? (Note that, for the previous last two sentences, I just reused your words in a different context, that of my argument. In the edit history of this page, this reuse of words is attributed to me, not to you, because their context has been altered as part of this comment that I am posting, demonstrating the principle in question: the editor is an author.)
I don't think you and I are going to reach agreement on this issue, so let's just agree to disagree, since the debate is academic at this point, given that Xaosflux provided below a solution to tag imports.
Lowellian (reply) 20:56, 2 January 2018 (UTC)
I'm still looking for the part in the license that says "It's not credit to the author if you don't identify the location". The fullest description of what it means to give "credit to the authors", to quote section 4(c) of the license, says: "You must ... provide, reasonable to the medium or means You are utilizing: (i) the name of the Original Author (or pseudonym, if applicable) if supplied, and/or if the Original Author and/or Licensor designate another party or parties (e.g., a sponsor institute, publishing entity, journal) for attribution ("Attribution Parties") in Licensor's copyright notice, terms of service or by other reasonable means, the name of such party or parties; (ii) the title of the Work if supplied; (iii) to the extent reasonably practicable, the URI, if any, that Licensor specifies to be associated with the Work, unless such URI does not refer to the copyright notice or licensing information for the Work; and (iv) , consistent with Section 3(b), in the case of an Adaptation, a credit identifying the use of the Work in the Adaptation (e.g., "French translation of the Work by Original Author," or "Screenplay based on original Work by Original Author")."
Notice that dates are not mentioned in this definition of what it means to give credit to the authors. Notice that locations are not mentioned in this definition of what it means to give credit to the authors. Notice that websites (URIs) are encouraged but technically optional in this definition of what it means to give credit to the authors. I simply cannot find anything at all in here that supports your claim that there's been a license violation if someone imports your work without adding a note that says "and he posted it to the English Wikipedia first". WhatamIdoing (talk) 17:44, 12 January 2018 (UTC)
@WhatamIdoing: If you're going to try to restart a debate 10 days later, after not replying within that whole time, on a discussion page that receives many, many edits on other topics, at least give me a courtesy ping. After over a week without a response, I thought we were done here, but I guess not. From now on, whenever I post in response to a comment of yours here in this topic, I will give you a ping. Please do the same for me.
That citation you keep repeating does not support your point and is in fact contrary to it, since it requires credit for the authors. Nothing you wrote shows that the entity posting an edit is not an author. And license aside, it is against the ethos of Wikipedia to omit authors, give a misleading credit that implies someone edited an article they did not, and alter the meaning of a person's words while still attributing it to them by reposting those words in a different context.
As I said previously, let's just agree to disagree, since the debate is academic at this point, given that Xaosflux provided below a solution to tag imports.
Lowellian (reply) 20:54, 13 January 2018 (UTC)
What exactly do you mean by your claim that authors are being omitted by Special:Import? Your complaint above is that "edits are now duplicated so that the same edit history appears on both the English and Bihari Wikipedias, accredited to me" (emphasis added). You've said that you're actually getting credit for the work, and you're unhappy about that.
If you read the license above, what constitutes "credit" is spelled out in numbered detail:
  1. name of author [NB: not full identity – just the name],
  2. title the author gave the work (if any),
  3. URL (if reasonably practical), and
  4. acknowledgement of any subsequent changes.
Which part of those four numbered requirements do you claim is being omitted here? (This isn't entirely academic, because the solution below is not going to work in every case.) WhatamIdoing (talk) 23:47, 15 January 2018 (UTC)
@WhatamIdoing: You're just repeating arguments already made earlier which I've already rebutted. I don't want false credit for work/edits that I did not make, and the import mechanism, as the editor, is the author being omitted. I've already stated that I'm satisfied with Xaosflux's solution. So I don't know why you're continuing to extend this debate: what actionable technical change are you wanting to happen? —Lowellian (reply) 02:17, 16 January 2018 (UTC)
I think I'm trying to figure out why anyone would (apparently) think that a piece of software can be an author of anything. I cannot understand why anyone would think that merely copying something from one place to the other, with zero changes, would make either the file-copying software or the person who did the equivalent of typing cp file.text copy.txt, become an actual author of the original work. AIUI copyright law simply does not work that way. A person cannot become an author of a work merely by copying someone else's work. WhatamIdoing (talk) 17:48, 17 January 2018 (UTC)
I'm trying to figure out why anyone would (apparently) think that falsely naming a person as an editor is okay when the person didn't make the edit and has never even been involved with the wiki. I cannot understand why anyone would think that it is okay to alter the meaning of someone's work and then hold them responsible for that altered work with which they had no involvement or even awareness. We're not getting anywhere, and there doesn't even seem to be any actionable technical change you want, so let's just agree to disagree and let this debate end. —Lowellian (reply) 00:08, 18 January 2018 (UTC)

Tagging imports

There's no way to reliably identify old imports to tag the edits, so that's not going to happen. The unexpected creation of accounts should be mostly done since most of the wikis are done. Anomie 13:56, 14 December 2017 (UTC)

But I'm not asking to identify old imports to tag the edits. I'm asking that future imports should tag imported edits as they are being imported. —Lowellian (reply) 20:56, 14 December 2017 (UTC)
@Lowellian: See the history of User:Xaosflux/Sandbox3z (for enwiki) and test2wiki:Male user:Xaosflux/Sandbox3z (for a remote wiki) for how NEWLY imported pages will appear in histories. Does the > identifier satisfy what you are looking for? — xaosflux Talk 22:18, 14 December 2017 (UTC)
@Xaosflux: Yes, that's great, thank you so much, that's pretty much exactly what I'm looking for! :) I don't know how involved you are in the process of these Wikipedia imports; are you in position to actually get that change done immediately for all future imports? —Lowellian (reply) 22:41, 14 December 2017 (UTC)
@Lowellian: I'm not working on the ticket, so here's the situation: any newly imported revisions will follow that already - its already live. The problem that you are seeing is that pages that were imported to projects previously have no information stored to change them in to this new style. — xaosflux Talk 23:20, 14 December 2017 (UTC)
@Xaosflux: Given the lack of stored information on previous imports, I see the difficulty there and am satisfied as long as these identifiers apply to all future imports. But I want to ask for clarification on something: these identifiers will apply to ALL future imports, including imports of edits from SUL accounts, right? Because that was the previous issue: imports of edits of non-SUL accounts were already being marked with an "imported>" identifier before the username, but edits of SUL accounts were not marked/identified in any manner. —Lowellian (reply) 23:52, 14 December 2017 (UTC)
@Lowellian: unless the software changes again in the future, then yes that is the plan for all imports going forward as far as I know, I think it is a good thing. The problem with the other edits is they USED to say your name on them, but in the database they didn't reference your userid, some of these appear to be resolvable, but many were not - in the database cleanup they are now saying "import>NAME" instead of just "NAME", because there is no way for them to know if it should be en:NAME, or es:NAME, or fr:wikisource:NAME, etc. For edits that did match a SUL account from the point of view of the destination wiki they already did match your SUL ID and there is nothing to do. — xaosflux Talk 03:56, 15 December 2017 (UTC)
@Xaosflux: Unless the person doing the import checks the "Assign edits to local users where the named user exists locally" checkbox. If they check that box, then SUL accounts will be attributed to the local name as was done by the maintenance script. As I told Lowellian in this edit, feature requests are better made in Phabricator than by continuing to demand changes here. Anomie 15:10, 16 December 2017 (UTC)
@Anomie: thanks for the clarification. I wasn't demanding anything, but will open a feature request to include an edit type identifier. — xaosflux Talk 15:57, 16 December 2017 (UTC)
See phab:T183061. — xaosflux Talk 16:10, 16 December 2017 (UTC)
  • I can see how the welcome notification when you haven't visited the wiki is annoying. There is no moral or legal obligation to "fix" anything in regards to attribution of your edit. Lowellian: Please see Wikipedia:Copying within Wikipedia. — Preceding unsigned comment added by Killiondude (talkcontribs) 00:05, 15 December 2017 (UTC)
    • It's annoying, confusing, unnecessary and just plain bad design. As is using a lonely bullet point for emphasis. Bullet points belong in bulleted lists. Andrewa (talk) 00:21, 15 December 2017 (UTC)
      • Thank you for your input. Killiondude (talk) 00:50, 15 December 2017 (UTC)
The normal process of copying within Wikipedia attributes that copying, within edit history, to the editor who was actually doing the copying. These imports are copying while attributing the copying to someone who didn't do the copying, to a wiki that they didn't edit. To repeat part of what I wrote above, attribution has multiple components: who wrote something, what was written, when it was written, and where it was written. The problem is that imports without tagging misrepresent at these components: who wrote it (since it is really the import script copying over what someone else wrote rather than that person writing it directly) and where it was written. These attributions aren't accurate because they are edits made to a specific wiki that are now being attributed as edits to a different wiki. —Lowellian (reply) 01:03, 15 December 2017 (UTC)
Regardless, the way it's happening is a confusing and annoying mess. The "welcomes" in unintelligible tongues of men and angels (for all the good they do) are just a symptom.
The problem appears to be, these so-called attributions are undecipherable. If this were not the case, the scripts would not have such problems. And since attribution is required, this is serious. Andrewa (talk) 01:46, 15 December 2017 (UTC)

Auto-created local accounts though no imported contributions

Here's what I haven't yet understood about this:
So, on wikis where articles previously have been imported, local accounts are created in order to attribute the contributing users. But most or at least some of the newly created accounts that have been reported in this thread have no contributions! Are those accounts just a side effect with no big significance (other than causing annoying welcomes and uncertainty)? Or do they reflect that contributions by that user have been imported, but the details have somehow been lost and won't therefore appear in the contributions list? --Pipetricker (talk) 10:09, 15 December 2017 (UTC)

This recent comment by jhsoby at phab:T181731 seems to say it's basically a side effect, related to Wikidata. (@Anomie) --Pipetricker (talk) 10:38, 15 December 2017 (UTC)
This comment is probably more relevant.  BTW, for some reason your ping didn't work. Possibly because the edit edited another line in addition to adding a comment. Anomie 15:15, 16 December 2017 (UTC)
I don't see how that comment is relevant: I didn't mean to ask about edit counts, but about why for example ilo:Espesial:Contributions/Pipetricker and wuu:Special:用户贡献/PrimeHunter have no contributions listed, when those local accounts were created by the maintenance script. --Pipetricker (talk) 09:59, 17 December 2017 (UTC)

Information vs text

The issues raised at Wikipedia:Village pump (miscellaneous)/Archive 57#Rogue bot or what on other language wikipedias seem better discussed here. Perhaps I should in hindsight have come here first.

One of the possible problems that occurs to me is really a restatement of the initial problem raised here by Lowellian. Somehow, we've lost sight of the difference between information, which can't be copyrighted but must be sourced by references, and text, which can be copyrighted and so must be attributed.

Accurate translation preserves the information but not the text. So when going from one language wiki to another, the references should be kept, but the attributions should not be.

In English Wikipedia, other language Wikipedias are not acceptable references, so translation into English should not be a problem: The sources are kept, the attributions discarded. Other language Wikipedias may have different policies on this, in which case it may be acceptable to add a reference to English Wikipedia if translating from here. But regardless, the attributions belong only in English Wikipedia.

Am I missing something? Andrewa (talk) 05:55, 16 December 2017 (UTC)

It seems you would be interested in reading derivative work. Killiondude (talk) 06:13, 16 December 2017 (UTC)
Good point but not quite so simple. While translation of a literary work certainly preserves the creative element of the original, the translation of an encyclopedia article does not. The creative aspect of the text of an encyclopedia article is purely in the phrasing (we prohibit original research, for example), and is lost in the translation.
It's a bit of a can of worms with regard to lists, but in general, the translation of an encyclopedia article is not automatically a derivative work.
In fact the better the article is written and the better the translation is performed, the less of a problem this becomes. But it's a very good point, and probably where the paranoia for preserving attributions through translation arises.
Preserving attributions is in general a good thing, and often required, and always important when required. But not as simple as it might appear, as we have been finding out. And playing safe is not always the safest strategy! Andrewa (talk) 07:37, 16 December 2017 (UTC)
Not to impugn on any of your thoughts here, but Wikipedia is a top 10 website. Much time, effort, and legal help has been put into its licensing. Killiondude (talk) 08:15, 16 December 2017 (UTC)
Not to suggest that it's not! But perhaps it is not perfect, despite its popularity? Perhaps fixing this might help us to stay popular?
Nor to suggest that my legal opinion is superior to that of the legal department. IANAL. Lawyers are important (perhaps unfortunately, if Shakespeare is to be believed). But they should never be allowed to tell an organisation what it wants to do. Their role is to help an organisation to decide how best to do it.
This has all the earmarks of lawyers calling the shots. The main problem with the legal perspective is that they tend to want everything spelled out in terms only another lawyer would understand. And isn't that exactly what we are doing with these useless attributions? Ones that even our own coding cannot interpret correctly?
There must be a better way. And yes, the lawyers have a role in finding it. And so does the community. Andrewa (talk) 16:36, 16 December 2017 (UTC)

Is it possible....

...to create a bot, or "auto-generated reminder" as follows: an admin blocks an editor, and...

  1. in their block summary for the user log, the admin adds a date command that on a specific date, triggers a bot reminder...
  2. the reminder simply says "Review block log of (bot inserts respective user's name);
  3. the bot posts the reminder to AN, and on the TP of the blocking admin and blocked user.

Please ping me when responding. Thank you! Atsme📞📧 11:53, 4 January 2018 (UTC)

Yes, of course. (((The Quixotic Potato))) (talk) 12:50, 4 January 2018 (UTC)
@Atsme: Forgot to ping you. (((The Quixotic Potato))) (talk) 12:51, 4 January 2018 (UTC)
Thank you, TQP - is this something that can be done locally without having to get the WMF involved? In other words, if community consensus approves a policy change/modification that will allow admins to add such a reminder to the block log, is it simple enough a project that it can be implemented (via java script, perhaps?) without having to jump through the WMF's hoops of fire to get a programmer to write the script? Atsme📞📧 13:41, 4 January 2018 (UTC)
This COULD be done with a bot since it could be done by an editor (that is read block logs, store data locally, read data locally, make edits). To be done with a bot it would not require any software changes - it would require someone to create and run such a bot. To actually be useful you'd have to convince admins to actually use these custom block log triggers and where the edits should go. — xaosflux Talk 14:22, 4 January 2018 (UTC)
  1. Download daily block log.
  2. Search each entry for trigger (e.g. "remindme 17/12/2019") and store it in a little database. Check if the date is in the correct format (dd/mm/yyyy v.s. mm/dd/yyyy)
  3. Check if there are remindme instructions for today in the database and send out the appropriate notifications if that is the case.
This isn't very difficult to program. Ideally the person who writes this software already has a bot or bots that run every day (I wouldn't run it on this computer because it is not always turned on). That person would need a botflag to post outside of their own userspace. The WMF does not have to be involved.
(((The Quixotic Potato))) (talk) 14:32, 4 January 2018 (UTC)
Note that HTML comments do not appear in the message displayed to the blocked user; ideally, you could use that to append metadata to your blocks. This is already routinely done for Sockpuppets. -- Luk talk 13:51, 5 January 2018 (UTC)
A "remind me to check on this later" is one of the features originally envisioned for mw:Flow. The most obvious use case is probably WP:U problems, to give good-faith users a chance to request a different username. Reviewing indef blocks would be another useful situation. Whatamidoing (WMF) (talk) 17:56, 12 January 2018 (UTC)

How to edit descriptions of articles that appear on mobile devices

I apologize if this is documented somewhere. Is it possible to edit the descriptions of articles that appear on mobile devices at the bottom of the page? I've seen some that are confusing and could be improved. Is it on wikidata? Is it somewhere else on the page? Or is it not part of Wikipedia at all? Thank you. Lollipop (talk) 16:44, 4 January 2018 (UTC)

Lollipop It's on wikidata. The wikidata item for VPT is - this and has a description of "Wikimedia technical village pump" Galobtter (pingó mió) 16:53, 4 January 2018 (UTC)
ok thank you..... I will make use of that by editing on the big screen . Lollipop (talk) 17:18, 4 January 2018 (UTC)
See also Wikipedia:FAQ/Editing#How do I edit mobile subtitles? PrimeHunter (talk) 19:49, 4 January 2018 (UTC)
Lollipop you may also be interested in WP:Village_pump_(proposals)#RfC:_Populating_article_descriptions_magic_word. Alsee (talk) 20:24, 8 January 2018 (UTC)

A request on a generic infobox

Dear all, in Wiki Project Ancient Egypt, we have a problem with the pharaoh infobox (visible on hundreds of articles). We noticed that the [show] button in the infobox, next to "Royal Titulary" is rarely if ever noticed by casual readers (see e.g. Nyuserre Ini). This means many cannot see the pharaoh's five names in hieroglyphs with translations. This has all sorts of negative consequences, from complains about the absence of this information to well-meaning people editing the hieroglyphs in the article. Thus, we contemplate the idea of making the [show] button more conspicuous by replacing it by [click to show] or put it in bold, or both. Unfortunately, Template:Infobox_pharaoh does not allow us to edit the appearance of the [show] button which seems to be defined at a higher level, perhaps in templates called by the infobox template. Could someone help us by showing us how to edit the appearance of the show button for pharaoh infoboxes ?Iry-Hor (talk) 17:57, 6 January 2018 (UTC)

Someone here should hopefully be able to tell if/how the appearance of the [show] button can be changed. But I'm wondering whether, in addition, the caption of the collapsed part of the infobox could be changed to something that will more immediately signal the presence of hieroglyphs. Say, if the "Royal titulary" bit was followed, in brackets, by the hieroglyphic rendition of the concept. – Uanfala (talk) 18:09, 6 January 2018 (UTC)
Uanfala This would be difficult because it would be hard to pinpoint hieroglyphs for this concept without entering endless debates in Egyptology and second, the hieroglyphs would distord the infobox and I believe make it quite ugly. However I agree that we could say something like [click for hieroglyphs] instead of just [show].Iry-Hor (talk) 08:44, 7 January 2018 (UTC)
I think the problem is not really specifically with the look of the [show] button, but that other than that, the "Royal titulary" line appears just like the {{{name}}} and "Pharaoh" headings above it, as a heading on a colored background. A heading representing folded content should have a more obvious graphic indication of this, other than the [show] button. Perhaps put [show] on a line by itself below the heading, with a lighter background color. --Pipetricker (talk) 18:30, 6 January 2018 (UTC)
Yeah, it's not immediately obvious that it can be expanded - just looks like a heading for the remaining stuff in the infobox. Galobtter (pingó mió) 18:37, 6 January 2018 (UTC)
Pipetricker Galobtter Uanfala Thanks for your ideas, as you pointed out the problem is that it looks like "Royal Titulary" is the heading of the section below when it is really the heading of the name section which is hidden until the button [show] is clicked. We could also add another heading under it for the next section, I don't know what's best really and on top of that I do not know how to change the show button.Iry-Hor (talk) 08:42, 7 January 2018 (UTC)
This demo shows the basic minimum. It illustrates that the text "show" is set by the javascript that is associated with the NavFrame class. Therefore, you can't configure it by modifying an infobox template or any of its subtemplates. --Redrose64 🌹 (talk) 14:15, 7 January 2018 (UTC)
Redrose64 ok so that means the only way to make the show button more conspicuous is that there is no way?Iry-Hor (talk) 14:33, 7 January 2018 (UTC)
mw:Manual:Collapsible elements#With custom toggle link implies that the toggle link may be customised, and even supplies three HTML elements that it claims will carry out such customisation. But it doesn't say where these should be placed, nor does it provide a working demo. I also can't find where in mw:MediaWiki:Gadget-NavFrame.js this code would hook to. --Redrose64 🌹 (talk) 15:29, 7 January 2018 (UTC)
Redrose64 Thank you, I will try to find out how this works.Iry-Hor (talk) 18:41, 7 January 2018 (UTC)
You might replace this:
| headerstyle = background:#decd87;padding:0.1em; {{#if:{{{titulary_notes|{{{notes|}}}}}} | |display:block;margin-bottom:0.3em;}}
| header = {{bigger|[[Ancient Egyptian royal titulary|Royal titulary]]}}<!--(resized here rather than via headerstyle otherwise [show/hide] link also resized)-->
with this:
| headerstyle = font-size:150%;background:#decd87;padding:0.1em; {{#if:{{{titulary_notes|{{{notes|}}}}}} | |display:block;margin-bottom:0.3em;}}<!--(resize [show/hide] link)-->
| header = <span style="font-size:75%;">[[Ancient Egyptian royal titulary|Royal titulary]]</span><!--(now resized header smaller to emphasize [show/hide] link)-->
Sandbox version at right uses |headerstyle= to set the whole header to 150% of normal size then applies a size reduction to the header title leaving the [show/hide] at the larger size. Play around with the values till you find something that you like.
Trappist the monk (talk) 15:49, 7 January 2018 (UTC)
Trappist the monk Thank you for your precious help! I will implement something like this when the discussion on the subject is closed (see talk page of the infobox). Also is there a way for the button to say something else than [show]?Iry-Hor (talk) 18:40, 7 January 2018 (UTC)
I don't know how to change the [show/hide] label. That appears to be hard-coded at the top of mw:MediaWiki:Gadget-NavFrame.js.
Another think that you might consider is adding |showhide=left which will mode the [show/hide] label to the left side of the header. Because this is en/wiki and English is read left-to-right, doing that make make the label more obvious to readers without the necessity of size changes.
Trappist the monk (talk) 19:19, 7 January 2018 (UTC)
@Iry-Hor and Trappist the monk: You can do this by using the newer mw-collapsible and mw-collapsible-content classes instead of NavFrames. {{Hidden/sandbox}} has the newer classes but there are a few things that need to be done (like centring the header text with a div with margin on left and right, since the show/hide button is different, and maybe checking that the slight change in display doesn't break anything?) before the code in {{Hidden begin/sandbox}} is moved to the main {{Hidden begin}} template (which {{Hidden}} uses). The left-side button is also currently a local bit of CSS which isn't in MediaWiki core like the standard mw-collapsible classes. Jc86035 (talk) 05:55, 9 January 2018 (UTC)
Jc86035 Will this allow me to replace [show] by [click to show] and put it on the left ?Iry-Hor (talk) 06:36, 9 January 2018 (UTC)
@Iry-Hor: It will, but I think you shouldn't change the text to that since clicking might not be possible for e.g. those using the desktop site on tablets. Furthermore, I think it would be best to have a separate header for the content below the titulary, regardless of what the button looks like, since this would make it clearer that the button isn't referring to the rest of the infobox. Also, people might not know what "titulary" means (it's not even in the two English-language Oxford dictionaries that macOS has), so it might help to clarify that with, for example, "names in hieroglyphs" in brackets. Jc86035 (talk) 07:26, 9 January 2018 (UTC)

A note about wmf labs AFD stats…

The log takes your earliest timestamp, and attaches the !vote to that date even while acknowledging that you !voted later. This messes up your logs if you delsort but then come back a week later or so and !vote. See December 30 and you'll find a Jan 6 !vote listed in the middle of those Dec 30s. L3X1 Happy2018! (distænt write) 17:03, 7 January 2018 (UTC) dnau L3X1 Happy2018! (distænt write) 14:23, 10 January 2018 (UTC)

I'm investigating this and should have a fix out pretty soon. Enterprisey (talk!) 19:05, 7 January 2018 (UTC)

Image won't render?

In the Blood in stool, there's a section of wikimarkup that says

[[File:Red feces.png|thumb|Hematochezia typically presents with bright red blood mixed  in with the stool.]]

which renders as thumb|Hematochezia typically presents with bright red blood mixed in with the stool. rather than the expected image. What gives? The markup seems valid to me, and replacing the image what different one renders correctly. What's the problem/fix? Headbomb {t · c · p · b} 01:01, 8 January 2018 (UTC)

File:Red feces.png is on MediaWiki:Bad image list. PrimeHunter (talk) 01:12, 8 January 2018 (UTC)
So, how do we bypass this? Headbomb {t · c · p · b} 01:41, 8 January 2018 (UTC)
You can post a request at MediaWiki talk:Bad image list. PrimeHunter (talk) 01:45, 8 January 2018 (UTC)
I added it as an exception to disallowing use of this image. Please note, for future reference, that PrimeHunter is correct about the correct place to make these requests. עוד מישהו Od Mishehu 07:53, 8 January 2018 (UTC)
@PrimeHunter:As an admin, you could have also done this - see here how to do it - since Wikipedia is not a bureaucracy. There is no doubt that allowing this exception is reasonable. עוד מישהו Od Mishehu 08:22, 8 January 2018 (UTC)

Redirecting links to asian websites

Can anyone safely run a links check on New Jersey Women's Hall of Fame? I ran the "Fix dead links", but I'm still concerned. I found under "External links" section that the New Jersey Women's Hall of Fame website link was a redirect to an Asian language site. I removed it. I randomly tried another link on the page, and it also redirected to an Asian language site. Can anyone safely check the links on this article and remove anything redirecting to Asian websites? — Maile (talk) 14:11, 8 January 2018 (UTC)

@Maile66: This looks like a case of usurped website. You can set |deadurl=usurped in the CS1/2 citations to remove the offending links. --Izno (talk) 14:34, 8 January 2018 (UTC)
@Izno: set it where? I don't fully understand. — Maile (talk) 14:40, 8 January 2018 (UTC)
@Maile66: In each citation template that you think needs to be fixed. --Izno (talk) 14:42, 8 January 2018 (UTC)
@Izno: I won't actually know unless I open every page link to see which ones are redirecting. I was hoping there would be something more automatic. — Maile (talk) 14:45, 8 January 2018 (UTC)
@Maile66: No, there's nothing automatic. I think it's fairly safe to say, having opened one or two links, that the entire website has been usurped. --Izno (talk) 14:48, 8 January 2018 (UTC)

"Wikipedia:New_user_landing_page" should be able to opt out or outright removed

What if I want to view the non-existent page's deleteion log to see why it shouldn't be created? — Preceding unsigned comment added by Ywwuyi (talkcontribs) 14:23, 8 January 2018 (UTC)

@Ywwuyi: can you clarify? The View History (then the View Logs) controls work on the page Wikipedia:New_user_landing_page. Also, this page exists and has no deletions in the history. — xaosflux Talk 14:46, 8 January 2018 (UTC)
I go to any non-existent page and will get redirect there. I don't want to view WP:New user landing page, but a page that has yet to be created. Ywwuyi (talk) 14:57, 8 January 2018 (UTC)
@Ywwuyi: this is by design, only on the Article namespace. See WP:ACTRIAL. The reason why is that very new editors (such as your self) are not allowed to create pages in that namespace directly. Feedback to improvement of the landing page or suggestions for specific edits on it can be submitted at Wikipedia talk:New user landing page. — xaosflux Talk 20:02, 8 January 2018 (UTC)
The deletion log is hard to find for logged in users without autoconfirmation. If you log out then you get the deletion log at for example Rifal Lastori instead of being redirected to Wikipedia:New user landing page. See Wikipedia talk:Autoconfirmed article creation trial/Archive 5#Deletion log not shown. PrimeHunter (talk) 20:18, 8 January 2018 (UTC)
(a) The normal way is to: (i) click the redlink; (ii) in the browser's address bar, remove the query string parameters &action=edit&redlink=1; (iii) find where it says ?title= and after this, insert this string: Special:Log&page= and press ↵ Enter
(b) The alternative way is to (i) go to any page; (ii) click the "View history" tab; (iii) click the "View logs for this page" link near the top; (iv) in the browser's address bar, locate the page= parameter, remove whatever follows that and append the name of the page that you're interested in (use underscores instead of spaces). --Redrose64 🌹 (talk) 20:42, 8 January 2018 (UTC)

Warning on lowercase title

I've added {{lowercase title}} at eldiario.es per WP:NCLOWERCASEFIRST, and the template shows a red warning "Warning: Display title "eldiario.es" overrides earlier display title "<i>Eldiario.es</i>".". The template works fine at pages like iPad or eBay.

What am I doing wrong? Diego (talk) 14:28, 8 January 2018 (UTC)

P.S. I've found that the error message only appears when templates {{Infobox Newspaper}} and {{lowercase title}} are both included. Diego (talk) 14:35, 8 January 2018 (UTC)

@Diego Moya: That just means there is a second display title being defined; in this case, in {{infobox newspaper}}. Review the use instructions there to fix the issue. (Recommendation: you may want to use the DISPLAYTITLE magic word in the article after fixing the displaytitle issue in the infobox rather than a passthrough template such as {{lowercase title}} since you should include the italics i.e. {{DISPLAYTITLE:''eldiario.es''}}.) --Izno (talk) 14:39, 8 January 2018 (UTC)
Thanks, that solved the problem. It required adding |italic title=no to infobox newspaper to prevent it from adding an incorrect uppercase title definition. Diego (talk) 15:37, 8 January 2018 (UTC)

Tech News: 2018-02

16:19, 8 January 2018 (UTC)

Template talk:Legend0

Can somebody help me with my edit request? I am trying to add a |text= option per {{Legend#Full parameter list}}.--Nevéselbert 18:15, 8 January 2018 (UTC)

Indication whether Talk page posts are present or not

It annoys me that I have to view an article's Talk page to see whether any posts have been made. Could there be an indication next to the link? Example: 0 if posts not present. Even better might be to keep the link's colour light red (as if the Talk page is totally empty) even if templates are present. In other words, disqualify the templates from changing the colour. Akld guy (talk) 19:32, 8 January 2018 (UTC)

I don't know if this is technically feasible, but I absolutely second this proposal. – Uanfala (talk) 19:58, 8 January 2018 (UTC)
1. Realistically, I don't think the page-rendering software is going to read every linked talk page to see if there are any section headings in it, just to avoid annoying a few editors (this does not annoy me). And that would be the only way to do it, the page history does not distinguish between "posts" and other edits.
2. Your "even better" is a non-starter anyway, as it would make it impossible to see if the target page exists. Redlink means no page, and it's unlikely we're going to invent a third color for this purpose—even if that's something within the control of our developers. ―Mandruss  20:02, 8 January 2018 (UTC)
It would be nice if MediaWiki assigned a class to the "Talk" link for an almost empty talk page so the link could be styled like Help:Link color#Styling all links just for you. But if it was a general MediaWiki feature then you would need a general way to define "almost empty". PrimeHunter (talk) 20:34, 8 January 2018 (UTC)
Even if possible, that's a lot of feature creep for a minor annoyance to a small minority of editors. How about making pings and other userpage links generate notifications when added after the fact, or at least devising a way to make it clear that no notification was generated? That's a major annoyance to what I suspect is a majority of editors who use notifications. It's actually more than an annoyance, as notifications are an essential part of discussions. This, not single-click-saver features, is the kind of thing where our developers should be spending their limited time. ―Mandruss  20:51, 8 January 2018 (UTC)
Mandruss, in your personal preferences ("Notifications" tab) you can turn on the option of receiving notifications for each successful (or unsuccessful) ping you make. – Uanfala (talk) 23:06, 8 January 2018 (UTC)
@Uanfala: I checked the "Failed mention" box and still got no indication that this edit did not generate a notification. It isn't clear to me that that option addresses the problem I'm talking about. In any case, if there were an option for such a solution it should be enabled by default. ―Mandruss  23:32, 8 January 2018 (UTC)

If we're brainstorming, something like [talk (3)] rather than [talk] to indicate 3 level 2 headers could very likely be scripted. Headbomb {t · c · p · b} 20:54, 8 January 2018 (UTC)

That's a pretty good idea. I wrote a script that does that: User:Enterprisey/talk-tab-count.js Enterprisey (talk!) 21:55, 8 January 2018 (UTC)
@Enterprisey: Thanks. I'd like to check it out, and I guess it's time I learned how to enable something like that for my account. How? ―Mandruss  22:07, 8 January 2018 (UTC)
Oops, I forgot to write documentation and installation instructions - I'll ping you when those are posted. Enterprisey (talk!) 22:10, 8 January 2018 (UTC)
Mandruss, installation instructions are up at User:Enterprisey/talk-tab-count. Enterprisey (talk!) 22:16, 8 January 2018 (UTC)
@Enterprisey: Thanks. It shows (14) for Talk:Donald Trump, which has 10 L2s and 5 L3s. ―Mandruss  22:24, 8 January 2018 (UTC)
Okay, I fixed it so it only counts level 2's. I don't really want to fix it further to display 10 instead of 9, because it would be too expensive to check for section headers inside everything transcluded on the page. Enterprisey (talk!) 22:35, 8 January 2018 (UTC)
Roger. Guess we're done here then, and everybody's happy. The performance hit seems large enough to be noticeable, but no problem if the user deems the benefit worth it. I'll decline. ―Mandruss  22:42, 8 January 2018 (UTC)
Whoa! That was quick! Who would have thought this would get solved so easily. Good job, Enterprisey! – Uanfala (talk) 23:04, 8 January 2018 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Can someone add this to the Gadgets please? (((The Quixotic Potato))) (talk) 04:42, 9 January 2018 (UTC)

Sure. There used to be a dedicated page, but now all we need is a WP:VPT discussion, which I'll put in a new subsection. Enterprisey (talk!) 05:30, 9 January 2018 (UTC)

Hmmm, my suggestion got hijacked to a totally different one. I'm not impressed. Akld guy (talk) 05:34, 9 January 2018 (UTC)

Were you asking for a post count in any link to a talk page, not just the one in the tab at the top? That would be technically feasible too, if a bit visually noisy. Enterprisey (talk!) 05:40, 9 January 2018 (UTC)
@Akld guy: It seems to me that Enterprisey's tool gave you exactly the functionality you asked for: it puts the number of talk page posts that have been made to a talk page at the top of the article, so that way, if a talk page hasn't had any posts, it will read 0. Please give it a try: see User:Enterprisey/talk-tab-count for installation instructions. Mz7 (talk) 06:25, 9 January 2018 (UTC)
@Enterprisey: and @Mz7: I didn't ask for a tool. I asked for a system-wide implimentation that would indicate that user posts have been made on each article's Talk page. When viewing an article, it's annoying to have to click "Talk" to see whether any posts have been made. Numbering was one method. My better suggestion was that if no user posts have been made, the colour of the Talk button should stay light red, as if no content was present. The way it's currently set up, as soon as someone puts a template on the Talk page, the colour changes to blue. If there were some way to disqualify templates or any other notifications from changing the colour to blue, that would work well. Akld guy (talk) 07:45, 9 January 2018 (UTC)
Well, how does it matter to you whether it is system wide? The script could be configured so that it displays light red when 0 discussions are there and blue if 1 or more is there. Galobtter (pingó mió) 07:51, 9 January 2018 (UTC)
(edit conflict) @Akld guy: I'm afraid I disagree with a system-wide implementation (i.e. switched on by default for all users) in the way you describe. Those templates that go on talk pages belong mostly to WikiProjects, and sometimes they contain other information that may be pertinent to editors, such as {{BLP}} notices or {{Ds/talk notice}} notices. A red talk page link currently means that these project templates don't exist and should be added. In any case, Enterprisey is one of the project's most helpful scriptwriters, and he has specifically volunteered his time to write you a script that will change your own interface in one of very ways that you initially suggested to help mitigate your annoyance for this issue, and he has also proposed in the section below that it be added to Special:Preferences so that it is easily available to all users. It may be possible to adjust the script to turn the link red; I don't know, but I don't really understand why you have so readily dismissed Enterprisey's efforts to help you. Mz7 (talk) 08:01, 9 January 2018 (UTC)
I didn't realise he had helped me. It looked to me like Mandruss hijacked this thread and turned it into a completely different complaint about something unrelated to mine. If it had been made clear to me what you were all doing, I would have understood. It seems everyone went off on a tangent and came up with a solution that was beyond my comprehension. Akld guy (talk) 09:42, 9 January 2018 (UTC)
@Akld guy: You're right, I did go off topic there. Apologies. ―Mandruss  10:25, 9 January 2018 (UTC)
@Mandruss: No worries, and thank you for not trying to deny it. Akld guy (talk) 10:29, 9 January 2018 (UTC)

A while back I wrote User:Anomie/talklink that does something like is requested here. Anomie 23:12, 11 January 2018 (UTC)

Proposal to make talk-tab-count a gadget

The user script User:Enterprisey/talk-tab-count was written as part of the above discussion to display the postlevel-2 section count of a talk page on the "Talk" tab. Transcluded sections are not counted. Should it become a gadget? Enterprisey (talk!) 05:55, 9 January 2018 (UTC); updated 21:45, 9 January 2018 (UTC)

So apparently the requirements are:
  • Gadgets must work if just included with no further configuration. They can be configurable via personal common.js, but must work unconfigured.
  • Gadgets must be compatible with all major browsers, i.e. they must not terminate with errors.
  • Gadgets should be functional in most major browsers (cross-browser compatibility). Exceptions must be clearly stated.
  • Gadgets only working in some skins must be marked as such if that data is available.
Works at-least on firefox and chrome. Support Galobtter (pingó mió) 08:01, 9 January 2018 (UTC)
display the post count For clarity, that's "the count of level-2 section headings". Also it should be reiterated that it won't include any transcluded headings, although they are relatively rare on article talk pages. ―Mandruss  10:20, 9 January 2018 (UTC)
This should be at Wikipedia:Village pump (proposals) in my opinion. ―Mandruss  10:30, 9 January 2018 (UTC)
Mandruss is probably correct. Support as requester. (((The Quixotic Potato))) (talk) 11:26, 9 January 2018 (UTC)
I put the proposal here because this venue was slightly favored over VPPR in the discussion where we closed WP:Gadget/proposals. (The editors in the discussion thought the technical village pump was more suited for gadgets, as they're more of a technical matter.) I've added a notice on VPPR, though. Enterprisey (talk!) 21:59, 9 January 2018 (UTC)
  • Oppose too new - get more beta testers. If all good after a few months revisit. — xaosflux Talk 03:38, 10 January 2018 (UTC)
No oppose template - after all it isn't a vote :) :P Hmm, one additional feature might be checking if it is a redirect. Galobtter (pingó mió) 05:33, 10 January 2018 (UTC)
Ha, wrong project, changed to tic's - and just a general summary of my current opposition. — xaosflux Talk 14:25, 10 January 2018 (UTC)

Featured Star looks extremely massive

In the article, "List of SpongeBob SquarePants episodes", the featured star is unusually huge. In fact, it takes up much of the article. I doubt it is just my browser since Archive.is also captures that same mistake, seen here. Yoshiman6464 ♫🥚 22:06, 8 January 2018 (UTC)

I saw what you were talking about, but it went away when I reloaded the page. Enterprisey (talk!) 22:18, 8 January 2018 (UTC)
@Enterprisey: Because I made an edit. (((The Quixotic Potato))) (talk) 22:19, 8 January 2018 (UTC)
That's interesting; I wonder why two copies of the template were necessary. Enterprisey (talk!) 22:20, 8 January 2018 (UTC)
I have removed one of the two. (((The Quixotic Potato))) (talk) 22:22, 8 January 2018 (UTC)
(edit conflict × 2) Purging and a null edit didn't seem to fix it for me but moving the {{featured list}} template up did. Not sure why. – by AdA&D at 22:21, 8 January 2018 (UTC)
Hm, weird editconflicts. (((The Quixotic Potato))) (talk) 22:25, 8 January 2018 (UTC)
I guess the problem when {{featured list}} is at the bottom is related to the page being in Category:Pages where template include size is exceeded. Templates at the bottom are not supposed to be transcluded at all in that case. A link to Template:Featured list was displayed as normal for pages in the category, but maybe a messy partial transclusion was made. PrimeHunter (talk) 22:32, 8 January 2018 (UTC)
I've seen a massive FA star before, and that was also on a page that had maxed out the template limits, and used selective transclusion (the parametrization method). It was the "natural" size, as displayed at File:Cscr-featured.svg. --Redrose64 🌹 (talk) 23:32, 8 January 2018 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Since it wasn't displaying properly for me I've temporarily substituted the episode tables for seasons 1 and 2. I think the best solution would be not to transclude the articles for the seasons at all (and remove the hidden episode descriptions after substitution), since AFAIK it doubles the count towards the template limit. Jc86035 (talk) 08:08, 9 January 2018 (UTC)

WikiData moving to new servers - data loss possible if you try to save during the move

From Tech News (posted above a while ago, but not everyone reads it who should):

Wikidata will be moved to its own database servers. This is because it is growing and needs more resources. Because of this you will be able to read but not edit Wikidata and the German Wikipedia between 06:00 and 06:30 UTC on 9 January. You might lose edits if you try to save during this time. This includes editing the language links on other wikis. [43]

 — SMcCandlish ¢ >ʌⱷ҅ʌ<  22:48, 8 January 2018 (UTC)

Reset edition calling cite module for cite_book

There is a convoluted math-source template, "Template:Introduction to Algorithms" which attempts to alter authors based on "edition=" or "1=" but cannot reset "edition=3" as "edition=3rd" so I generated "version=3rd edition" which works, but cannot reset "edition=" as blank to hide when invoke of the Lua script cite module. Used in page "Merge sort". Are there any other solutions, beyond simply call {{cite book}} rather than invoke module? No hurry on this. Thanks. -Wikid77 (talk) 02:00, 9 January 2018 (UTC)

I've reverted to {{cite book}} for now. I think Module:Citation/CS1/Wrapper could use a blacklist parameter to prevent the module from using specified parameters, |edition= in this case. Perhaps |blacklist=edition,example2,example3 would prevent the module from passing |edition=, |example2=, and |example3= to the wrapped template. — JJMC89(T·C) 06:17, 9 January 2018 (UTC)
Yes, until this works properly reversion is appropriate. I encountered similar issues trying to get the module invocation to work for {{mathworld}} (in that case not deployed because it was more obviously problematic already for the sandbox/test cases); there didn't seem to be a way to get it to ignore the template-specific parameters that should not be passed to the invocation. In the meantime see {{Introduction to Algorithms/sandbox}} for the broken invoke version and {{Introduction to Algorithms/testcases}} for some test cases. —David Eppstein (talk) 06:29, 9 January 2018 (UTC)

I do not have a clear understanding of the |edition= problem. Example of what it shouldn't do along with an example of what it should do?

I changed {{Introduction to Algorithms/sandbox}} to use |title= and |title-link= and /testcases to use |title-link=unset which eliminated the notitlelink error.

Trappist the monk (talk) 12:28, 9 January 2018 (UTC)

@Trappist the monk: |edition= should be used by {{Introduction to Algorithms}} but not passed to {{cite book}}. {{Introduction to Algorithms}} uses |edition= to determine the value of other parameters passed to {{cite book}}, including a different value for |edition=. For example, {{Introduction to Algorithms|edition=1}} should result in {{cite book|edition=1st}}, but we get {{cite book|edition=1}} instead since the module passes |edition=1 directly to {{cite book}}, overriding the value in {{Introduction to Algorithms}}. Normally this behavior is desired in order to allow overriding the default parameter values in the wrapper.
A similar issue can occur with other parameters. Say a I have a {{cite web}} wrapper that uses |potato= to determine some {{cite web}} parameter value, e.g. |url=. If |potato= has a value, it will result in an error for an unknown parameter for {{cite web}}, but it is a perfectly valid parameter for the wrapper. — JJMC89(T·C) 15:28, 9 January 2018 (UTC)
I don't think that it is necessarily a good idea to blacklist valid cs1|2 parameters because that will prevent a legitimate override of that parameter. {{Introduction to Algorithms}} provides for the unnamed parameter {{{1}}} as an alias of |edition=. Because Module:Citation/CS1 does not accept positional parameters, I have tweaked Module:Citation/CS1/Wrapper so that it does not hand-off positional parameters to the cs1|2 template. Now, instead of writing:
{{Introduction to Algorithms/sandbox|edition=2}}
Cormen, Thomas H.; Leiserson, Charles E.; Rivest, Ronald L. Introduction to Algorithms (2 ed.). MIT Press and McGraw-Hill. 
write:
{{Introduction to Algorithms/sandbox|2}}
Cormen, Thomas H.; Leiserson, Charles E.; Rivest, Ronald L.; Stein, Clifford (2001) [1990]. Introduction to Algorithms (2nd ed.). MIT Press and McGraw-Hill. ISBN 0-262-03293-7. 
Trappist the monk (talk) 16:20, 9 January 2018 (UTC)
Also, taking a tip from {{test case}}, I've tweaked Module:Citation/CS1/Wrapper so that is does not pass parameters with names that begin with an underscore:
{{Introduction to Algorithms/sandbox|_edition=3}}
Cormen, Thomas H.; Leiserson, Charles E.; Rivest, Ronald L.; Stein, Clifford (2009) [1990]. Introduction to Algorithms (3rd ed.). MIT Press and McGraw-Hill. ISBN 0-262-03384-4. 
Alas, because of the leading underscore, this scheme does not work inside {{test case}}
Trappist the monk (talk) 17:03, 9 January 2018 (UTC)
It would be preferable if we could also make it work with the original named parameters instead of requiring all-new parameters or only positional parameters. —David Eppstein (talk) 18:53, 9 January 2018 (UTC)

One-time red links

This may be a bit of a pain, but would it be possible to generate a list of red links that appear exactly one time in mainspace? I have a theory that a good number of these are either well-meaning links with typos, or things that should not be linked. Further to the second idea, would it be possible to generate a list of articles containing the largest number of one-time red links? Cheers! bd2412 T 23:52, 9 January 2018 (UTC)

AFAIK Special:Wanted doesn't even ignore redlinks in non-article space (please correct me if I am wrong). But yeah, it would be possible to create a list of red links that appear exactly one time in mainspace. (((The Quixotic Potato))) (talk) 00:32, 10 January 2018 (UTC)
Do we have any idea how many results this would generate? Thousands? Hundreds of thousands? Something in between? bd2412 T 17:39, 10 January 2018 (UTC)

OAuth - Developing Locally

tl;dr: what do I put here to develop on my local machine?

I'm trying to create a web application that uses MediaWiki OAuth. I'm confused by the OAuth "callback" URL field on the propose page. From my understanding of the definition, it seems that this field is hardcoded/permanent (i.e. can't be changed once set in the registration form). Does this mean that I won't be able to develop on my local machine with the consumer I create for production? What should I put in this field if I want to develop locally? Thanks in advance. -FASTILY 09:50, 10 January 2018 (UTC)

Definitely sorry that's been a while before anyone can answer. And You're welcome in advance. The best advice I have to offer is answered in your own question, where it's stated that you're "create a web application that uses MediaWiki", so maybe try the Media Wiki url. Otherwise I don't have a clue.Maybe try your question here if you're still not sure. Sincerely, User: Zanygenius(talk page) 17:31, 14 January 2018 (UTC)
Turns out you can use Localhost (e.g. http://localhost:8080/) for that field. Here's an example consumer for anyone who's interested. -FASTILY 07:48, 17 January 2018 (UTC)
OAuth 1.0a (the version we use) requires the callback to be set, even if it's unused. As you've discovered, even URLs at localhost are ok. Alternatively, the worst case scenario could be: you could probably get an OAuth grant approved for testing, which could then be revoked when you're ready to go live. FACE WITH TEARS OF JOY [u+1F602] 15:24, 18 January 2018 (UTC)

catastrophic formating in a french-to-english translation

Hello, I've tried the translation tool for the first time, resulting on a catastrophic result here : Vésuve de Brekka. Can somebody help to fix ? Thanks. And sorry. --Tsaag Valren (talk) 12:57, 10 January 2018 (UTC)

@Tsaag Valren: Please don't use exaggerations like catastrophic.. the world is not ending just yet. Normally you have 3 options to deal with templates when you translate. Which did you choose ? —TheDJ (talkcontribs) 13:45, 10 January 2018 (UTC)
@TheDJ: Tried to use correspondig template, and edited. It works for the "quote" model, but not for {{article}} and {{lien web}} / {{weblink}}. --Tsaag Valren (talk) 14:03, 10 January 2018 (UTC)
@Tsaag Valren: You have to use a corresponding English template or avoid using a template. You cannot assume a template has the same name or parameters in another language. fr:Modèle:Article under languages in the left pane has a link to the English Template:Cite journal. The English Template:Article is a completely different template which cannot be used for citations. You also have to translate or avoid month names. |date=9 janvier 2018 is not accepted in English. Write |date=9 January 2018 or |date=2018-01-09. Other users have fixed the citation errors. PrimeHunter (talk) 10:11, 11 January 2018 (UTC)

Merging characters in article heading (Arēna Rīga)

AxG Arēna Rīga.png

Can anyone answer as to why on the Arēna Rīga article (and maybe others with 'ē') that 'r' and 'ē' overlap in headings, but not in the content text? Does anyone else experience this problem? -- AxG /   16:19, 10 January 2018 (UTC)

It sounds like a font problem in your browser. I see no problem in Firefox, IE, Edge or Chrome with the Vector skin. What is your browser and your skin at Special:Preferences#mw-prefsection-rendering? PrimeHunter (talk) 17:23, 10 January 2018 (UTC)
It’s Firefox and Vector. I checked over on the Polish and Latvian Wikipedia, put these don’t use Georgia for the article titles, with the old sans serif being fine. -- AxG /   19:29, 10 January 2018 (UTC)
The same is also happening in Chrome and Opera, but IE is fine. -- AxG /   19:40, 10 January 2018 (UTC)

Is this only Vector skin? Try the others - View Arēna Rīga in the skin: 

--Redrose64 🌹 (talk) 20:15, 10 January 2018 (UTC)

MinervaNeue and Timeless both have the same problem, two skins that use Georgia. -- AxG /   20:59, 10 January 2018 (UTC)
They all look fine for me in Firefox 57.0.4 on Windows 10. What is your operating system? Do you see the same problem in "Arēna Rīga" and the heading below? PrimeHunter (talk) 21:57, 10 January 2018 (UTC)
Arēna Rīga

(Note: the above heading was marked up as <h2>Arēna Rīga</h2> for the purpose of test and discussion. To not mess up archiving, it has been changed to a "fake heading", which may have changed its visual appearance.)

Windows 7, and no to the one you've wrapped in <span style>, but yes to h1, and h2 headings. -- AxG /   22:07, 10 January 2018 (UTC)
That does not look like Georgia to me. The serif in the top-right of the "g" in Georgia is a perfectly horizontal line, rather as if someone grafted a small hyphen onto the end of the letter. Your screenshot shows a different "g", leading me to doubt that Georgia is the font being shown. Wikipedia's styles instruct the browser to choose Linux Libertine ahead of Georgia if available, so perhaps there is a problem with Linux Libertine. If you don't require this font, removing it from your system may help (maybe not just with Wikipedia but with other sites too). — This, that and the other (talk) 11:36, 11 January 2018 (UTC)
You were right User:This, that and the other, it was Linux Libertine, and not Georgia. I went ahead and deleted the font, then re-download and install it and it's fine now. Thanks for everyone's brains and knowledge! -- AxG /   14:10, 11 January 2018 (UTC)

How does (public) thanks work?

In article history, there's a link for sending thanks, that links to Special:Thanks. When you click on it, it prompts you if you want to, Send public thanks for this edit? I get the part about a thank you item showing up in their notification list, but I don't get the public part. Is this really a public action? Does it show up in a publicly-visible log someplace? -- RoySmith (talk) 17:28, 10 January 2018 (UTC)

See Wikipedia:Notifications/Thanks#How do I see the thanks I've given out. It says: "You will only be able to see who you thanked, and when. The log does not record the specific edits, and you cannot access other editors' notifications." PrimeHunter (talk) 17:31, 10 January 2018 (UTC)
Yes, it's at Special:Log/thanks. Here is the log of whom you have thanked, and here is the log of who has thanked you. Mz7 (talk) 18:47, 10 January 2018 (UTC)
We can't have any secret thanking going on around here. ―Mandruss  19:32, 10 January 2018 (UTC)
Thanks -(Redacted) 19:34, 10 January 2018 (UTC)
Private thanks is so easy. It is possible to thank me here, but if you do, I shan't reply. I prefer it face to face. --Redrose64 🌹 (talk) 20:38, 10 January 2018 (UTC)
MORE THAN HAPPY TO THANK YOU FACE TO FACE STOP PLS FWD AIRFARE AND LODGING EXPENSES EARLIEST STOPMandruss  21:35, 10 January 2018 (UTC)
Somewhere is a list that groups users by most thankful/least ingrate and most thanked. Probably what the sekrit admin scores are calculated off of.[FBDB] L3X1 Happy2018! (distænt write) 13:48, 11 January 2018 (UTC)

"Page size" Tool: "Word count" script 'User:Dr pda/prosesize.js' does not work with skin = Timeless

The useful "Page size" Tool (which shows an article's "Prose size" and its actual word count) does not display within the Timeless skin.

I've tested repeatedly but, when "Timeless" is the chosen skin (in User / Preferences / Appearance / Skin), the coding for this "prosesize" script doesn't seem to work when placed in either the "Shared CSS/JavaScript for all skins" (i.e. in common.js) or directly in the "Custom JavaScript" for that specific skin (i.e. in timeless.js) or when placed in both.

The coding I am referring to is this:

importScript('User:Dr pda/prosesize.js'); //User:Dr pda/prosesize.js

It may be my user error, but could this be a (known?) bug? I searched the Village pump archives but did not locate a mention of this. I have gotten around the problem by choosing to use the (default) Vector skin. Users of the Timeless skin might wish to be aware of this current lack of functionality. Many thanks, -T2.Timbuk-2 (talk) 19:11, 10 January 2018 (UTC)

The script will only work with monobook and vector skins. Ruslik_Zero 19:53, 10 January 2018 (UTC)
@Timbuk-2 and Ruslik0: I wanted to let you know that similar information is now available in the XTools' Page History tool. Look for the "Prose" column in the "General statistics" section at the top. In case you were unaware, you can load any article in XTools from within Wikipedia by going to the "View history" tab, and clicking on "Revision history statistics".

Furthermore, there is a public API to programmatically retrieve prose statistics. What this means is the user script could be updated to use the XTools API, and it will work for any skin. Pinging Dr pda in case they are interested (though it seems they may have retired from the project).

Hope this helps MusikAnimal talk 02:12, 15 January 2018 (UTC)

Brilliant! MusikAnimal, the first option you mention meets my needs and works in all skins except MinervaNeue (or am I just not seeing the "Page history" tab in that skin?). I will spread the word about this. Many thanks. Timbuk-2 (talk) 02:40, 15 January 2018 (UTC)

No talk pages appear on Mobile

Whenever you click view talk page on an article or user page on mobile, it goes to the browser wikipedia and says this article cant exist because it has a bad title. YuriGagrin12 (talk) 20:48, 10 January 2018 (UTC)

It works for me. When logged in at https://en.m.wikipedia.org/wiki/Foobar I have a link at the bottom saying "Talk". It goes to https://en.m.wikipedia.org/wiki/Foobar#/talk where I see the talk page. Are you using some app or the normal mobile site in a browser? Does the link actually say "view talk page"? Does the mesasge actually say "this article cant exist because it has a bad title"? Please post an example url where you see the link, and the url it takes you to. PrimeHunter (talk) 21:36, 10 January 2018 (UTC)
This definitely happened to me about a week ago, but only for one afternoon. I cannot remember whether I was in Mobile view or Desktop view (my preference is the latter). Using Android with Samsung S5. I have a suspicion that an update that afternoon hadn't fully unpacked and installed at the time I started to browse, or an update led to problems that had to be rectified by another update the next day. Akld guy (talk) 23:26, 10 January 2018 (UTC) Added comment: browser was Chrome. Akld guy (talk) 00:14, 11 January 2018 (UTC)
I was using the app as I like the ability to save articles however when I click view talk page it says that(almost always)YuriGagrin12 (talk) 00:23, 11 January 2018 (UTC)
Hello, YuriGagrin12! The talk button on the mobile skin is currently only visible to logged-in users, or logged-out users who have opted-in to the beta setting. This differs from desktop which shows it unconditionally. The mobile apps shows the talk page link regardless if you are logged in to you wiki account or not. There's a little more discussion in this Phabricator task, constructive feedback there is welcome! CKoerner (WMF) (talk) 19:52, 12 January 2018 (UTC)
@CKoerner (WMF): Yes, im logged in. Its not a question of whether i can see the talk page button or not, its that when I click on view talk page it takes me to safari and I almost always get "BAD TITLE this article cannot exist because it has a bad title" Even when i've been on those talk pages. YuriGagrin12 (talk) 00:56, 16 January 2018 (UTC)
YuriGagrin12, does this happen just in the main namespace or other areas (like User:)? Links to pages where you're seeing the error would be handy. It sounds like it might be this task. I'll leave a note there of your issue. CKoerner (WMF) (talk) 21:06, 18 January 2018 (UTC)

An IGN link won’t post when I try to add it.

Hello why won’t an IGN link post when I at least why to update a game article, with a link I found thanks. Danny231 (talk) 08:42, 11 January 2018 (UTC)

Which link, which article, and what goes wrong? Place the link inside <nowiki>...</nowiki> here if you cannot save it. PrimeHunter (talk) 09:50, 11 January 2018 (UTC)
This is the link I was on about http://m.uk.ign.com/articles/2017/11/07/elder-scrolls-online-clockwork-city-dlc-and-xbox-one-x-enhancements-out-today Danny231 (talk) 12:09, 11 January 2018 (UTC)
I originally thought that it might be an issue with the blacklist, but IGN certainly isn't blacklisted. I was able to post the link on Talk:The Elder Scrolls Online. @Danny231: Would you be able to post a screenshot of what happens when you try to post it? There's nothing in your filter log so it's not disallowing you from adding it. Anarchyte (work | talk) 13:11, 11 January 2018 (UTC)
I tried to do it again for a screenshot it just doesn’t come up with an error or even show up I posted the link. Strange. Danny231 (talk) 13:15, 11 January 2018 (UTC)
The link works fine. Special:Contributions/Danny231 shows you have saved no edit on any other page between your posts here. Maybe you didn't click "Save" or "Publish changes", or maybe you ignored a message after doing so. PrimeHunter (talk) 18:28, 11 January 2018 (UTC)

Problem trying to move draft to main

I am experiencing difficulty in moving a page to mainspace. When I click on 'move' I get the usual dropdown but when I try to scroll upwards to where 'article' is at the top of it, the panel 'disappears'. I can get to 'article' by dragging the little bar thing in the scrolling 'column' but the cursor remains as a pointer and does not change to a small 'hand'. If I then try to click on it the panel again disappears. The panel is also partially obscured by the 'talk' icon at the page top. Is there an anomaly of some sort? Thanks. Eagleash (talk) 11:02, 11 January 2018 (UTC)

Which operating system, which browser, which skin? --Redrose64 🌹 (talk) 11:22, 11 January 2018 (UTC)
Windows 7, Google Chrome, Vector (default). Eagleash (talk) 11:25, 11 January 2018 (UTC)
I have the same problem with Windows 10, Firefox, Vector. I have reported it with screenshots at phab:T184735: "Namespace selection at Special:MovePage can clash with navigation menu". PrimeHunter (talk) 16:05, 11 January 2018 (UTC)
Thank you. Eagleash (talk) 16:31, 11 January 2018 (UTC)

Undo and rest of twinkle on mobile

Is there a wiki-gaget or script which can modify twinkle or atleast the Undo feature for the mobile interface. Also what is the official WMF status of officially adding the Undo and twinkle to the mobile interface — Force Radical ( TalkContribs ) 11:27, 11 January 2018 (UTC)

Heya Force Radical, there's nothing on the radar for the WMF teams I work with (largely mobile and web). I've passed along your request as I am aware that the teams are looking for ideas on what sort of contributions might work best on mobile devices. Your question might be a good one to add to Wikipedia_talk:Twinkle as there's a similar question there as well from Kailash29792. CKoerner (WMF) (talk) 19:37, 12 January 2018 (UTC)

Who maintains code/table for anti-vandalism bots?

What group is in charge of anti-vandalism bots? (I'm wondering why this edit wasn't picked up by same. It seems a no-brainer keyword for basing a tentative anti-valdalism revert on.) Ok, --IHTS (talk) 00:12, 12 January 2018 (UTC)

Each bot is managed by its own respective operator. — xaosflux Talk 01:04, 12 January 2018 (UTC)
Thx. --IHTS (talk) 02:55, 12 January 2018 (UTC)
@Ihardlythinkso: perhaps you are thinking of filters, rather than bots. There are a number of links at Special:AbuseFilter where you can post an inquiry about the filters missing something that should have been blocked. — Maile (talk) 01:26, 12 January 2018 (UTC)
Thx for the clarification & lead. --IHTS (talk) 01:56, 12 January 2018 (UTC)
Actually I think this should have been cleaned up by a bot, not prevented by a filter. --IHTS (talk) 02:54, 12 January 2018 (UTC)

Unregistered account has a contribution

See Special:Contributions/Computer. Though this account is unregistered (appears to have been renamed), it shows a contribution when queried. How is this possible? For those wondering, I picked this up off of WP:LAME, where the account is mentioned (in a very old edit war). Home Lander (talk) 01:21, 12 January 2018 (UTC)

The diff for that edit is here, which says it was by User:タチコマ robot. DuncanHill (talk) 01:25, 12 January 2018 (UTC)
... and the contrib shows up for that account as well. This is a mystery for the ages, here. ;-) Hijiri 88 (やや) 07:26, 12 January 2018 (UTC)
This entry appears in the log: 23:53, 18 July 2007‎ Andrevan ‎ m . . (1,072 bytes) (0)‎ . . (moved User:WOPR to User:Computer: Automatically moved page while renaming the user "WOPR" to "Computer")
and : 20:12, 8 July 2008‎ EVula ‎ m . . (5,878 bytes) (0)‎ . . (moved User:Computer to User:タチコマ robot: Automatically moved page while renaming the user "Computer" to "タチコマ robot")
Graeme Bartlett (talk) 07:44, 12 January 2018 (UTC)
The same bug with User:NeuroproteXeon, it is reported at phab:T128276. Stryn (talk) 16:07, 14 January 2018 (UTC)

Per: Special:WantedPages §Question/Suggestion

___NOT_A_TECH_ISSUE__

Admins:

Salutations, Members of the Wikipedia Community It must be brought to attention that articles show up no matter whether they were deleted, or they weren't, nonetheless, they we're thrown in together. I don't nessicarily find this as a problem, however I find it to be like

speed bumps on the road of editing

— unknown
.

Nowadays, I often find my self scrolling the list, and today I tried clicking on Iceland Sea. I was considering taking it under my wings, only to find it deleted by User:Zzyzx11, so I was unsure whether it would be a good idea. I often felt steered away from pages because of this entropy.

--

Now, I understand the Administrative needs of showing the deleted pages', don't get me wrong here. I shall implement my solution below, and submit what would be like a summary, except it's my solution, potentially the answer, in my opinion, to the problem.

It would be found quite harsh and unnecessary to delete the deleted pages, so why not provide a button. One that could temporarily hide the deleted pages to Auto-confirmed users and reveal the same to the administration, buearucrats, and the stewards(which Special:Statistics counts as 0, huh?), who could really use it. Why not provide a button like you'd see on your watchlist, in which sorts the desirable content out of the thickness. A button like: Hide Deleted Pages would really do the trick.

--

I would like to take the time to thank you for all you've done for Wikipedia. What you have, what you do, and what you'll contribute to in the future, so much contributions, I must thank you. I must also thank you in advance, for responding to me, and resolving perhaps one of the most arrogant problems of the Special Pages, at least affecting me.

Thank you, let's keep Wikipedia strong.

Sincerely, User: Zanygenius(talk page) 01:28, 12 January 2018 (UTC)

The reason it was deleted can be useful to know. In this case it was deleted for reason G7, which means that the original author wanted it deleted. This means that it is fine to recreate it. You can even ask for a restore, though what was there was not that useful, and had no references. Also the page was actually deleted by Sphilbrick, so perhaps you are looking at another entry. There is already a mechanism to hide or eliminate the deletion entry, but it should only be used in certain cases. (perhaps the title was libelous or very offensive, etc). As an admin I see "(change visibility)" which will allow me to hide the entry. This message appears when attempting to hide a log entry: "Deleted log events will still appear in the logs, but parts of their content will be inaccessible to the public. Other administrators will still be able to access the hidden content and to undelete it, unless additional restrictions are set. " Graeme Bartlett (talk) 07:38, 12 January 2018 (UTC)
@Graeme Bartlett: I find that to be interesting perspective there, though I have stated that there is importance to the visibility of deleted pages in parapgraph 3. Now I don't find this completely un-useful, as I decided to post a message to the Creator about his article, as you suggested, and so hopefully he'll respond soon.
Well, I'll try to keep in mind all that you've said, as I progress forward. Have a wonderful day!
Sincerely, User: Zanygenius(talk page) 15:54, 12 January 2018 (UTC)

Anyone else think 200 characters is too much for the "Reason" parameter when moving a page?

[44] -- is there any way to access the actual <200 character reason I actually wrote, or is it lost to the aether? I'm pretty sure it was meant to say something like "over the manuscript tradition relates to the New Testament rather than the Hebrew Bible, because of the abundance of fairly early but relatively variant manuscripts we have of the former", but with it being cut short because the automatic part of the edit summary came to 162 characters and cut the end of my reason off. If I had planned ahead for this, I would have tried to fit my reason into 93 characters or less, but... Hijiri 88 (やや) 07:19, 12 January 2018 (UTC)

@Hijiri88: See the move log. — JJMC89(T·C) 07:32, 12 January 2018 (UTC)
Like the edit summary, the actual limit is 255 bytes; but a significant proportion of that is soaked up by the default text "moved page Foo to Bar" which could potentially include such strings as "over a redirect", "without leaving a redirect" or both. --Redrose64 🌹 (talk) 16:28, 12 January 2018 (UTC)
Soon the limit will be raised to 1000 Unicode characters. But you'll still have to take that 162 characters into account if you're writing that much text in the move reason. Anomie 00:49, 13 January 2018 (UTC)

Templates that fetch data from wikidata

Hello. Do we have templates that fetch data from Wikidata? Xaris333 (talk) 10:19, 12 January 2018 (UTC)

Category:Wikidata templates. PrimeHunter (talk) 10:22, 12 January 2018 (UTC)

div col template

This was pointed out on the template's talk page, but it seems to have gone unanswered, so I figured I'd bring it up here instead. In {{div col}}, the default is to use cols=2, despite that being deprecated. I most often see this template used in "See also" sections, and whenever I see cols used explicitly, I tend to change to to colwidth= something between 20em and 30em, but I'm probably not consistent with which. Is there a good solution so articles are consistent? Maybe just a basic wrapper for "See also"s that picks a reasonable default width? It almost never needs to be changed from some reasonable default anyway. –Deacon Vorbis (carbon • videos) 17:39, 12 January 2018 (UTC)

It might be worth looking at Template talk:Reflist/Archive 29 and some of the work done there by RexxS and others. A fixed number of columns (too narrow on smartphones, too wide on big screens) has been deprecated by this community for years. Whatamidoing (WMF) (talk) 18:40, 12 January 2018 (UTC)
I'm not quite sure what I'm supposed to be looking at exactly. I realize that setting a fixed number of columns is deprecated, but that's exactly what the template does by default (with 2) despite that. Would a {{See also cols}}/{{See also end}} wrapper be reasonable? This could just pick a reasonable default (say, 30em), and would be easy to update. This would help avoid inconsistent column widths, as is currently the situation. Even better would be to use something like this on most every page, and enable columns if there are more than some minimum number of entries, but I don't know if that's possible to check for with a pair like above. –Deacon Vorbis (carbon • videos) 19:16, 12 January 2018 (UTC)
I have added some discussion to Template talk:Div col, which has only 38 watchers. Feedback from technical folks is welcome. – Jonesey95 (talk) 21:22, 12 January 2018 (UTC)

Strange vandalism

Sorry if this is the wrong place to post this, but on several pages, Human and Barack Obama are specifically the ones I know of but I've been told there are more, there are transparent images covering the entire page that link to a YouTube stream. These links don't show up in the source code or the edit history of the pages. FrederickE♠♣♥♦ 04:35, 13 January 2018 (UTC)

Also it appears that the pageXinjiang conflict has the same issue linking here https://www.youtube.com/watch?v=oYntVKsbvFM has this page been hacked?? I know this is not the right place to report this but i do not have the ability to to sign up for a phabricator account right this moment Thanks Sassmouth (talk) 04:42, 13 January 2018 (UTC)
There was vandalism to Template:Excessive citations inline, I'm running a purge job against pages it was on and have increased its protection. The vandal has been blocked. — xaosflux Talk 04:42, 13 January 2018 (UTC)
@FrederickE: and @Sassmouth: the purge job is done, please let us know if you still see issues. — xaosflux Talk 04:54, 13 January 2018 (UTC)
Additionally, I've added this to the spam blacklist. SQLQuery me! 04:45, 13 January 2018 (UTC)

Template:Panorama

I made this template defaulting to center in focal area, to get proper width, I used width: min-content; to calculate box width. But there is a problem that Microsoft Edge does not support this property, so this template cannot get desied width on Edge if this template including very small image. I hope Microsoft fix it soon. Is there anyway to contact them? --Great Brightstar (talk) 14:22, 13 January 2018 (UTC)

@Great Brightstar: Good morning, Sorry, there's No available phone, however I recommend visiting their website for help. Sincerely, User: Zanygenius(talk page) 15:18, 13 January 2018 (UTC)
@Great Brightstar: Where have you seen this min-content value described? It's not in Cascading Style Sheets Level 2 Revision 2 (CSS 2.2) Specification W3C First Public Working Draft 12 April 2016, which describes the width: property and its proposed extensions for CSS 2.2; nor is it in CSS basic box model W3C Working Draft 9 August 2007, which describes the width: property and its proposed extensions for CSS 3. This implies that few browsers (if any) will recognise a width: min-content; declaration. Personally I would not use anything that isn't described in the most recent W3C Recommendation, which for the width: property is Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification. --Redrose64 🌹 (talk) 19:47, 13 January 2018 (UTC)
This value is described in MDN Web Docs. According to MDN, this is defined in CSS basic box model 7 September 2016, and currently available in Chrome (without prefix), Firefox (with -moz), Opera and Safari (with -webkit). --Great Brightstar (talk) 10:25, 14 January 2018 (UTC)
That doc is an Editor's Draft, so will be highly fluid - don't rely on it. Indeed, the big yellow box states "This draft is undergoing changes and many parts are not consistent with other modules of CSS. Please, refer to CSS level 2 [CSS21] instead for the definition of the basic box model." --Redrose64 🌹 (talk) 21:38, 14 January 2018 (UTC)

Could the empty fields be hidden in templatedata tables?

When setting up template data, the preview on the template doc page ends up showing reams of this:

Default
empty
Example
empty
Auto value
empty

There often isn't any reason to fill these fields in, but they do make it quite hard to scan the tables for what's actually been specified. They also often mean the tables are too big to be a sensible replacement for existing parameter tables, which means the parameter list ends up being written out (at least) twice on template pages. Would it possible to just get rid of them when empty? User:GKFXtalk 19:59, 13 January 2018 (UTC)

Yep. Using CSS one can only hide the fields, but not the "label" using something like dd.mw-templatedata-doc-muted { display:none} until they add that class to the sibling dt tag (https://phabricator.wikimedia.org/T176956). It is possible to hide all of it entirely using javascript. 21:27, 13 January 2018 (UTC) — Preceding unsigned comment added by 197.218.83.2 (talk)

That CSS should really be put into the site-wide stylesheet. I've been adding quite a bit of templatedata recently and it's frustrating that the tables are just too unwieldy to become the primary source of parameter information on all but the simplest templates. If these tables were actually readable on doc pages, they could be used as a replacement for existing information more often. On the DRY (don't repeat yourself) principle, that would make both maintaining and reading doc pages easier. User:GKFXtalk 10:04, 14 January 2018 (UTC)

Method to flag names

User:Theopolisme/Scripts/adminhighlighter.js is a useful script to know who is an admin, it highlights the signature in a blue bar. I'd like to expand this with the ability to highlight other designated names with custom colors. For example, highlight User:Theopolisme with the color red so whenever I come across Theopolisme in the future, it reminds me this is someone I wanted to remember for whatever reason (I could keep a separate "key" or list with notes). Is there any tool like this available, or would it be easy to expand adminhighlighter.js? (Theopolisme has not logged in since September..) -- GreenC 21:23, 13 January 2018 (UTC)

One doesn't need a script to highlight individual linked names. CSS is enough ( https://developer.mozilla.org/en-US/docs/Web/CSS/Attribute_selectors). 21:34, 13 January 2018 (UTC) — Preceding unsigned comment added by 197.218.83.2 (talk)

In Firefox 57, created a userChrome.css per instructions with content as described:
a[href*="User:GreenC"] {
  background-color: silver;
}
Rebooted Firefox.. but doesn't work. Is the CSS ok? -- GreenC 22:31, 13 January 2018 (UTC)

The CSS is fine, but this would be better:

a[href="/wiki/User:GreenC"] {
  font-style: italic;
}

It will ensure that it only matches the user name and not subpages or other random page that may also contain that string. Creating that custom firefox css seems like overkill. Tampermonkey or greasemonkey or "stylish(?)" extensions would achieve the same thing.

It is simpler just add it to wiki User:XX/common.css as you're a registered user. 23:29, 13 January 2018 (UTC) — Preceding unsigned comment added by 197.218.83.2 (talk)

Also see WP:CUSTOMSIG for similar advice. Johnuniq (talk) 23:40, 13 January 2018 (UTC)
Got it, thanks IP! -- GreenC 23:41, 13 January 2018 (UTC)

Centring Template:Tree list

(Section heading changed to remove template call, see comment in the wikitext.)

Can someone help me with this? I'm trying to force said template to appear in the centre of a table cell. |style="text-align:center" doesn't work.--Nevéselbert 22:08, 13 January 2018 (UTC)

@Neveselbert: It generates a <div>...</div>-type block element, which won't respond to inline styling placed outside itself. Where are you trying to do this? --Redrose64 🌹 (talk) 22:11, 13 January 2018 (UTC)
@Redrose64: I am editing a draft. Here are the contents of the cell I would like to have centred:
Can the template itself be modified to allow centre formatting? Thanks.--Nevéselbert 22:19, 13 January 2018 (UTC)
This might work:
--Redrose64 🌹 (talk) 23:57, 13 January 2018 (UTC)
That does indeed work! @Redrose64: can you implement the changes in {{Tree list}}? Thanks.--Nevéselbert 00:11, 14 January 2018 (UTC)
I have to add though that, when line breaks are invoked, this happens:
Foo
|center=yes does not appear to work in this situation.--Nevéselbert 00:28, 14 January 2018 (UTC)
Try it without width="195px" --Redrose64 🌹 (talk) 09:53, 14 January 2018 (UTC)
@Redrose64: Is that the only way to fix the problem? It's just that the table I'm editing uses fixed widths, so I'd rather not. Do you know of any way to insert the treeview lines without having to transclude {{Tree list}}? I've looked and I have only seen {{hr}}, which only inserts a straight line.--Nevéselbert 19:50, 14 January 2018 (UTC)
I've been testing out different values, parameters, and what not, @Neveselbert:, and I think you'll be satisfied with my findings, which can be seen below.
The problem seems to arise when there is only 1 row width setting in the main table. I do find that odd, but it's not the only reason. The 1st column is too small in order for the machine to "centerise" it. So, now I'm proposing a change in the row parameter, using
{| class=wikitable style="width:395px"
| width="400px" |{{Tree list/sandbox|center=yes}}
as the beginning to the table. That produces
Foo
And it centers better using higher | width= paremeter. For extra long trees, try 500 or higher. Now, I think that should solve all your problems. Questions? Feel free to come back and ask them. We won't get annoyed.
Sincerely, User: Zanygenius(talk page) 20:47, 14 January 2018 (UTC)

Editconflicts with yourself

If I doubleclick the "Publish changes" button I can get an editconflict with myself. Why don't we disable that button in Javascript for a second after it has been clicked? (((The Quixotic Potato))) (talk) 22:22, 13 January 2018 (UTC)

  • Pointless comment I know but this has been a thing for like 4-5 years however it's never been an issue well not for me anyway so don't see much pointing changing stuff. –Davey2010Talk 23:01, 13 January 2018 (UTC)
The Quixotic Potato, try User:Enterprisey/disable-save-on-click.js. I don't know if it works, because the next page loads too fast for me to let me doubleclick it, so let me know if there's a way I could improve it. Enterprisey (talk!) 07:54, 16 January 2018 (UTC)

Linking to section with template name in title

How does one generate a proper link to: [[c:Commons:Village_pump/Copyright#{{Dw_no_source_since}}_pettifogging]]?

The problem is that the section title has a template name in it and Mediawiki disrupts the link in other to look for the template, i.e. [[c:Commons:Village_pump/Copyright#Template:Dw no source since_pettifogging]]. Dragons flight (talk) 14:02, 14 January 2018 (UTC)

@Dragons flight: By encoding the curly brackets: c:Commons:Village_pump/Copyright#{{Dw_no_source_since}}_pettifogging -- John of Reading (talk) 14:15, 14 January 2018 (UTC)
Thanks. Funny, I tried to do that before posting and it didn't seem to work. I guess I got the encoding wrong somehow. Thanks again. Dragons flight (talk) 14:23, 14 January 2018 (UTC)
Gave it an {{anchor}} as well, now it works without the odd markup to c:Commons:Village_pump/Copyright#Dw_no_source_since_pettifogging. — xaosflux Talk 15:19, 14 January 2018 (UTC)
For this I recommend User:The Earwig/permalink.js -- though that produces a permalink, which may not be what you want. MusikAnimal talk 00:37, 15 January 2018 (UTC)

List formatting

What's the best syntactically correct way to do the list and column formatting in "Don't Stop the Music" (Rihanna song) § Track listing and formats without changing the layout too much (e.g. without making the line spacing too small, without splitting the numbered lists across columns)? Would a helper template be needed to do custom formatting? Currently it's syntactically ten separate lists inside {{col-start}}/{{col-2}}, which are probably deprecated by something somewhere. On some articles I've also seen things like *; (as well as * ;, which doesn't actually work) instead of the bold formatting in this article, which passed FA despite having these formatting issues. Jc86035 (talk) 16:28, 14 January 2018 (UTC)

@Jc86035: Good morning, I'm currently only at level-3, so I don't know super specialized layouts. However, I can tell you that when I went to look at the problem, an organized, understandable, list (shown in the box below) appeared, so I don't know if it should really be messed with. However, you may insert a wikitable.[1] Hopefully this helps some, and don't be to hard on yourself.[2]

References

  1. ^ Wikipedia:Manual of Style/Lists of works#List styles mentions that sometimes, simpler is better.
  2. ^ Wikipedia:Wikipedia is a work in progress Don't be to fast!
Track listing and formats
Track listing and formats
Notes
  • a^ Released as separate digital singles in both United States and Canada via iTunes.
  1. ^ a b c d e f This is just a dummy reference to avoid error messages. The real references are at Don't Stop the Music (Rihanna song) § Track listing and formats.
Sincerely, User: Zanygenius(talk page) 16:58, 14 January 2018 (UTC)
@Zanygenius: It's not syntactically correct, however, since if it were correct it would be nested (*, *#), it wouldn't be ten separate lists in the rendered HTML (the newlines should be removed but I'm not sure of the best way to make it look nice) and it wouldn't be split in the middle with {{col-2}}, since this splits the list unnecessarily into two table cells (help page · Manual of Style).
You've only been here for less than a month, so I don't know if it's the best thing for you to go around giving other editors advice yet. It's also probably best to avoid extraneous bold and italic formatting (even in your comments), since it can distract from the words. Jc86035 (talk) 00:51, 15 January 2018 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Main questions:

  • Is it possible to mark within a list that an element shouldn't be split between columns?
  • Is it stylistically correct(?) to use margin-left: 1.6em (default seems to be 3.2em) to reduce the indent of a numbered list?
  • Do these things require changes to MediaWiki:Common.css or the creation of a template/Lua module for these sorts of lists to make them correctly formatted? (In any case, indenting an <ol> inside a <li> would require a template for either the outer list or the inner lists to add styling or CSS classes.)
  • Are {{col-begin}} and other column templates using tables (instead of divs) deprecated? Should they be deprecated?

Jc86035 (talk) 01:05, 15 January 2018 (UTC)

The markup in the collapsed box above creates bad lists partly because of the blank lines, but mainly because it switches from one style to the other without nesting. A format like this would be better (refs omitted):

  • Promotional remix singles
    1. "Don't Stop the Music (Solitaire's More Drama Mix)" – 8:04
    2. "Don't Stop the Music (The Wideboys Club Mix)" – 6:38
  • iTunes EP
    1. "Don't Stop the Music" – 4:27
    2. "Don't Stop the Music (The Wideboys Club Mix)" – 6:38
    3. "Don't Stop the Music (Instrumental)" – 4:19

which gives a single unordered list, into which are nested some ordered lists. To Jc86035's first question (element shouldn't be split) though, this is within the scope of CSS Fragmentation Module Level 3 but be warned, this is only a W3C Candidate Recommendation so is not yet finalised. (CSS 2.1, which is a full W3C Recommendation, only has provision for break control in paged media such as hardcopy printout). --Redrose64 🌹 (talk) 11:03, 15 January 2018 (UTC)

Template:Free-content attribution evaluates to wrong HTML with icon floating in apparently disconnected locations

Resolved: Fixed incorrect formatting in the template. Jc86035 (talk) 01:52, 15 January 2018 (UTC)

Template:Free-content attribution reportedly evaluates to wrong HTML. Moreover, the use of this "Free-content attribution" template in a list of items generates a multi-colored circular icon icon that floats out of place in a list.

These two phenomena may not be related, but the free-floating icon problem suggests a moderately urgent need to modify the HTML to which that template translates. For more detail, see Template talk:Free-content attribution#The template evaluates to wrong HTML. Thanks, DavidMCEddy (talk) 01:42, 15 January 2018 (UTC)

I was told to come here for help writing a Wikipedia-editing script and running it on my account

Everything is explained in the link in the section header. Care to differ or discuss with me? The Nth User 03:14, 15 January 2018 (UTC)

Problem with move

I tried moving Draft:Nancy_Wilson_(basketball_coach) into article space, but when I click the Move option, it didn't seem to allow "article" as a choice. (Possibly related, I can see the word "talk" highlighted and almost interfering.) I tried selecting some other options such as Category and Book (obviously, not carrying out the move, and those seemed to work. Am I missing something?--S Philbrick(Talk) 14:19, 15 January 2018 (UTC)

What browser and what version of your browser are you using? You can try clicking on the dropdown box to where it is highlighted (but the dropdown doesn't show) and then type ( to make it appear as a temporary workaround. Nihlus 14:21, 15 January 2018 (UTC)
Same here on Chrome 63, but typing ( and clicking enter allows selection. Galobtter (pingó mió) 14:29, 15 January 2018 (UTC)
  • A technical fix (phab:T182602) has been made, and should be resolved this week here. — xaosflux Talk 15:03, 15 January 2018 (UTC)
Thanks for the feedback that it is a known problem, and scheduled to be fixed. Thanks also to Galobtter and Nihlus - I had to try a couple times, but that worked as a temporary workaround.--S Philbrick(Talk) 15:35, 15 January 2018 (UTC)

Tech News: 2018-3

18:45, 15 January 2018 (UTC)

Two-factor authentication progress?

355-failed-attempts-2018-01-15.png

There are a lot of things I do here that I find enjoyable, but logging in to find the pictured notification is not one of them. It's times like these that make me wish that the 2FA extension were available for all accounts. I see we have a tracking Phab task for this (T166622) but of course it's had no serious activity since August last year. The Phab project also seems low-activity to me. What's the status on this, and is there an estimate for when we can have it? Enterprisey (talk!) 22:03, 15 January 2018 (UTC)

At least you can log in. If 2FA were enabled, there would be a dozen complaints every month from people with a fouled-up system that did not allow them to log on. No one can guess a password in a thousand attempts providing the password is reasonable (WP:STRONGPASS) and providing the editor does not reuse their password on various sites. Does anyone know what the rate limit of guessing passwords is? It is likely that the IP of the person attempting to log on will be displayed in the alert to the targeted user fairly soon (phab:T174388) and that will at least be interesting. Johnuniq (talk) 22:19, 15 January 2018 (UTC)
@Enterprisey: if you REALLY REALLY want this, you can have it already (see your talk page). Please note, as far as I can tell - it will not stop those errors - they will still have invalid logon attempts. — xaosflux Talk 22:34, 15 January 2018 (UTC)
If your password is secure and unique to Wikipedia, or you have 2FA enabled, you can safely disable the "Failed login attempts" notifications in your preferences. This particular notification is intended only as a wake up call that your account should be secure. If it is, you have nothing to worry about. MusikAnimal talk 02:10, 16 January 2018 (UTC)
I wouldn't say nothing to worry about but rather no immediate cause for concern. One should always be at least cognizant that someone is assaulting their account--if the hacker is determined & targeting you they could try other vectors beyond just brute-force. Can't hurt to be cautious :) FACE WITH TEARS OF JOY [u+1F602] 15:55, 18 January 2018 (UTC)
Re my rate limit question above, mw:Requests for comment/Passwords (2014) says the default allows one guess per minute per IP, with possibly a captcha every few attempts. A person controlling a bot with access to 1000 IPs could perform 1000 attempts per minute to guess the password of a single account, or could attack several accounts concurrently. I don't see any recent information about the current requirements for a password or the enwiki rate limiting settings. Johnuniq (talk) 09:32, 16 January 2018 (UTC)

Wikimedia error

Resolved

Just for documentation, I got a Wikimedia error when I tried to post a few minutes ago, saying the site was under maintenance.— Vchimpanzee • talk • contributions • 22:26, 15 January 2018 (UTC)

Greetings, @Vchimpanzee: So your problem is on Wikipedia, or one of the other Wikis? Leaves a bit of confusion. Thank you in advance,
Sincerely, User: Zanygenius(talk page) 22:35, 15 January 2018 (UTC)
Sorry, it was English Wikipedia. It only happened once.— Vchimpanzee • talk • contributions • 15:53, 17 January 2018 (UTC)
Always copy the error :) —TheDJ (talkcontribs) 16:51, 17 January 2018 (UTC)
I would have, but I had something else copied that I didn't want to lose.— Vchimpanzee • talk • contributions • 18:42, 17 January 2018 (UTC)
@Vchimpanzee:Glad to hear that it's resolved!

Sincerely, User: Zanygenius(talk page) 21:02, 17 January 2018 (UTC)

Thanks for reporting, but if it's just a one-off error that didn't repeat and you didn't copy the message, there's precious little that can be done to track it down. Please let us know if you see it again though. FACE WITH TEARS OF JOY [u+1F602] 15:46, 18 January 2018 (UTC)

Weird text cursor / insertion point behaviour when editing source, iPad Safari

I was trying to edit a Wikipedia article using Safari ios 11.2.2 on an iPad Pro 12.9" and I got into a state where no text cursor was visible. Then when I clicked in the textvat some point and made some changes the text edits were actually happening at a different point in the text, not at the point corresponding visually to the point where I had clicked. It was as if it had somehow got the offset into the text wrong, speculation :- perhaps by getting font widths wrong?

Has anyone ever seen anything like this?

I had to give up and close the browser and lose the edits. I tried editing the same page using a different browser, iCab, and it was all good. CecilWard (talk) 19:16, 16 January 2018 (UTC)

@CecilWard: Happnes to my computer sometimes, and my tablet other times. This past month has been better. I recommend typing slowly. But I seriously can't wait for the day they correct that. Also, this seems to happen after 20 mintues of straight up typing, so do bits at a time.
Sincerely, User: Zanygenius(talk page) 19:58, 16 January 2018 (UTC)
Do you have the syntax highlighting beta enabled ? —TheDJ (talkcontribs) 11:09, 17 January 2018 (UTC)

Editor font size

At some point since my last edit 29 minutes ago, the font size in my wikitext editor window dramatically increased, roughly doubling. What happened? ―Mandruss  21:27, 16 January 2018 (UTC)

I have the opposite problem, as shown in the [sub-]section below. Emir of Wikipedia (talk) 21:33, 16 January 2018 (UTC)
I have the same thing as User:Mandruss. I searched throughout the preferences on a way to change it back but have come up empty so far. Adamtt9 (talk) 21:45, 16 January 2018 (UTC)
It happened to me too, at the same time. It's happened before - anyone know how to fix it? Hawkeye7 (discuss) 21:52, 16 January 2018 (UTC)
For some reason the font has been changed to a Monospaced font in the wikitext editor in both Firefox and Chrome. --Bamyers99 (talk) 21:54, 16 January 2018 (UTC)

Just found the Tech News: 2018-02 notice about this:

  • The font size in the editing window will change slightly for some users. It will now look the same on all browsers and operating systems. [51][52]

--Bamyers99 (talk) 22:03, 16 January 2018 (UTC)

The latter sources says "This will shrink the height of the characters, by a barely noticeable 2.5%, for editors using Chrome, IE, and Edge", I certainly noticed. It also says " Editors using Safari or Chrome on OS X/mac OS (about 12%) will notice a significant increase, which should improve accessibility", which would explain the case in this section. Emir of Wikipedia (talk) 22:08, 16 January 2018 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────(Firefox) I got back to my preferred size by changing 150% to 110% in my common.css.[53] I assume any editor can get any size they want by copying the last 3 lines there and setting the percentage as desired. I hope this is the last time I have to change it. ―Mandruss  22:20, 16 January 2018 (UTC)

Thanks for that Mandruss. I think that for Chrome, IE, and Edge 95% works better. Another suggestion I have is to make this at Meta in your global common.css, because as I documented below this change affects other projects but obviously if you don't use other projects then disregard this. Emir of Wikipedia (talk) 22:33, 16 January 2018 (UTC)
  • I wish the tech guys would stop "improving" the default text editor and NOT making it opt-in. As in, I would like to be able to use the original pre mid-2017 change UI. Now I'm stuck with various preference changes which barely negate it or having to change my CSS as demonstrated above. Safari& Chrome MacOS L3X1 Become a New Page Patroller! (distænt write) 01:37, 17 January 2018 (UTC)
I nerfed mine all the way down to 85% and but the font still looks weird. L3X1 Become a New Page Patroller! (distænt write) 01:42, 17 January 2018 (UTC)

Text is smaller in source editor

I have suddenly come across a very strange problem. The text is my source editor has suddenly gone small. I use the Vector skin and I have many scripts as shown at User:Emir of Wikipedia/common.js. This is not a browser specific I have tested in on multiple browsers. It is also not a display or scaling issue as this is the only thing affected. Commons also seems to be affected by this issue. Looks like I am not the only one having this type of problem as shown in the above section. Emir of Wikipedia (talk) 21:33, 16 January 2018 (UTC)

This issue has been resolved due to the content in the above section. Emir of Wikipedia (talk) 22:34, 16 January 2018 (UTC)

How can I remove a display language from the Languages list on the left side of the page?

After recently making contributions to other langwikis, Wikipedia has started to list Deitsch (Pennsylvania German) in the list of languages, even though such an article doesn't exist. I believe this is intended to suggest that I make a new translation for the article. However, I don't speak Deitsch, and would not be able to make useful contributions to that language's wiki. How can I remove Deitsch from my list of languages? {{u|Rey_grschel}} {Talk} 00:20, 17 January 2018 (UTC)

On which page are you seeing this link? --Redrose64 🌹 (talk) 00:28, 17 January 2018 (UTC)
You can't remove it. Those aren't a list of languages. They're links to a same-named article at a Wikipedia of another language. — Maile (talk) 01:46, 17 January 2018 (UTC)
The post is referring to a feature of "Content Translation" at Special:Preferences#mw-prefsection-betafeatures. If the feature thinks you know a language and the current article does not exist in that language then you get a gray language link to translate the article. mw:Help talk:Extension:ContentTranslation#Removing the gray interwiki links says you cannot edit the list of languages. You can remove the whole list by disabling "Automatically enable all new beta features" and "Content Translation" at Special:Preferences#mw-prefsection-betafeatures. PrimeHunter (talk) 01:59, 17 January 2018 (UTC)
That's exactly what I'm seeing. I'd disable "Content Translation" but it's a useful feature when translating articles. I guess I'll just have to live with it. {{u|Rey_grschel}} {Talk} 02:16, 17 January 2018 (UTC)
I don't mean to sound rude, but I know that this list normally contains links to articles on other langwikis, however, this language is at the top of the list and is greyed out (perhaps something I should have mentioned, even though I said the article already existed). PrimeHunter has exactly what I'm looking for. {{u|Rey_grschel}} {Talk} 02:16, 17 January 2018 (UTC)
You should have followed the edit notice for this page, specifically: "Where did you encounter the problem? Please add links when possible." You could have said: "For example, Teisterbant has a gray 'Deitsch' link to https://en.wikipedia.org/w/index.php?title=Special:ContentTranslation&page=Teisterbant&from=en&to=pdc. Then people could see it's about a feature which is disabled by default. PrimeHunter (talk) 02:52, 17 January 2018 (UTC)
I'll make sure to do that in the future, sorry about that. {{u|Rey_grschel}} {Talk} 04:03, 17 January 2018 (UTC)
On various pages throughout the enwiki, particularly on Teisterbant and several of its related articles. {{u|Rey_grschel}} {Talk} 02:16, 17 January 2018 (UTC)
I tried enabling content translation at beta features, and went to Teisterbant but I don't see any mention of Deitsch. --Redrose64 🌹 (talk) 17:23, 17 January 2018 (UTC)
Deitsch is an example for Rey_grschel. I see svenska, Ελληνικά, dansk (Swedish, Greek, Danish) without knowing any Greek. mw:Help talk:Extension:ContentTranslation#Removing the gray interwiki links says: "the list is determined based on certain criteria like your browser preferences, past languages you have translated into, geographical location (if shared) etc". I'm in Denmark with Danish in my browser. Swedish is very similar to Danish. Don't know where Greek came from. I did make one edit to the Greek Wikipedia in 2011. PrimeHunter (talk) 18:25, 17 January 2018 (UTC)

Template syntax + wikidata question

Someone added some category to wikidata, and then set up a popular infobox to automatically display that information when it is available. The problem is, it's not especially important information (in my opinion). I want the template to by default NOT display this information (even if it's available on wikidata), with a way to override that and display the wikidata information in any particular article.

The status quo (which displays the information no matter what) looks like:

...
| label5 = [[Dimensional_analysis#Definition|Dimension]]
| data5 = {{#if:{{{dimension|}}} |{{{dimension|}}} |{{#invoke:wd|property|P4020}} }}
...

How would I edit it so that it is possible to display this wikidata information, but it is not displayed by default? Is that even possible? --Steve (talk) 00:46, 18 January 2018 (UTC)

I don't know whether there is any practice for how to handle this but you could for example say that dimension = wikidata means pull from wikidata. Any other value is displayed, with empty or undefined meaning nothing will be displayed. Untested code:
| data5 = {{#ifeq:{{{dimension|}}}|wikidata|{{#invoke:wd|property|P4020}}|{{{dimension|}}}}}
PrimeHunter (talk) 00:59, 18 January 2018 (UTC)
@RexxS: This one should be an easy one. --Izno (talk) 17:42, 18 January 2018 (UTC)
@Sbyrnes321, PrimeHunter, and Izno: All of the code and logic for whitelisting and blacklisting fields on a per-article basis is already available in Module:WikidataIB. Looking at dimension (P4020) in electric charge (Q1111)
{{#invoke:WikidataIB |getValue |qid=Q1111 |P4020 |fetchwikidata=ALL |onlysourced=no }} → T I
You could exclude that field by default by using something like
| data5 = {{#invoke:WikidataIB |getValue |qid={{qid|}} |P4020 |name=dimension |fetchwikidata={{{{fetchwikidata|ALL}}} |suppressfields={{{suppressfields|dimension}}} |onlysourced=no |{{{dimension|}}} }}
Then in an article where you want to display dimension, add |suppressfields=none to the infobox. It may be worth studying the WikidataIB documentation to see other ways how you could use it for these sort of cases.
One caveat: it displays plain text, not Math markup because it was expressly designed for use in infoboxes, not normal article text. You would have to add the Math markup around the #invoke if you really wanted that. --RexxS (talk) 18:14, 18 January 2018 (UTC)

"A link was made from x"

Is there any way to disable these notifications on a page-by-page basis? I understand it can be disabled entirely, but I was just wondering if I could only disable it for a few popular pages that get used in references, etc. Anarchyte (work | talk) 09:51, 18 January 2018 (UTC)

Not as far as I know. There are a number of preferences which it would be useful to have set on a page-by-page basis, such as categorisation - I want to know when articles are added to certain maintenance categories but I generally don't care when articles are added to most content categories. If I turn off "Hide categorization of pages" at Preferences → Watchlist, I get a watchlist flood, and with the new 1,000-entry maximum, I could easily miss out on edits more than a day or so earlier. --Redrose64 🌹 (talk) 12:21, 18 January 2018 (UTC)

Proposals

RfC: Populating article descriptions magic word

In late March - early April 2017, Wikipedia:Village pump (proposals)/Archive 138#Rfc: Remove description taken from Wikidata from mobile view of en-WP ended with the WMF declaring[54] "we have decided to turn the wikidata descriptions feature off for enwiki for the time being."

In September 2017, it was found that through misunderstanding or miscommunication, this feature was only turned off for one subset of cases, but remained on enwiki for other things (in some apps, search results, ...) The effect of this description is that e.g. for 2 hours this week, everyone who searched for Henry VIII of England or saw it through those apps or in "related pages" or some such got the description "obey hitler"[55] (no idea how many people actually saw this, this Good Article is viewed some 13,000 times a day and is indefinitely semi-protected here to protect against such vandalism).

The discussion about this started in Wikipedia:Village pump (policy)/Archive 137#Wikidata descriptions still used on enwiki and continued mainly on Wikipedia talk:Wikidata/2017 State of affairs (you can find the discussions in Archive 5 up to Archive 12!). In the end, the WMF agreed to create a new magic word (name to be decided), to be implemented if all goes well near the end of February 2018, which will replace the use of the Wikidata descriptions on enwiki in all cases.

We now need to decide two things. Fram (talk) 09:58, 8 December 2017 (UTC)

How will we populate the magic word with local descriptions?

  1. Initially, copy the Wikidata descriptions by bot
  2. With a bot, use a stripped version of the first sentence of the article (the method described by User:David Eppstein and User:Alsee in Wikipedia talk:Wikidata/2017 State of affairs/Archive 5#Wikipedia descriptions vs Wikidata descriptions)
  3. With a bot, use information from the infobox (e.g. for people a country + occupation combination: "American singer", "Nepali politician", ...)
  4. Start with blanks and fill in manually (for all articles, or just for BLPs)
  5. Start with blanks, allowing to fill in manually and/or by bot (bot-filling after successful bot approval per usual procedures)
  6. Other

Discussion on initial population

  • #5 – allows bot operations for larger or smaller sets of articles per criteria that don't have to be decided all at once, and manual overrides at all times. --Francis Schonken (talk) 10:28, 8 December 2017 (UTC)
  • #5 is my preference following the reasoning below:
    Option 1, copying from Wikidata, will populate Wikipedia with a lot of really bad descriptions, which will remain until someone gets around to fixing them. My initial rough estimates are that there are more bad/nonexistent Wikidata descriptions than good ones. I strongly oppose this option unless and until someone comes up with solid data indicating that it will be a net gain.
    Option 2, extracting a useful description from the first sentence or paragraph seems a nice idea at first glance, but how will it be done? Has anyone promoting this option a good idea of how effective it would be, how long it would take, and if it would on average produce better descriptions than option 1? This option should be considered unsuitable until some evidence is provided that it is reasonably practicable and will do more good than harm.
    Option 3, copying from the infobox, may work for some of the articles that actually have an infobox with a useful short description, or components that can be assembled into a useful short description. This may work for a useful subset of articles, but it is not known yet how many. I would guess way less than half so not a good primary option.
    Option 4, start with blanks and fill in manually, is probably the only thing that can be done for a large proportion of articles, my guess in the order of half. It will have to be done, and is probably the de facto default. It is easy, quick and will do no harm. It is totally compatible with option 5, for which it is the first step.
    Option 5 is starting with option 4 and applying ad hoc local solutions which can be shown to be useful. Any harm is localised, Wikidata descriptions can be used when they are appropriate, extracts from leads can be used when appropriate, mashups from infoboxes can be used when appropriate, and manual input from people who actually know what the article is about can be used when appropriate. I think there is no better, simpler, and more practical option than this, and suggest that projects should consider how to deal with their articles. WPSCUBA already has manually entered short descriptions ready for use for more than half of its articles, which I provided as an experiment. It is fairly time consuming, but gets easier with practice. Some editors may find that this is a fun project, others will not, and there will inevitably be conflicts, which I suggest should be managed by BRD as simple content disagreements, to be discussed on talk pages and finalised by consensus. In effect, option 5 is the wiki way. It is simple and flexible, and likely to produce the best results with the least amount of damage. · · · Peter (Southwood) (talk): 11:26, 8 December 2017 (UTC)
    (There was an edit conflict here and I chose to group all my comments together · · · Peter (Southwood) (talk): 11:26, 8 December 2017 (UTC))
  • #5. Whether a Wikidata description is suitable or not is very different across many groups of articles. It should be decided (and possibly bot populated) per group, sometimes per small group, and for that we need to start from blank descriptions.--Ymblanter (talk) 11:23, 8 December 2017 (UTC)
  • Start with not using it anywhere, only use it as override per situation. —TheDJ (talkcontribs) 12:09, 8 December 2017 (UTC)
    TheDJ, To clarify, is this an Option 6: Other that you are proposing here? i.e. Only add the magic word to articles where the Wikidata short description is unsuitable, and use Wikidata description as default in all cases until someone finds a problem and adds a magic word, after which the short description will be taken from the magic word? If this is the case, what is your opinion on reverting to Wikidata description for any reason at a later date? · · · Peter (Southwood) (talk): 14:53, 8 December 2017 (UTC)
    @Pbsouthwood: Correct. I have no opinions on reverting at a later moment. —TheDJ (talkcontribs) 13:42, 11 December 2017 (UTC)
  • #5. That doesn't deal with all the issues, but it comes closest to my views, given the choices. See also my comments at WT:Wikidata/2017 State of affairs/Archive 12 and WT:Wikidata/2017 State of affairs. - Dank (push to talk) 14:06, 8 December 2017 (UTC)
    • Peter asked me for clarification. If people have specific questions, or if they want a summary of my previous posts, I'll do my best to answer. - Dank (push to talk) 15:30, 8 December 2017 (UTC)
    • To whoever closes this: the discussion started here seems to be continuing at a new RfC at Usage of Wikidata links. - Dank (push to talk) 15:18, 16 January 2018 (UTC)
  • #5 but don't wait too long to fill in where possible. Fram (talk) 14:14, 8 December 2017 (UTC)
    Fram Are you recommending a massive short term drive to produce short descriptions to make the system useful? · · · Peter (Southwood) (talk): 15:09, 8 December 2017 (UTC)
    • Yes, although this isn't in my view necessary to proceed with this, only preferable. No descriptions is better than the current situations, but decent enwiki-based descriptions is in many cases better than no descriptions. No need to throw out the baby (descriptions to be shown in search and so on) with the bathwater. Fram (talk) 15:21, 8 December 2017 (UTC)
  • #6 - don't use it. There has been no consensus to have this magic word in the first place - that is the question that should have been asked in this RfC (see discussion here). I personally think it is a bad idea and a waste of developer time. It's better to focus on improving the descriptions on Wikidata instead. Mike Peel (talk) 15:27, 8 December 2017 (UTC)
  • #6 — Find a solution that monitors and updates Wikidata descriptions — If a description is good enough for Wikipedia(ns), it should be on Wikidata. If vandalism is blocked on Wikipedia, it should be simultaneously reverted on Wikidata. Wikidata is the hub for interwiki links and a storage site for both descriptions and structured data that then are harvested by external knowledge-based search engines (think Siri, Alexa, and Google's Knowledge Graph). For interwiki purposes, we should want to ensure that short descriptions at Wikidata are accurate, facilitating other language Wikipedias when they interlink to en.wiki. For external harvesting, we should want to prevent vandalism from being propagated. The problems regarding vandalism and sourcing on Wikidata are real, but the solution is for Wikipedians and our anti-vandalism bots to be able to easily monitor and edit the relevant Wikidata material. Possible solutions would include: (a) Implementing a pending changes-like functionality for changes to descriptions on high-traffic or contentious pages; (b) Make changes to short descriptions prominently visible on Wikipedia watchlists, inside the VisualEditor, and as a preference option for Wikipedia editors; (c) Develop and implement in-Wikipedia editing of Wikidata short descriptions using some kind of click-on-this-pencil tool.--Carwil (talk) 15:46, 8 December 2017 (UTC)
    • After those solutions are implemented, you are free to ask for an rfC to overturn the consensus of the previous RfC which decided not to have these descriptions. This RfC is a discussion to get solutions which give you what you want on enwiki (descriptions in VE, mobile, ...) without interfering in what Wikidata does (they are free to have their own descriptions or to import ours). Fram (talk) 16:01, 8 December 2017 (UTC)
    Carwil, How do you propose that Wikipedia controls access by vandals to Wikidata? Are you suggesting that Wikipedia admins should be able to protect Wikidata items and block Wikidata users?
    The easy options are… "undo" functionality for Wikidata descriptions in Wikipedia watchlists, and option (a) I proposed above, something like pending-changes that protects pages on Wikipedia from unreviewed changes from Wikidata. Transferring anti-vandalism bots from Wikipedia to Wikidata would also be helpful.--Carwil (talk) 16:47, 8 December 2017 (UTC)
    Cluebot already runs on Wikidata. ChristianKl (talk) 15:19, 17 December 2017 (UTC)
  • Strongly oppose 4 and strongly oppose 5—Let's reject any solution that mass-blanks short descriptions: these are a functional part of mobile browsing and of the VisualEditor. As an editor and a teacher who brings students into editing Wikipedia, the latter functionality is a crucial timesaver. Wikipedia is increasingly accessed by mobile devices and short descriptions prevent clicking through to a page only to find it's not the one you are looking for.--Carwil (talk) 15:46, 8 December 2017 (UTC)
    • Note, this is a double vote, Carwil already expressed a bolded "support" above... Fram (talk) 10:11, 8 January 2018 (UTC)
    Have you analysed the overall usefulness of Wikidata descriptions and found that there are more good descriptions than bad, or found a way to find all the bad ones so they can be changed to good? If so please point to your methods and results, as they would be extremely valuable. What methods have you used to indicate the comparative harm done by bad descriptions versus the good done by good descriptions? · · · Peter (Southwood) (talk): 16:14, 8 December 2017 (UTC)
Yes, I have analyzed a sample here. I found that 13 of 30 had adequate descriptions (though 7 of them could be improved), 13 had no descriptions at all, 1 was incorrectly described (not vandalism), 2 were redundant with the article title (i.e., they should be overridden with a blank), and 1 represented a case where the Wikipedia article and the Wikidata entity were not identical and shouldn't share the same description. The redundant descriptions would cause no harm. Mislabelling "Administrative divisions of Bolivia" with the subheading "administrative territorial entity of Bolivia" would cause mild confusion. The legibility provided by descriptions easily outweigh the harms. (The only compelling harm is due to vandalism, which should be addressed by improving vandalism tools not forking the descriptions between the projects.)--Carwil (talk) 16:47, 8 December 2017 (UTC)
The options 4 and 5 are not to blank anything, they are to put short descriptions, which are text content, into the article they describe, where they can be properly, (or at least better), maintained, by people who may actually know what the article is about. Wikidata can use them if their terms of use allow, and if they are actually better for Wikidata's purposes, which is by no means clear at present. · · · Peter (Southwood) (talk): 16:14, 8 December 2017 (UTC)
Options 4 and 5 involve starting with blanks everywhere. The whole proposal assumes that we should fork a dataset describing Wikipedia articles into two independently editable versions. Forking a dataset always creates inconsistencies and reduces the visibility of problems by splitting the number of eyes to watch for problems. Better to make Wikipedians' eyes more powerful and spotting problems (which are unusual) rather than to throw up wall between the two projects. My sample suggests that 90% of the time, or more, the two projects are working towards the same goal here.--Carwil (talk) 16:47, 8 December 2017 (UTC)
They do, but it is unlikely the WMF will switch until the Wikipedia results are no worse than the Wikidata results, though I have no idea how they would measure that, since they don't seem to have much idea of the quality they will be comparing against, or if they do, are not keen on sharing it.
The dataset does not suit Wikipedia. We should not be forced to use it. A dataset that suits Wikipedia may not suit Wikidata. Should we force it on them? Two datasets means Wikipedia can look after their own, and Wikidata can use what they find useful from it, and Wikipedians are not coerced into editing a project they did not sign up for. Using shitty quality data on Wikipedia to exert pressure on Wikipedians to edit Wikidata may have a backlash that will harm either or both projects, not a risk I would be willing to take, if it could affect my employment, unless of course I was being paid to damage the WMF, but that would be conspiracy theory, and frankly I think it unlikely.
I also did a bit of a survey, my results do not agree with yours, and they are also from such a small sample as to be statistically unreliable. I also wrote short descriptions for about 600 articles in WPSCUBA, but did not keep records. Most (more than half) articles needed a new description as the Wikidata one either did nor exist or was inappropriate. There were some which were perfectly adequate, but less than half of the ones that actually existed, from memory. It would be possible to go back and count, but I think it would be a better use of my time to do new ones, if anyone is willing to join such a project. Maybe Wikiproject Medicine, or Biography, where quality actually may have real life consequences, but I don't usually work much in those fields and hesitate to move into them without some project participation. I have already run into occasional unfriendly reactions where projects overlap, but fortunately very few. · · · Peter (Southwood) (talk): 18:18, 8 December 2017 (UTC)
  • @Pbsouthwood: I don't think there's much daylight between Wikipedia's purpose for these descriptions (which hasn't been written yet), the value of them for the mobile app, the value of them for the VisualEditor (as disambiguators for making links), and the value for Wikidata as discussed here. There, the requirements include: "a short phrase designed to disambiguate items with the same or similar labels"; avoiding POV, bias, promotion, and controversial claims; and avoiding "information that is likely to change." Only the last one seems likely to differ from the ideal Wikipedia description and only marginally: e.g., "current president of the United States" would have to be replaced with "45th president of the United States."--Carwil (talk) 22:11, 12 December 2017 (UTC)
  • There have been extensive discussions between community and WMF on the description issue. I wish this RFC had gone through a draft stage before posting. There may be other options or issues that may need to be sorted out, potentially affecting the outcome here. A followup RFC might be needed.
    The previous RFC[56] consensus was clearly to eliminate wikidata-descriptions, and that is definitely my position. An alternate option would be to skip creating a description-keyword at all, and just take the description from the lead sentence. That has the benefits of (1) ensuring all articles automatically have descriptions (2) avoiding any work to create and maintenance on descriptions and (3) it would avoid creating a new independent independent issue of description-vandalism. The downside is that the lead sentence doesn't always make for a great short description.
    If we go with a new description keyword, #5 #2 and #1 are all reasonable. (#3 and #4 are basically redundant to bot approval in #5). However as I note in the question below, #5 can be implemented with a temporary wikidata-default. This gives us time to start filling in local-descriptions before the wikidata-descriptions are shut off. This would avoid abruptly blanking descriptions. Alsee (talk) 21:49, 8 December 2017 (UTC)
  • #2, with #5 as a second preference. The autogenerated descriptions look like they're good enough for most purposes. Sandstein 16:14, 10 December 2017 (UTC)
    Sandstein, How big was your test sample, and how were the examples chosen? · · · Peter (Southwood) (talk): 16:36, 10 December 2017 (UTC)
  • 5. Mass-importing WD content defeats the purpose of getting rid of WD descriptions. James (talk/contribs) 16:30, 11 December 2017 (UTC)
    Only true for a limited period until someone gets round to changing them where necessary. If the problem is big enough, there will be bot runs to do fixes, so over a medium term it does not make much difference as once the descriptions are in Wikipedia we can fix them as fast as we can make arrangements to do so and will no longer be handicapped by WP:ICANTHEARTHAT obfuscations from WMF. The important part is to get them where we have the control so we can start work getting them right. · · · Peter (Southwood) (talk): 07:47, 13 December 2017 (UTC)
  • 5 Basically what Peter said. In some areas, the wikidata descriptions will be good. In others the first sentence stripping will be good. In some data from infoboxes can be used. Etcetera. Galobtter (pingó mió) 16:20, 19 December 2017 (UTC)
  • 5 - Having just read the discussions on this I'm absolutely astounded that so much vandalism has taken place, Anyway back on point Wikidata is beyond useless when it comes to dealing with vandalism and as such 5 is the best way of dealing with it!. –Davey2010 Merry Xmas / Happy New Year 23:24, 27 December 2017 (UTC)
  • Combination of 1 and 5. Important but keep hidden until reviewed on WP. Doc James (talk · contribs · email) 06:19, 30 December 2017 (UTC)
  • #6 Retain Wikidata descriptions and bypass only those not needed Eventually all Wikipedias will have to use Wikidata. Moving back and forth make no much sense. The only thing we could do is possibly add functions to update Wikidata directly and retain functionality to bypass magic word locally. -- Magioladitis (talk) 15:56, 30 December 2017 (UTC)
    • Circular reasoning. "Use Wikidata because we will have to use Wikidata"? Fram (talk) 10:11, 8 January 2018 (UTC)
  • 5 - For reasons stated by others above. Tony Tan · talk 04:17, 17 January 2018 (UTC)

What to do with blanks

What should we do when there is no magic word, or the magic word has no value?

  1. Show the Wikidata description instead
  2. Show no description
  3. Show no description for a predefined list of cases (lists, disambiguation pages, ...) and the Wikidata one otherwise (this is the solution advocated by User:DannyH (WMF) at the moment)
  4. Other
  5. A transition from #1 to #2. In the initial stage, any article that lacks a local description will continue to draw a description from Wikidata. We deploy the new description keyword and start filling in local descriptions which override Wikidata descriptions. Once we have built a sufficient base of local descriptions, we finalize the transition by switching-off Wikidata descriptions completely. (Note: Added 16:34, 6 January 2018 (UTC). Previous discussion participants have been pinged to discuss this new option in subsection Filling in blanks: option #5.)

Discussion on blanks

  • #2 – comes closest to having no description per initial aborted RfC; those who want them can write them, or fill in automatically (per usual bot approval procedures). --Francis Schonken (talk) 10:28, 8 December 2017 (UTC)
    • No reasonable variant/alternative/compromise has been proposed since I supported #2 a month ago. Please replace DannyH as an intermediary (not the first time I suggest this): they have been pretty clear about their inability to propose anything tangible. The well-being of the Wikipedia project should not be left in the hands of those who are a paid to improve the project but can deliver next to nothing. --Francis Schonken (talk) 10:37, 8 January 2018 (UTC)
  • #5 as a reasonable compromise per various discussions below. · · · Peter (Southwood) (talk): 18:24, 6 January 2018 (UTC) #2 The Wikidata description should not be allowed as a default where there is no useful purpose to be served by a short description. An empty parameter to the magic word must be respected as a Wikipedia editorial decision that no short description is wanted. This decision can always be discussed on the talk page. Under no circumstances should WMF force an unwanted short description from Wikidata as a default. Nothing stops anyone from manually adding a description which is also used by Wikidata, but that is a personal decision of the editor and they take personal responsibility as for any other edit. Automatically providing no description for a predefined list of classes has problems, in that those classes may not be as easily defined as some people might like to think. For example, most list articles don't need a short description, but some do. The same may be true for disambiguation pages. Leaving them blank as the first stage and not displaying a short description until a (hopefully competent) editor has added one is easy to manage for the edge cases, and may be managed by other methods per option 5 of population. It is flexible and can deal with all possibilities. There is no need to make it more complicated and liable to break some time. Ideally the magic word could be given a comment in place of a parameter where an explanation of why there should not be a short description would be useful. In this case the comment should not be displayed and is there to inform editors who might wonder if it had been missed. · · · Peter (Southwood) (talk): 11:43, 8 December 2017 (UTC)
  • #1 - Show the wikidata description in stead. —TheDJ (talkcontribs) 12:10, 8 December 2017 (UTC)
  • #2. No magic word (and magic word with no parameter) should result in no description, not some non-enwiki data being confusingly shown to readers (while being missed by most vandalism patrollers apparently). Today, for 8 hours, we had this blatant BLP violation on a page with 10,000 pageviews per day. Using these descriptions by default (or at all) is a bad idea, and was rejected at the previous RfC. Fram (talk) 14:21, 8 December 2017 (UTC)
Top read sep 17 2017.png
  • #1 - From the WMF: We're proposing using Wikidata as the fallback default if there isn't a defined magic word on Wikipedia, because short descriptions are useful for readers (on the app in search results, in the top read module, at the top of article pages) and for editors (in the Visual Editor link dialog). For example: in the top read module from September pictured here, 3 of the 5 top articles benefit from having a short description -- I don't know who Gennady Golovkin and Canelo Álvarez are, and having them described as "Kazakhstani boxer" and "Mexican boxer" tells me whether I'm going to be interested in clicking on those. (The answer on that is no, I'm not really a boxing guy.) I know that Mother! is a 2017 film, but I'm sure there are lots of people who would find that article title completely baffling without the description. Clicking through to the full list of top read articles, there are a lot of names that people wouldn't know -- Amber Tamblyn, Arjan Singh, Goran Dragić. This is a really popular feature on the apps, and it would be next to useless without the descriptions.
We want to create the magic word, so that Wikipedia editors have editorial control over the descriptions, which they should. But if the magic word is left blank on Wikipedia -- especially in the cases where Wikipedia editors haven't written a description yet -- then for the vast majority of cases, showing the description from Wikidata is better than not showing anything at all. As a reader looking at that top read module, I want to know who Gennady Golovkin is, and the module should say "Kazakhstani boxer," whether that text comes from Wikipedia or Wikidata.
I know that a big reason why people are concerned about showing the Wikidata descriptions is that the Wikidata community may sometimes be slower than the Wikipedia community to pick up on specific examples of vandalism. The example that Fram cites of Henry VIII of England showing "obey hitler" for two hours is disappointing and frustrating. However, I think that the best solution there should be to improve the community's ability to monitor the short descriptions, so that vandalism or mistakes can be spotted and reverted more quickly. The Wikidata team has been working on providing more granular display in watchlists on Wikipedia, so that Wikipedia editors can see edits to the descriptions for the articles that they're watching, without getting buried by other irrelevant edits made to that Wikidata item. That work is being tracked in this Phabricator ticket -- phab:T90436 -- but I'm not sure what the current status is. Ping for User:Lydia Pintscher (WMDE) -- do you know how this is progressing?
Sorry for only getting back to this now. It slipped through. So we have continued working on improving which changes show up in the recent changes and watchlist here from Wikidata. Specifically we have put a lot of work into scaling the current system, which is a requirement for any further improvements. We have made the changes we are sending smaller and we have made it so that less changes are send from Wikidata to Wikipedia. We have also rolled out fine-grained usage tracking on more wikis (cawiki, cewiki, kowiki, trwiki) to see how it scales. With fine-grained usage tracking you will no longer see changes in recent changes and watchlist that do not actually affect an article like it is happening now. The roll-outs on these wikis so far looks promising. In January we will continue rolling it out to more wikis and see if it scales enough for enwiki. At the same time we will talk to various teams at the developer summit in January to brainstorm other ways to make the system scale better or overhaul it. --Lydia Pintscher (WMDE) (talk) 09:31, 19 December 2017 (UTC)
We've talked in the previous discussions about types of pages where the Wikidata descriptions aren't useful for article display, because they're describing the page itself, rather than the subject of the article. The examples that I know right now are category pages (currently "Wikimedia category page"), disambiguation pages ("Wikimedia disambiguation page"), list pages, and the main page. Those may be helpful in the case of the VE link dialog, especially "disambiguation page", but there's no reason to display those at the top of the article page, where they look redundant and kind of silly. We're proposing that we just filter those out of the article page display, and anywhere else where they're unnecessary. I'd like to know more examples of pages where short descriptions aren't useful, if people know any.
For article pages, I don't know of any examples so far where a blank description would be better for the people who need them (people reading, searching or adding links on VE). If we're going to build the "show a blank description" feature, then we need to talk about specific use cases where that would be the best outcome. That's how product development works -- you don't build a feature, if you don't have any examples for where it would be useful. If people have specific examples, then that would help a lot. -- DannyH (WMF) (talk) 14:58, 8 December 2017 (UTC)
"For article pages, I don't know of any examples so far where a blank description would be better " Check the two examples of vandalism on pages with 10K+ pageviews per day I gave in this very discussion, including one very blatant BLP violation which lasted for 8 hours today. In these examples, a blank description would have been far preferable over the vandalized one, no? Both articles, by the way, are semi-protected here, so that vandalism couldn't have done by the IPs here (and would very likely have been caught much earlier). "specific use cases where that would be the best outcome." = all articles, and certainly BLPs. Fram (talk) 15:19, 8 December 2017 (UTC)
Better than no description?
If you want another example of where no description would be preferable over the Wikidata one, look to the right. This is what people who search for WWII (or have it in "related articles", the mobile app, ... see right now and have seen since more than 5 hours (it will undoubtedly soon be reverted now that I have posted this here). This kind of thing happens every day, and way too often on some of our most-viewed pages. Fram (talk) 15:38, 8 December 2017 (UTC)
I agree that the vandalism response rate on Wikidata is sometimes too slow. I think the solution to that is to make that response rate better, by making it easier for Wikipedia editors to monitor and fix vandalism of the descriptions. I disagree that the best solution is to pre-emptively blank descriptions because we know that there's a possibility that they'll be vandalized. I'm asking for specific examples where editors would make the choice to not show a description on the article page, because a blank description is better than the majority of good-to-adequate descriptions already on Wikidata. -- DannyH (WMF) (talk) 16:10, 8 December 2017 (UTC)
And I am saying that this is a red herring. Firstly, you claim that there exists a majority of good-to adequate descriptions on Wikidata, without any convincing evidence that this is the case. I am stating that out of several hundred short descriptions that I produced, there were a non-zero number of cases where a short description made no apparent improvement over the article title by itself. · · · Peter (Southwood) (talk): 16:21, 8 December 2017 (UTC)
DannyH (WMF), Filtering descriptions out of the article page view means that they will be invisible for maintenance which is very bad, unless they are filtered out based on content, not on page type, which may be technically problematic - you tell me, I don't write filter code. Can you guarantee that no vandalism can sneak through by this route?. As long as they are visible anywhere in association with the Wikipedia article they are a Wikipedia editorial issue. · · · Peter (Southwood) (talk): 15:39, 8 December 2017 (UTC)
We are not asking for a development feature to leave out descriptions that don't exist, it is the simplest possible default. Please try to accept that simply displaying whatever content is in the magic word parameter is the simplest and most versatile solution, and that if we leave it blank that is because we prefer it to be left blank. If anyone prefers to have a short description in any of these cases, they can edit Wikipedia to put in the one they think is right, and if anyone disagrees strongly enough to want to remove it, they can follow standard procedure for editorial disagreement, which is get consensus on the talk page. It is not rocket science, it is the Wikipedia way of doing these things. If it is difficult for the magic word to handle a comment in the parameter we can simply put the comment outside. There may be a few more cases where people will fail to notice that it is there, but probably not a train smash. Is there any reason why a comment in the parameter space should not be parsed as equivalent to no description? I have asked this before, and am still waiting for an answer.· · · Peter (Southwood) (talk): 15:39, 8 December 2017 (UTC)
  • #1 - and focus on improving the descriptions on Wikidata. Mike Peel (talk) 15:27, 8 December 2017 (UTC)
    • See discussion at Wikipedia_talk:Wikidata/2017_State_of_affairs#Circular_"sourcing"_on_Wikidata - I've posted a random sample of 1,000 articles and descriptions, of which only 1 description had a typo and none seemed to be blatently wrong - although 39% don't yet have a description. So let's add those extra descriptions / improve the existing ones, rather that forking the system. Thanks. Mike Peel (talk) 00:14, 12 December 2017 (UTC)
      • That sample includes the many typical descriptions which are right on Wikidata and useless (or at least very unclear) for the average enwiki reader: "Wikimedia disambiguation page" (what is Wikimedia, shouldn't that be Wikipedia, and even then, I know I'm on Wikipedia, and we don't use "Wikipedia article" as description for standard articles either...) There are also further typos ("British Slavation Army officer"), useless descriptions ("human settlement", can we be slightly more precise please), redundant ones (Shine On (Ralph Stanley album) - "album by Ralph Stanley")... And the basic issue, that language-based issues shouldn't be maintained at Wikidata but at the specific languages, is not "forking", it is taking back content which doesn't belong at Wikidata but at enwiki. Fram (talk) 05:45, 12 December 2017 (UTC)
    • You may add "Descriptions not in English" to the problems list from that sample: "Engels; schilder; 1919; Londen (Engeland); 1984". Fram (talk) 06:01, 12 December 2017 (UTC)
    • And "determined sex of an animal or plant. Use Q6581097 for a male human" is not really suitable for use on enwiki either (but presumably perfect for Wikidata). Neeraj Grover murder case - "TV Executive" seems like the wrong description as well. Stefan Terzić - "Team handball" could also use some improvement. Fram (talk) 07:56, 12 December 2017 (UTC)
      • OK, so maybe 4/1000 have typos/aren't in English/are wrong - that's still not bad. Most of the rest seems to be WP:IDONTLIKEIT (where I'd say WP:SOFIXIT on Wikidata, but you don't want to do that). Yes, it is forking - the descriptions currently only exist on Wikidata (we've never had them on Wikipedia), and they aren't going away because of this - so you want to fork them, and in a way that means the two systems can't later be unforked (due to licensing issues). That's not helpful, particularly in the long term. Mike Peel (talk) 19:58, 12 December 2017 (UTC)
        • I gave more than 4 examples, some 40% don't have a description (so can hardly be wrong, even if many of those need a description), and many have descriptions we can't or shouldn't use. Basically, you started with 0.1% problem in your view, when it is closer to 50% in reality. Please indicate which licensing issues you see which would make unforking impossible. It seems that these non-issues would then also make it impossible to import the Wikidata descriptions, no? Seems like a red herring to me. By the way, have you ever complained about forking when Wikidata was populated with millions of items from enwiki (and other languages), where from then on they might evolve separately? Or is forking only an issue when it is done from Wikidata to enwiki, and not the reverse? Fram (talk) 22:28, 12 December 2017 (UTC)
          • Only a few of your example problems seem to be actual problems, the rest are subjective. You're proposing that we switch to 100% without description, so I can't see how you can argue about the 40% blank descriptions (and they weren't a problem at the start of this discussion). I'm not saying 0.1%, but ~1% seems reasonable here. Enwp descriptions are CC-BY-SA licensed, which means they can't be simply copied to Wikidata as that has a CC-0 license (and yes, this isn't great, and copyrighting the simple descriptions doesn't make any sense, but it is what it is) - although that means that we can still copy from Wikidata to here if needed. I'm complaining that we're forking things here to do the same task (describing topics), and that we're trying to do so using the wrong tool (free text with hacks) rather than a better tool (a structured database). Mike Peel (talk) 23:01, 12 December 2017 (UTC)
            • Ah, the old "structured database" vs "free text with hacks" claim, I wondered why it wasn't mentioned yet. In Wikidata, you are putting free text in a database field, which then at runtime gets read and displayed. In enwiki, you are putting free text in a "magic word" template, which then at runtime gets read and displayed. Pretending that the descriptions in Wikidata aren't free text and in enwiki are free text is not really convincing. However, what is the wrong tool for the task is Wikidata, as that is not part of the enwiki page history and wikitext, and thus can't be adequately monitored, protected, ... The only "hack" is the current one, using Wikidata to do something enwiki can do better (and which philosophically also belongs on enwiki, as it is language-based text, not some universally accepted value). Fram (talk) 07:53, 13 December 2017 (UTC)
  • #2, or transition from #1 to #2. I have engaged significant discussions with the WMF on the descriptions-issue on the Wikidata/2017 State of affairs talk page. The WMF has valid concerns about abruptly blanking descriptions, and we should try to cooperate on those concerns. Temporarily letting a blank keyword default to wikidata (#1) will give us time to begin filling empty local descriptions before shutting off wikidata descriptions (#2). But in the long run my position is definitely #2. Alsee (talk) 21:02, 8 December 2017 (UTC) Adding explicit support for #5, which is essentially matches my original !vote. Alsee (talk) 16:36, 6 January 2018 (UTC)
    This could work. While we are filling in short descriptions, whenever we find an article that should not have a short description, we could put in a non-breaking space to override an unnecessary Wikidata description. We will need to see the actual display shown on mobile on desktop too, so we can see what we are doing. As long as there is a display of the short description in actual use on desktop, it might be unnecessary to switch. That would reduce the pressure to rush the process, which may be a good thing, but also may not. · · · Peter (Southwood) (talk): 10:12, 9 December 2017 (UTC)
    Alsee, thanks. I've been staying out of conversations about if/when/how the magic word gets used/populated, because I think those are the content decisions that need to be made by the English WP community. I want to figure out how we can get to the place where Wikipedia editors have proper editorial control over the short descriptions, without hurting the experience of the readers and editors who are using those descriptions now. -- DannyH (WMF) (talk) 23:29, 11 December 2017 (UTC)
You can enable a view of the Q-code, short description and alias via this script: [[57]].--Carwil (talk) 13:01, 9 December 2017 (UTC)
Carwil, This is exactly the kind of display I had in mind. It is easily visible, but obviously not part of the article per se, as it is displayed with other metadata in a different text size. To be useful it would have to be visible to all editors who might make improvements to poor quality descriptions, so would have to be a default display on desktop. This may not be well received by all, but it would be useful, maybe as an opt-out for those who really do not want to know. It still does not deal with the inherent problems of having the description on Wikidata, in that it is not Wikipedia and we do not dictate Wikidata's content policies, control their page protection, block their vandals etc, but it does let us see what is there, and fixing is actually quite easy, though maybe I am biased as I have done a fair amount of work on Wikidata. I would be interested to hear the opinions of people who have not previously edited Wikidata on using this script. I can definitely recommend it to anyone who wants to monitor the Wikidata description. Kudos to Yair rand.· · · Peter (Southwood) (talk): 16:15, 9 December 2017 (UTC)
It also does not solve the problem of different needs for the description. When the Wikidata description is unsuitable for Wikipedia, we should not arbitrarily change it if it is well suited to Wikidata's purposes, but if it is going to be used for Wikipedia, we may have to do just that.· · · Peter (Southwood) (talk): 16:21, 9 December 2017 (UTC)
  • #2. Any Wikidata import should be avoided because that content is not subject to Wikipedia editorial control and consensus. Sandstein 16:16, 10 December 2017 (UTC)
    Sandstein, My personal preference is that eventually all short descriptions should be part of Wikipedia, and not imported in run time, however, as an interim measure, to get things moving more quickly, I see some value in initially displaying the Wikidata description as a default for a blank magic word parameter, as it is no worse than what WMF are already doing, and in my opinion are likely to continue doing until they think the Wikipedia local descriptions are better on average. If anyone finds a Wikidata description on display that is unsuitable, all they have to do is insert a better one in the magic word and it immediately becomes a part of Wikipedia. If you find a Wikidata description that is good, you can also insert it into the magic word and make it local, as they are necessarily CC0 licensed. The only limitation on getting 100% local content is how much effort we as Wikipedians are prepared to put into it. Supporters of Wikidata can improve descriptions on Wikidata instead if that is what they prefer to do, and as long as a good short description is displayed, it may happen that nobody feels strongly enough to stop allowing it to be used. I predict that whenever a vandalised description is spotted, most Wikipedians will provide a local short description, so anyone in favour of using Wikidata descriptions would be encouraged to work out how to reduce vandalism and get it fixed faster, which will greatly improve Wikidata. Everybody wins, maybe not as much as either side would prefer, but more than they might otherwise. As it would happen, WMF win the most, but annoying as that may be to some, we can live with it as long as we also have a net gain for Wikipedia and Wikidata. · · · Peter (Southwood) (talk): 16:58, 10 December 2017 (UTC)
  • 2. We have neither the responsibility nor the authority to enforce WP guidelines on a project with diametrically opposed policies. Content outside of WP's editorial control should not appear on our pages, period. James (talk/contribs) 16:34, 11 December 2017 (UTC)
  • 2 comes closest to my views, given the choices. See my comments at WT:Wikidata/2017 State of affairs/Archive 12 and WT:Wikidata/2017 State of affairs. Also see the RfC from March; most of what was said there is equally relevant to the current question. - Dank (push to talk) 21:01, 11 December 2017 (UTC)
  • Comment from WMF: I want to say a word about compromise and consensus. I've been involved in these discussions for almost three months now, and there are a few things that I've been consistent about.
First is that I recognize and agree that the existing feature doesn't allow Wikipedia editors to have editorial control over the descriptions, and it's too difficult for Wikipedia editors to see the existing descriptions, monitor changes, and fix problems when they arise. Those are problems that need to be fixed, by the WMF product team and/or the Wikidata team.
Second: the way that we fix this problem doesn't involve us making the editorial decisions about the format or the content. That's up to the English Wikipedia and Wikidata communities, and if there's disagreement between people in those communities, then ultimate control should be located on Wikipedia and not on Wikidata. In other words: when we build the magic word, we're not going to control how it's used, how often, or what the format should be. I think that both of these two points are in line with what most of the people here are saying.
The third thing is that we're not going to agree to a course of action that results in the mass blanking of existing descriptions, for any meaningful length of time. I recognize that that's something that most of the people here want us to build, but that would be harmful to the readers and editors that use those descriptions, and that matters. This solution needs to have consensus with us, too, because we're the ones who are going to build it. I'm not saying that we're going to ignore the consensus of this discussion; I'm saying that we need to be a part of that consensus. -- DannyH (WMF) (talk) 15:13, 12 December 2017 (UTC)
How many people have actually complained in the 8 months or so that descriptions have now been disabled in mobile view? "readers and editors that use those descriptions": which editors would that be? Anyway, basically you are not going to interfere in content decisions, unless you don't like the result. But at the same time you can't be bothered to provide the necessary tools to patrol and control your features (and your first point is rather moot when this magic word goes live and works as requested anyway). Which is the same thing you did (personally and as WMF) with Flow, Gather, ... which then didn't get changed, improved, gradually accepted, but simply shot down in flames, at the same time creating lots of unnecessary friction and bad blood. Have you actually learned anything from those debacles? Most people here actually want to have descriptions, and these will be filled quite rapidly (likely to a higher percentage than what is provided now at Wikidata). But we will fill them where necessary, and we will leave them blank where we want them to be blank. You could have suggested over the past few months a compromise, where either "no magic word" or "magic word with no description" would mean "take the wikidata description", and the other meant "no description". You could have suggested "after the magic word is installed, we'll take a transitional period of three months, to see if the descriptions get populated here on enwiki; afterwards we'll disable the "fetch desc from wikidata" completely". Instead you insisted that the WMF would have the final say and would not allow blanks unless it was for a WMF-preapproved list of articles (or article groups). Why? No idea. If the WMF is so bothered that readers should get descriptions no matter what (even if many, many articles don't have Wikidata descriptions anyway in the first place), then they should hire and pay some people to monitor these and make sure that e.g. blatant BLP violations don't remain for hours or days. But forcing us to display non-enwiki content against our will and without providing any serious help in patrolling it is just not acceptable. Fram (talk) 15:44, 12 December 2017 (UTC)
Fram, those compromises are what I'm asking for us to discuss. I'm glad you're bringing them up, that's a conversation that we can have. I'm going to be talking to the Wikidata team next week about the progress on building the patrolling and moderation tools. We don't have direct control over what the Wikidata team chooses to do, but I want to talk with them about how the continued lack of a way to effectively monitor the short descriptions is affecting this conversation, this community, and the feature as a whole. English Wikipedia editors need to have the tools to effectively populate and monitor the descriptions, and you need to have that on a timeline that makes sense. I need to talk to more people, and keep working on how to make that happen. I'm going to talk with people internally about the transitional period that you're suggesting. -- DannyH (WMF) (talk) 16:04, 12 December 2017 (UTC)
I think the major concern is the lack of control over enwp content. There are currently only two outside sources of enwp content over which the local community has no control: Commons and Wikidata; it has taken some years for Commons to build a level of trust over their content policies and failsafes to prevent abuse at enwp through Commons. The only reason today that the use of Commons materials here is two-fold 1) they've proven they can handle their business, and 2) there exists local over-rides that are transparent and easy to enact. For Wikidata to be useful and to avoid the kind of acrimony we are seeing here, we would need the SAME thing from Wikidata. Point 1) can only occur over time, and Wikidata is far too new to be proven in that direction. Recent gaffes in allowing vandalism off-site at Wikidata to perpetuate at enwp does not help either. If the enwp community is going to feel good about allowing Wikidata to be useful going forward, until that trust reaches what Commons has achieved, we need point 2 more than anything. Defaulting to local control over off-site control is necessary, and any top-down policy that removes local control, either directly or as a fait accompli by subtling controlling the technology, is unlikely to be workable. If Wikidata can prove their ability to take care of their own business reliably over many years, the local community would feel better about handing some of that local control over to them, as works with Commons now. But that cannot happen today, and it cannot happen if local overrides are not simple, robust, and the default. --Jayron32 17:32, 12 December 2017 (UTC)
"English Wikipedia editors need to have the tools to effectively populate and monitor the descriptions, and you need to have that on a timeline that makes sense." You know, yiou have lost months doing this by continually stalling the discussions and "misinterpreting" comments (always in the same direction, which is strange for real misunderstandings and looks like wilful obstruction instead). You just give us the magic word, and then we have the tools to monitor the descriptions: recent changes, watchlists, page histories, ... plus tools like semi- or full protection and the like. We can even build filters to check for these changes specifically. We can build bots to populate them. From the very start, everyone or nearly everyone who was discussing these things with you has suggested or stated these things, you were the only one (or nearly the only one) creating obstacles and finding issues with these solutions where none existed. "I'm going to be talking to the Wikidata team next week about the progress on building the patrolling and moderation tools." is totally and utterly irrelevant for this discussion, even though it is something that is sorely needed in general. Patrolling and moderating Wikidata descriptions is something we are not going to do; we will patrol and moderate ENWIKI descriptions, and we have the tools to do so (a conversation may be needed whether the descriptions will be shown in the desktop version or not, this could best be a user preference, but that is not what you mean). Please stop fighting lost battles and get on with what is actually decided and needed instead. Fram (talk) 17:54, 12 December 2017 (UTC)
I'm talking to several different groups right now -- the community here, the WMF product team, and the Wikidata team -- and I'm trying to get all those groups to a compromise that gives Wikipedia editors the control over these descriptions that you need, and doesn't result in mass blanking of descriptions for a meaningful amount of time. That's a process that takes time, and I'm still working with each of those groups. I know that there isn't much of a reason for you to believe or trust me on this. I'm just saying that's what I'm doing. -- DannyH (WMF) (talk) 18:02, 12 December 2017 (UTC)
Indeed, I don't. I'm interested to hear why you would need to talk to the Wikidata team to find a compromise about something which won't affect the Wikidata team one bit, unless you still aren't planning on implementing the agreed upon solution and let enwiki decide how to deal with it. Fram (talk) 22:28, 12 December 2017 (UTC)
Fram, you're saying "us", "we", etc. here rather freely. Please do not speak for all editors here, particularly when putting your own views forward at the same time. There's a reason we have RfC's... Thanks. Mike Peel (talk) 21:11, 12 December 2017 (UTC)
Don't worry, I'm not speaking for you. But we (enwiki) had an RfC on this already, and it's the consensus from there (and what is currently the consensus at this RfC) I'm defending. There's indeed a reason we have RfC's, and some of us respect the results of those. Fram (talk) 22:28, 12 December 2017 (UTC)
I'm glad you're not speaking for me - but why are you trying to speak for everyone except for me? What consensus are you talking about, this RfC is still running (although I'm worried that potential participants are being scared off by these arguments in the !vote sections)? And what consensuses are you accusing me of disrespecting? Mike Peel (talk) 22:40, 12 December 2017 (UTC)
FWIW, Fram definitely speaks for me. James (talk/contribs) 23:24, 12 December 2017 (UTC)
You don't really seem to care about the results of the previous RfC on this, just like you didn't respect the result of the WHS RfC when your solution was not to revert to non-Wikidata versions, but to bot-move the template uses to a /Wikidata subpage which was identical to the rejected template. Basically, when you have to choose between defending Wikidata use on enwiki or respecting RfCs, you go with the former more than the latter. Fram (talk) 07:53, 13 December 2017 (UTC)
──────────────────────────────────────────────────────────────────────────────────────────────────── ok... I propose that from this point on, DannyH, User:Mike Peel and User:Fram, cease any further participation in this RfC. You three and your mutual disagreements are again completely dominating the discussion, the exact thing that the Arbcom case was warning against. This is NOT helping the result of this discussion. —TheDJ (talkcontribs) 14:24, 13 December 2017 (UTC)
  • #3 – This makes the most sense to me for reasons I stated above. I would amend #3 only by saying: Immediately populate a local description for any pages being actively protected from vandalism which could just mean protected pages, or could mean (where appropriate) pages subjected to arbitration enforcement as well.--Carwil (talk) 18:02, 13 December 2017 (UTC)
  • #1 This whole idea is just adding complexity over a rather small problem. The less duplication on the datas, the better. We should focus on ways to follow more project add glance and focus on better tools to follow change on Wikipedia rather than splitting the Wikimedian forces on all the different project. Co-operation and sharing are the essence of these projects, not control, defiance and data duplication. TomT0m (talk) 16:34, 15 December 2017 (UTC)
  • #1 per DannyH. Additionally, we can configure protected articles to never display data from Wikidata. It's worth noting that this option allows you to run a bot that puts " " as description for a specific class of articles when you don't like the kind of descriptions that Wikidata shows for those articles. ChristianKl (talk) 15:29, 17 December 2017 (UTC)
    For clarification, Is your claim that we can configure protected articles to never display data from Wikidata based on knowing how this could be done, and that it is a reasonably easy thing to do, or a conjecture? Bear in mind how WMF is using the data on the mobile display. I ask because I do not know how they do it, so cannot predict how easy or otherwise it would be to block from Wikipedia side. Ordinary logic suggests that it may not be so easy, or it would already have been done. · · · Peter (Southwood) (talk): 04:44, 18 December 2017 (UTC)
    Without the magic keyword being active, it's not possible to easily prevent the import. However, once the feature is implemented you will be able to run a bot quite easily that creates "magic keyword = ' '" for every article that's protected or for other classes of articles where there's the belief that the class of article shouldn't import Wikidata and is better of with showing the user a ' ' instead of the Wikidata description.
    Additionally, I think the WMF should hardcode a limitation that once a Wikipedia semiprotects an article the article stops displaying Wikidata derived information. That would take some work on the WMF, but if that's what they have to do to get a compromise I think they would be happy to provide that guarantee. ChristianKl (talk) 12:31, 18 December 2017 (UTC)
    I would be both encouraged and a bit surprised to see WMF provide a guarantee. So far they have been very careful to avoid making any commitments to anything we have requested. I will believe it when I see it. I have no personal knowledge of the complexity of coding a filter that checks whether the article is protected or semi-protected and using that to control whether a Wikidata description is used that is fast and efficient enough to run every time that a short description may be displayed. but I would guess that this is an additional overhead that WMF would prefer to avoid. Requiring such additional software could also delay getting the magic word implemented, which would be a major step in the wrong direction. This needs to be simple and efficient, so the bugs will be minimised and speed maximised. Putting in a blank string parameter that displays as a blank string is easy and simple and requires no complicated extra coding. This can be done by any admin protecting an article where there is no local short description. · · · Peter (Southwood) (talk): 16:33, 18 December 2017 (UTC)
    ChristianKl, Wouldn't it make the most sense to produce a description for each protected article, rather than produce a blank? We're talking about a considerable shorter list than all articles here. Then we would have functionality (what WMF says they want) and protection from vandalism on Wikidata.--Carwil (talk) 15:23, 19 December 2017 (UTC)
    I agree with you that writing description in those cases makes sense, but the people who voted #2 seem to have the opinion that this isn't enough protection from vandalism on Wikidata and don't want that Wikidata content is shown even if the 'magic word' is empty. ChristianKl (talk) 17:55, 19 December 2017 (UTC)
  • #1 Most of the time, for most purposes, the Wikidata descriptions are fine. #1 gives a sensible over-ride mechanism for cases where there is particular sensitivity. Jheald (talk) 20:55, 17 December 2017 (UTC)
    Unless you have a reasonably robust analysis to base this prediction on, it is speculation. However it will make little difference in the long run, as it will be easy to override the Wikidata descriptions through the magic word. It is just a question of how tedious it would be, depending on what proportion of 5.5 million will have to be done.· · · Peter (Southwood) (talk): 04:44, 18 December 2017 (UTC)
  • #2 Agree with Alsee. Most sensible. Wikidata entries can be imported initially, if needed. It's easiest if things are kept on the same area, with the same community and policies. I really don't see the advantage of having things on Wikidata - the description is different for every language. Galobtter (pingó mió) 11:54, 19 December 2017 (UTC) Peter Southwood makes excellent practical points - an interim measure, to get things moving more quickly, I see some value in initially displaying the Wikidata description as a default for a blank magic word parameter, as it is no worse than what WMF are already doing too. Galobtter (pingó mió) 11:58, 19 December 2017 (UTC) Addendum, #5 is basically it, yeah. What matters is in the long-run it's there here. Galobtter (pingó mió) 07:21, 10 January 2018 (UTC)
Galobtter—Wikidata has a data structure that maintains separate descriptions for each language (or at least each language with a Wikipedia).--Carwil (talk) 15:23, 19 December 2017 (UTC)
I know that, what I'm saying is why have all that when it's mostly useful only to that language wikipedia. Other data on wikidata is useful across wikipedias - raw numbers, language links, etc Galobtter (pingó mió) 15:27, 19 December 2017 (UTC)
If the description is defined in the article text, then it can only be used in that article, on that language Wikipedia. If the description is on Wikidata, then you can access it from other articles (e.g., list articles), and places like Commons (descriptions for categories on the same topic as the articles), or on Wikivoyage etc. If it's in a data structure like on Wikidata, then it's a lot more easy to automatically reuse it than if it's embedded in free-form text. Thanks. Mike Peel (talk) 15:34, 19 December 2017 (UTC)
The description on Wikidata will remain available, if other projects or environments want to use it and think it suits their purpose (and can better access it than Enwiki magic words). This is rather out-of-scope for this discussion though, which won't change anything on Wikidata. Fram (talk) 15:47, 19 December 2017 (UTC)
  • 2 because Wikidata is shite and shouldn't ever be used regardless of how good it is in some articles, WMF have had ample oppertunity to patrol that site and do something about it however instead they've ignored requests time and time again so it's about time we did something ourselves, Anyway back on point using blanks is better - If someone adds a silly description they'll be reverted and no doubt one will be added. –Davey2010 Merry Xmas / Happy New Year 23:31, 27 December 2017 (UTC)
  • Combination of 2 and 1: Wikidata descriptions are off (except for maybe a brief run in) but will be possibly shown when ONLY changes to them can occur in the watchlist. Doc James (talk · contribs · email) 06:24, 30 December 2017 (UTC)
  • 2, because we need complete editorial control over this type of content. Alternatively, #5 as a compromise. Tony Tan · talk 04:21, 17 January 2018 (UTC)

Filling in blanks: option #5

Pinging everyone who !voted in the What to do with blanks discussion: Francis Schonken, Peter (Southwood), TheDJ, Fram, DannyH (WMF), Mike Peel, Sandstein , James, Dank, Carwil, TomT0m,ChristianKl, Jheald, Galobtter, Davey2010, Doc James.

If the debate is viewed as a simple option #1 vs option #2 outcome, the situation is rather unpleasant. By my count there is currently a majority for #2, however it's not exactly overwhelming. On the other hand #1 has substantial minority support, and the WMF is strongly averse to the possibility that descriptions get mass-blanked before we can repopulate with new descriptions.

There has been substantial discussion of an alternative that was not presented in the original RFC choices: a transition from #1 to #2. In the initial stage, any article that lacks a local description will continue to draw a description from Wikidata. We deploy the new description keyword and start filling in local descriptions which override Wikidata descriptions. Once we have built a sufficient base of local descriptions, we finalize the transition by switching-off Wikidata descriptions completely.

I believe multiple people above have expressed support above for this kind of compromise. People on opposing sides may consider this less-than-ideal for opposing reasons, however I hope everyone will consider this plan in an effort to build a collaborative compromise-consensus. Alsee (talk) 16:24, 6 January 2018 (UTC)

I don't really care how the transition is done (as long as it's done within a few months ish) - main goal is to eventually have everything on enwiki and rely little or not at all on wikidata. Galobtter (pingó mió) 16:58, 6 January 2018 (UTC)
I would grudgingly support a transition as long as WMF commits to a hard temporal deadline for switching off Wikidata descriptions. James (talk/contribs) 18:06, 6 January 2018 (UTC)
Yes, I would accept this compromise. It does not really matter in the long run, as long as WMF will switch off when Wikipedians decide that the local descriptions are adequate. It will be up to Wikipedians to get the descriptions populated. Anyone who wants to get Wikidata descriptions shut down sooner can make it happen by adding more short descriptions. · · · Peter (Southwood) (talk): 18:11, 6 January 2018 (UTC)
It still seems like a waste of time to me. Just use the Wikidata descriptions, and improve them there. Mike Peel (talk) 19:05, 6 January 2018 (UTC)
As we discussed below, the WMF plan is to switch from a Wikidata-fallback to full enwiki control when there are 2 million non-blank short descriptions on enwiki, which is roughly comparable to the number of existing descriptions on Wikidata. That will help to ensure that the readers and editors who use these descriptions won't notice a sudden degradation of the feature. -- DannyH (WMF) (talk) 19:16, 6 January 2018 (UTC)
I don't remember seeing any consensus regarding the 2 million quoted above.· · · Peter (Southwood) (talk): 15:22, 7 January 2018 (UTC)
As I think about this more, it would really just be easier if we could have that one item of Wikidata appear in our watchlists (for those who wish). I would than support simply continuing to use WD.
Would also be good to show the short definitions within Wikipedia text for those who wish and are logged in. Doc James (talk · contribs · email) 06:51, 7 January 2018 (UTC)
That should be the default then - that's the only way can get the same amount of people looking at it. It should also be more visible - appearing somewhere when editing on enwiki (maybe even "editable" there) but stored on wikidata. It's currently pretty obscure where it is stored; should be known to most people editing where they can change the description. Then it's somewhat reasonable. Objections would be enwiki control over them. Galobtter (pingó mió) 07:00, 7 January 2018 (UTC)
@Doc James: We're already half-way there with Preferences -> Watchlist -> "Show Wikidata edits in your watchlist" to see Wikidata edits in enwp watchlists, and this javascript to show the wikidata descriptions at the top of articles. It would make much more sense to me if we spent the developer time that would be spent on this pointless magic word on instead improving that functionality. Thanks. Mike Peel (talk) 07:58, 7 January 2018 (UTC)
Ah very nice user script. Have turned it on. Doc James (talk · contribs · email) 08:05, 7 January 2018 (UTC)
That script it quite nice; however it needs to be default (or atleast show somwhere when editing) so people can spot vandalism. Galobtter (pingó mió) 08:09, 7 January 2018 (UTC)
Keeping the description on Wikidata keeps it under the control and policies of a different project. It is unfair to Wikidata if English Wikipedia imposes their policies on what can be content in Wikidata which will happen if the descriptions are stored there. Moving text that is specific to a Wikipedia article to Wikipedia avoids that can of worms. · · · Peter (Southwood) (talk): 15:22, 7 January 2018 (UTC)
Yeah i did point out that addition objection above; will definitely need enwp policies on it though unsure how much clash will be there. Probably will have standardizations for it etc Galobtter (pingó mió) 15:24, 7 January 2018 (UTC)
Only having it in our watchlists isn't enough. For starters, we need to monitor other Wikidata changes as well, for as long as using Wikidata dierctly in our articles is allowed (infoboxes, templates like "official website", authority control), so we wouldn't only have the descriptions in our watchlist, but these others as well (and at the moment and for a long time already al irrelevant changes as well, while some relevant ones are missing). It would need to be in the page history as well, it would need to be immediate (now there often is a delay, somtimes of hours, before it appears in our watchlists). And then there are the protection and block issues, as Wikidata allows circumventing our blocks and protections. Finally, these descriptions are also meant for internal Wikidata use, but these too often clash with our purpose (e.g. the "Wikimedia list" descriptions, or descriptions including advice on which Q-number to use). Enwiki and Wikidata are two different worlds, with different policies, practices and purposes, and forced mixing of them is a bad idea (now and in the long run). Fram (talk) 10:11, 8 January 2018 (UTC)
  • Oppose any "compromise" forced by WMF bullying and selective reading. Enwiki should decide when to turn off the automatic use of Wikidata descriptions, not the WMF. Fram (talk) 10:15, 8 January 2018 (UTC)
  • I stand by my original choice. —TheDJ (talkcontribs) 11:58, 8 January 2018 (UTC)
  • I still agree with Mike Peel on this: the best use of WP editors' time would be to make good descriptions that then also appear on Wikidata. And the best use of WMF developer's time is not making special workarounds for en.wp but rather making tools that allow all Wikipedias to monitor and protect the short description fields stored on Wikidata. But given that we're likely to have such as system let me suggest: (1) Either WMF should find a way to immediately freeze edits on short descriptions for protected pages and the most-viewed pages (which might be technically difficult) OR the en.wp community should do a drive to write such descriptions, inserting them BOTH on en.wp using the magic word and on Wikidata. (2) The magic word system should include an "intentional blank" that is different from a not-yet-written blank space. The WMF should count these intentional blanks as part of its 2 million goal. Community members should only use this system when the description genuinely adds nothing to page because its title is already clear (3) Lists and disambiguation pages should be handled in context specific way (e.g., it might make sense for "Wikipedia disambiguation page" to appear on VisualEditor but not on a mobile or desktop view of the page).--Carwil (talk) 19:15, 9 January 2018 (UTC)
  • For 12 months the description for Bo Scarbrough was "Clemson gave him that 'l'" - it has been viewed 140+thousand times (not obscure) since- until I saw it using that script that shows the wikidata description. See here. 100%, definitely need it to be visible - very visible - on enwiki so that vandalism can be detected, if it isn't stored in a magic word. Needs to be visible in the history of the article and there are also problems with protections, blocks etc etc as Fram points out. Currently the security seems to be by obscurity, which is pretty awful (and also means that descriptions are far less likely to be added). I think for reasons like enwiki control (and so having standardization, guidelines by enwiki and making it more suitable for enwiki) and detecting vandalism it should be in a magic word. Galobtter (pingó mió) 07:29, 10 January 2018 (UTC)

Other discussion

I don't understand any of this. Could someone please explain this to me? Hydra Tacoz (talk) 21:49, 18 December 2017 (UTC)
@Hydra Tacoz: Some uses of Wikiepdia have short descriptions of articles (e.g. in the Wikipedia app or for search engines). Where and how we get or store this info is what is being discussed. A logical place to keep it is Wikidata but there are some problems with that. ―Justin (koavf)TCM 21:55, 18 December 2017 (UTC)
@Koavf|Justin Thank you! So, how is the Wikidata a safe place? What exactly is the Wikidata? Hydra Tacoz (talk) 22:04, 18 December 2017 (UTC)
@Hydra Tacoz: Wikidata is a sister project of Wikipedia: it is a wiki but it is not an encyclopedia like this is but a place to store structured data. If you aren't familiar with databases, it may seem confusing at first but imagine a musician (e.g. John Coltrane) and at Wikipedia, we would write a biography of him, Wikiqoute would have quotes by and about him, Commons would have photos or recordings of or about him, etc. Wikidata would store individual facts such as his birth date, citizenship status, record labels signed to, etc. One function of Wikidata internally for projects like Wikipedia is to store short descriptions of the subject--in this case, something like "American jazz saxophonist and composer". ―Justin (koavf)TCM 22:07, 18 December 2017 (UTC)
To clarify: The function of the short description on Wikidata is an internal Wikidata function. It is not, (or was not originally), intended for use as a description of a Wikipedia article for use when displaying a Wikipedia article name by a Wikimedia project other than Wikidata. WMF currently use it for this purpose because they consider it the best available alternative (pretty much the only existing non-zero option). The intention is reasonable, as it helps users to identify which of a selected group of articles is most likely to be useful, but has the problem that it is outside the direct control of the Wikipedia editors of the articles it is used to describe, and there are problems with persistent vandalism, inappropriate or sub-optimal descriptions, which can only be edited on Wikidata, and that some Wikipedians are not keen on being coerced into editing and maintaining Wikidata to prevent vandalism appearing in connection with Wikipedia articles. There is also a technical problem in that the short description is currently not visible from desktop view,and does not show up usefully on watchlists, so vandalism can go undetected by Wikipedians. The proposed solution is to provide a short description on Wikipedia for each article which can be drawn on for any purpose where it may be useful, and the WMF devs say that must be done by a new "magic word" which as far as I can make out is like a more efficient template function. Whether the magic word is initially populated with blanks or Wikidata short descriptions is relatively unimportant over the long term, as once it exists, Wikipedians can watch and change the short descriptions as and when editors feel that it is needed, from within the Wikipedia editing environment of the associated article - The short description will be part of the article itself, and changes will show up on watchlists. · · · Peter (Southwood) (talk): 08:22, 19 December 2017 (UTC)
Hydra Tacoz if you click this search link and type Bar into the search box (do not press enter) you will see a list of articles. The first entry will probably be Bar: establishment serving alcoholic beverages for consumption on the premises. That text is the short-description being discussed here. To help small-screen mobile users, that description appears at the top of an article when it's read in the Wikipedia App. It used to appear appear on the mobile-browser view as well. It appears in the link-tool in Visual editor, and it might appear elsewhere. That text is not written anywhere at Wikipedia. It comes from the Wikidata entry for bar. You can edit it there. As others noted, Wikidata is a sister project of the Wikimedia family. Wikidata has been creating those descriptions for their own use, and the Foundation decided it would be convenient to re-use those descriptions here. The EnWiki community was rather surprised when we realized it was added and how it works. There are concerns that most EnWiki editors never see those descriptions, and even if they do see them, they often don't know who to fix them. There is concern/debate about how well the Wikidata community can catch and fix vandalism. There are concerns that the descriptions are not subject to EnWiki policies, page-protection, or user-blocks. Edits at wikidata (including vandalism, biased edit-warring, or otherwise) will bypass any page-protection we put on the article, and we can potentially be blocked from editing a description if a Wikidata admin disagrees with EnWiki policies such as BLP. Descriptions intended for Wikidata-purposes also may not always be best suited for our purposes. The discussion here is for adding something like {{description|a retail business establishment that serves alcoholic beverages}} at the top of our articles, and using that instead of Wikidata's descriptions. Then the description can be seen, edited, and controlled just like any other article wikitext. The downside is that EnWiki and Wikidata would have parallel systems managing similar descriptions for similar purposes. Alsee (talk) 11:25, 6 January 2018 (UTC)

WMF two-stage proposal for Wikipedia-hosted descriptions

We've been talking for a long time about how to give Wikipedia contributors editorial control over the short descriptions. I've got a new approach to a solution here, and I'd like to know what you think.

First up, to establish where this approach is coming from:

  • English Wikipedia editors need to be able to see, edit and effectively moderate the short descriptions on desktop and mobile web, without becoming active Wikidata editors. That requires meaningful integration in Wikipedia watchlists and page history. Those are features that the Wikidata team is working on, but they don't currently exist, and they don't have a timeline for it.
  • The short descriptions are very useful for readers of the mobile apps and for editors using VisualEditor, and blanking a significant number of descriptions for a meaningful period of time would harm the experience for those readers and editors.
  • English Wikipedia editors should make the content decisions about how to actually populate the descriptions, including being able to specify pages where a description isn't helpful.

That last point is the one we've been wrestling with for a while. I was asking for examples of article pages that shouldn't have a description, and several people brought up examples where the article had a disambiguation phrase, and the short description was only repeating information from that disambig phrase. Here's some examples:

I said above that I didn't think the redundancy was harmful, but some folks pointed out that I was moving the goalposts -- asking for examples, and then saying they didn't matter. I was trying to make content decisions about the format, and I'm not one of the people who are doing the actual work of writing and moderating them. Fair point.

So I wanted to estimate how many useful descriptions there currently are -- taking out "Wikimedia list page" and "Wikimedia disambiguation page", and also taking out pages where the description is just repeating a disambiguation phrase.

Last week, Mike Peel generated a list of 1,000 random articles and descriptions, which helped us to survey the quality of descriptions on a decent cross-section of pages. I wanted a bigger sample, so we generated a list of 10,000 articles and descriptions.

Here's the breakdown from that larger sample of 10,000 random articles. This is my current definition of "not useful" descriptions:

  • 39.82% have no short description on Wikidata
  • 7.76% have descriptions that include "Wikipedia" or "Wikimedia"
  • 1.16% have a disambiguation phrase in the article title, which is entirely duplicated in the description (116/10,000, marked on the page linked above)

Putting those together, that makes 48.75% blank/not useful descriptions, and 51.25% useful descriptions.

Extrapolating that out to 5.5 million articles, it suggests that about 2.82 million Wikipedia articles have useful descriptions. (I'm open to continuing to iterate on the definition of useful vs not useful, if people have thoughts about that.)

Now, from the WMF side, the thing that we want to avoid is switching suddenly from 2.8 million useful descriptions to a much lower number, which is what would happen if we built a magic word that's blank by default. That would hurt the experience of the readers and editors who rely on the descriptions.

So, the solution that I'm proposing is: WMF builds a magic word that Wikipedia editors can populate with descriptions.

  • Stage 1: Initially, the display of the descriptions pulls from the Wikipedia-hosted magic words -- but if there isn't one on Wikipedia, or the Wikipedia one is some version of blank, then it falls back to showing the Wikidata-hosted description.
  • Stage 2: When there are non-blank Wikipedia-hosted magic words on a number of articles that's roughly comparable to 2.8 million, then WMF switches to only pulling from the Wikipedia-hosted magic words, and we don't fall back to Wikidata-hosted descriptions. At that point, descriptions that Wikipedia editors leave blank will actually be blank on the site.

The decisions about how to generate ~2.8 million descriptions will be made by Wikipedia editors, and the timeline is up to you. I'll be interested to see how that process develops, but it's not our process. Our role is to switch to full Wikipedia-hosted descriptions when there are enough descriptions that the folks who use them won't notice a meaningful degredation. So that's the idea.

One final thing that I want to say is that there are a lot of people in the movement, including the WMF, who believe that more integration and interdependence between Wikidata and Wikipedia is going to be key to the movement's growth and success in the future. We're going to keep working on helping Wikidata to build features that make that integration realistic and practical.

Right now, Wikidata doesn't have the working features that would make short descriptions easy to see and moderate from Wikipedia. In the future, as the Wikidata team builds those kinds of features, we'll want to keep talking to folks about how to encourage productive interdependence between the two projects. I'm hoping that a positive resolution on this short descriptions question helps to keep the door open for those future conversations. What do you think? -- DannyH (WMF) (talk) 00:32, 22 December 2017 (UTC)

I'm having trouble following this. Admittedly I'm not the sharpest crayon in the box, so could you help by giving the Cliff's Notes version of this proposal? Shock Brigade Harvester Boris (talk) 01:54, 22 December 2017 (UTC)
The WMF claims, based on a sample of 10,000 articles and some dubious mathematics (116/10,000 is not 0.01% obviously, but 1.16%) that about 2.8 million enwiki articles have useful Wikidata descriptions; based on this, they will continue to use the Wikidata description when there is no enwiki magic word description, until enwiki has populated 2.8 million magic words. At that time, they will switch off the "use the Wikidata description when there is no enwiki description" and switich to "show a blank description when there is no enwiki magic word description". 08:09, 22 December 2017 (UTC)
Your count is a bit optimistic. Apart from the maths error explained above, I see in your sample "12. en:German International School New York - school". I also see that in yor count of the disambiguations, you don't count ones that aren't identical, even if it is less specific and useful than the disambiguation: "3. en:William McAdoo (New Jersey politician) - American politician", or add something which is hardly useful: "15. en:Matt Jones (golfer) - professional golfer". That's 3 out of the first 15 you don't count as useless descriptions, or some 20% more. Which would drop your 2.88 million to 1.8 million or so... Fram (talk) 08:09, 22 December 2017 (UTC)
And Fram's math is also wrong here. Just to be precise, DannyH (WMF) found 116 uninformative (because duplicating) parenthetical disambiguations. There are 1197 of those, 116 of which are already counted as faulty, so adding 20% of the remainder gets us to 116+216=332. So the faulty descriptions for parenthetical citations are only 3.32% of the total. We're still at about half valid descriptions. (From my perspective, "professional golfer" is more informative than "golfer" in the same way that "American politician" is less informative that "New Jersey politician.")--Carwil (talk) 12:46, 23 December 2017 (UTC)
I found 20% of the first 15 overall, not 20% of the remainder. Of course, nothing guarantees that this percentage will remain the same across all 10K, but it is not the calculation you are making. My 20% was not only about disambiguations, e.g. my first example (number 12) is not a disambiguation. Fram (talk) 15:03, 23 December 2017 (UTC)
I agree with Fram that the above-mentioned statistical analysis does not bear close inspection and claims a significantly inflated number of useful descriptions. Instead of pointlessly arguing the red herring of how many are good and how many are bad, I think we would actually be better off with populating the magic word with Wikidata descriptions at the start, and immediately switching to only showing descriptions from Wikipedia, as then we could get rid of the garbage more easily, and would be free of interference and externally imposed vandalism at the soonest possible date. This path should also reduce the coding to the minimum achievable required complexity, as all it would have to do is produce a description string from Wikipedia, without any conditionals. Blank description => Blank display, Non-blank description => Non-blank display. This should be the lowest possible overhead with the lowest probability of bugs, and should allow us to get started with fixing earlier. If the Wikidata description is good enough that no-one bothers to improve it, then it can stay. Empty descriptions will be empty at Wikidata too, so no disadvantage. Vandalism copied over from Wikidata will be absent from mobile and VE display after being deleted once. Crap copied over from Wikidata can be seen on Wikipedia and eliminated, either by providing a better short description, or simply deleting it. Way better than continuing to pull dubious material from Wikidata until a somewhat arbitrary number of non-blank descriptions have been produced on Wikipedia. Once the magic word syntax has been defined, a single bot run authorised by Wikipedians can populate the articles, even before the display code has been finalised. · · · Peter (Southwood) (talk): 15:01, 22 December 2017 (UTC)
DannyH (WMF), I don't think your proposal is an improvement on what I have described here, it prolongs the lack of internal control over Wikipedia content unneccessarily and to no advantage. · · · Peter (Southwood) (talk): 15:19, 22 December 2017 (UTC)
Pbsouthwood and Fram: We can get into the weeds on duplicates, but ultimately I don't think it's going to provide a lot of clarity for the amount of time and work it would take. This is the fairest option that we can provide, and I can't keep coming up with new solutions just because you say it's not an improvement. We need to bring this to a conclusion. -- DannyH (WMF) (talk) 17:56, 22 December 2017 (UTC)
DannyH (WMF), Firstly I have no idea what "get into the weeds on duplicates" is supposed to mean, so cannot comment on it further. Secondly, I don't think it is a fairer option than the one I have described, depending on how you define "fair" in this case. Thirdly, I don't see that your options are actually "solutions". Partial solutions, perhaps. Compromises, yes, but so are most of the other options discussed. I think you are missing the point again. Please read my suggestion above, and instead of a blanket dismissal, explain where it has technical problems and what they are. · · · Peter (Southwood) (talk): 03:40, 23 December 2017 (UTC)
DannyH, where did I say "it's not an improvement"? I have only commented on your poor calculations, that's all. If you can't accept any comments, then just shut down this RfC and declare what the WMF will do. Fram (talk) 11:11, 23 December 2017 (UTC)
Fram and Pbsouthwood: We've been talking about this for months, and I have agreed with many points that both of you have made. This compromise that I'm proposing will result in fully Wikipedia-hosted descriptions, with control over individual pages where WP editors think the description should be blank. This is the thing that you said that you wanted. The only compromise that I'm asking for on your side is for Wikipedia editors to actually write the short descriptions that you said that Wikipedia editors want to write. Do you think that this is an acceptable compromise? -- DannyH (WMF) (talk) 22:44, 23 December 2017 (UTC)
DannyH (WMF), The compromise you are suggesting requires Wikipedians to produce 2.8 million descriptions before you will agree to turn off Wikidata as the empty magic word default, meaning that the problems of vandalism remain for that period, which may be a long time, as Wikipedia is edited by volunteers who will edit as and where they choose. Fram disputes the validity of this number, and I consider a simpler option preferable which could result in a much earlier shutoff of Wikidata, without any loss of useful functionality for WMF. You have not made any reply to my query regarding technical objections, so should I assume there are none? Have you read and understood my suggestion above which I have now set in italics so you can find it more easily? These are not rhetorical questions, I ask them in order to get answers which may be relevant to getting closer tom a solution. I cannot force you to answer them, but you might find that discussions go more smoothly and productively when you answer questions instead of changing the subject.
In answer to your question, No, until you have answered our questions I cannot accept your proposal as an acceptable compromise because I am lacking what I consider to be important data for making that decision. However, I speak only for myself. Others may agree or disagree with my opinions, and I will go with the consensus. What I am trying to do is get us there by getting the options as clear as possible. I also think that most, if not all of the regular Wikipedians here are doing the same. · · · Peter (Southwood) (talk): 16:57, 24 December 2017 (UTC)
Pbsouthwood, what you're describing above is absolutely within the bounds of the proposal that I made. We can turn off the Wikidata fallback when there's a comparable number of good descriptions hosted on Wikipedia. We're not going to decide how to populate the magic words; those are content decisions that Wikipedia editors can make. If people want to copy all of the existing Wikidata descriptions, then that would hit the threshold of descriptions, and we could turn off the Wikidata fallback at that point. Does that answer your question? -- DannyH (WMF) (talk) 18:30, 26 December 2017 (UTC)
DannyH (WMF), That answers my question partly. If WMF is willing to commit to switching off the Wikidata fallback when Wikipedia decides that all the acceptable descriptions from Wikidata have been transferred, or have provided better ones, then I would accept the proposal, but not if WMF plans to hold out for an arbitrary and poorly defined number based on a small sample and a dubious analysis. · · · Peter (Southwood) (talk): 19:01, 26 December 2017 (UTC)
  • Support for either the 'two phase' solution (filling descriptions first and switching off wikidata later), or copying the wikidata descriptions and shutting off wikidata more quickly.
    After reviewing the 10k random Wikidata descriptions I see DannyH's calculation of 2.8 million 'useful' descriptions at wikidata is somewhat of an overestimate. It includes few percent that have zero value, and another few percent with negligible value. However I expect we all have reasonable flexibility on the vague threshold for local descriptions to credibly substitute for wikidata descriptions. Alsee (talk) 23:02, 27 December 2017 (UTC)
Pbsouthwood and Alsee: Okay, good. Yeah, we can work together on what the threshold for switching would be. I was hoping at first that we could pull the description for every page (5.5m), but the query would take days to run, and I wanted to go through a sample by hand anyway. That's why I used the random 10,000. If somebody wants to get a better estimate somehow, that's cool, or we just say a round number like 2 million. Or maybe someone has a better idea for how to judge that threshold. What do you think? -- DannyH (WMF) (talk) 21:21, 29 December 2017 (UTC)
DannyH (WMF), I think that if we can agree on a reasonably objective way to establish that the usefulness of Wikidata as a source for short descriptions has been effectively exhausted, we don't have to agree on any specific number. At some stage Wikipedians will suggest that we have taken as many of the short descriptions as is reasonably practicable and are actually useful, and request a shutdown of the Wikidata fallback. We would establish this point by internal discussion and consensus, as is traditional. At this point I suggest that WMF be allowed a two week period to check, and show statistically convincing evidence that it is worth the effort of finding and extracting more, and a way to find them, or do the shutdown without further delay. There is nothing to stop anyone who thinks that scavenging the last few useful descriptions is worth further effort from doing so at any time after the shutdown. Nobody gains by haggling over a specific number in the absence of reliable evidence. A few weeks or months of actually creating and transferring short descriptions is likely to inspire a whole range of more useful ideas on how to estimate the cutoff point. · · · Peter (Southwood) (talk): 05:08, 30 December 2017 (UTC)
Pbsouthwood, I think we need some kind of goal to shoot for. If we just say that the community will decide when they feel like it's done, then we're going to find ourselves in exactly the same place, however many months away it is. I'd like to have a clear line that we can agree on, so we can go through the rest of the process in amicable peace. -- DannyH (WMF) (talk) 19:08, 1 January 2018 (UTC)
DannyH (WMF). There are two problems with this latest proposal:
  1. What makes you think it will be easier to come up with a reasonable, generally acceptable fixed number now than later?
  2. Who is going to produce a credible number without generally acceptable evidence of statistical validity, or an actual count? Your proposals so far have appeared ingenuous. I doubt that Wikipedians would accept your suggestions without fairly convincing evidence, and it is you who is asking for a fixed number, therefore your burden to find one that we can accept. If you are trying to delay things as much as possible, this looks like a very effective method of stonewalling any progress. · · · Peter (Southwood) (talk): 05:16, 2 January 2018 (UTC)
Please confirm that development of the magic word is not being delayed until a final decision on numbers is reached. · · · Peter (Southwood) (talk): 05:16, 2 January 2018 (UTC)
Pbsouthwood, we are both operating in good faith here. I posted a list of 10k random Wikidata descriptions, with an explanation of the methodology I used to arrive at an estimate of 2.8 million useful descriptions. I've marked all of the descriptions in that list of 10,000 which are only repeating information from the disambiguation phrase, and not counting them. If somebody else wants to go through it and mark ones that they think I missed, that's fine, and I'll adjust the estimate.
What we're measuring is partially a judgment call -- what counts as a repeat of the disambiguation phrase? -- so it's not a task that a script can do accurately. It needs a person who can go through descriptions and make that judgment call. I've done that for 10,000 descriptions, and it took me a couple of hours. I can't spend more time looking at a bigger sample.
Development of the magic word is not being delayed until a final decision on numbers is reached. We will build the magic word that overrides the Wikidata description. Making the switch to shut off Wikidata descriptions and only pull from the Wikipedia descriptions will depend on the number that we're talking about. I am suggesting 2 million descriptions, which is significantly lower than my estimate of existing descriptions. -- DannyH (WMF) (talk) 18:58, 2 January 2018 (UTC)
DannyH (WMF), in my personal life I'm not a fan of carving long term specifics in stone, and the wiki-community also generally deals with things on the fly. If the descriptions get filled in quickly then any target number isn't going to matter much. If things proceed too slowly then some sort of examination of what's happening would probably be warranted anyway. However I can understand some people may be more comfortable if there is a clear target in place. If it's important, I guess I could sign onto a 2-million-or-earlier target. If necessary we could always meet that target by copying wikidata descriptions. Alsee (talk) 18:35, 5 January 2018 (UTC)
Alsee, I think it's helpful to have an estimate to shoot for, so that the community can make the kind of decision that you're referring to -- do we need to copy Wikidata descriptions, or should we try to write them all ourselves? "We need to write 2 million descriptions" is very different from "we need to write a lot of descriptions." -- DannyH (WMF) (talk) 22:40, 5 January 2018 (UTC)
Alsee, I agree with your most recent analysis and comment.· · · Peter (Southwood) (talk): 05:08, 30 December 2017 (UTC)

This is the key bit:

English Wikipedia editors need to be able to see, edit and effectively moderate the short descriptions on desktop and mobile web, without becoming active Wikidata editors. That requires meaningful integration in Wikipedia watchlists and page history. Those are features that the Wikidata team is working on, but they don't currently exist, and they don't have a timeline for it.

Integration is not possible until this capability is created. The current situation exposes us to prolonged vandalism and thus harms our reputation. Doc James (talk · contribs · email) 06:12, 30 December 2017 (UTC)

I agree with Doc James. We need local editorial control over what is displayed on this Wikipedia. Tony Tan · talk 04:24, 17 January 2018 (UTC)

A proposal to permanently semi-protect the Template space

Following a series of vandal edits to the template space (here and here, and the ANI about it), MusikAnimal template-protected (without opposition) templates with 5k+ transclusions and semi-protect all those with 1000+ transclusions.

Earlier today a template with 956 transclusions was vandalised.

Due to the fact that the template space isn't widely patrolled, and the potential for great harm to be done in a very short amount of time, I am proposing that all templates be semi-protected. This would likely involve a software change, but I think it's the only way to ensure that major vandalism on a relatively-unused template doesn't sit around for ages, to be seen by the unsuspecting public who might not know how to let us know to fix it.

I briefly discussed this off-wiki with Cyberpower678, who said they would support if there was a minimum transclusion count (10+ was discussed) so I am amenable to that option, but from an administrative standpoint I think it's easier to just batch-protect everything (unless we can get a protect-bot that can autoprotect templates with 10+ transclusions). Primefac (talk) 18:18, 21 December 2017 (UTC)

NOTE: This would not require a "software" change (to apply to an entire namespace), but would require a configuration change in InitialiseSettings.php. See example of auto confirmed being used for the Module: namespace on eswiki (scroll to the bottom of the page). — xaosflux Talk 19:30, 21 December 2017 (UTC)
  • Supportentire space a small transclusion number but not the entire space, per zzuuzz's argument below. — Insertcleverphrasehere (or here) 18:25, 21 December 2017 (UTC)
  • Yeah. OK make it so. net positive -- Dlohcierekim (talk) 18:26, 21 December 2017 (UTC)
  • Support Having a protect-bot is a little ehh, because it means that anyone can semi-protect any template with less than 10 transclusions by transcluding it..not too much potential for harm there, but still. Galobtter (pingó mió) 18:39, 21 December 2017 (UTC)
    Other than "winning" an edit war, I don't see the how it would be gaming the system to add a few more transclusions to result in semi-prot. Primefac (talk) 18:50, 21 December 2017 (UTC)
I mean, that is a vague problem. But rare. Galobtter (pingó mió) 03:58, 22 December 2017 (UTC)
  • Support I did indeed say I will support this and I can easily create a bot to enforce this. When I did say 10+ transclusions, I did mean in articlespace. So not too much potential for gaming as mentioned above.—CYBERPOWER (Merry Christmas) 18:42, 21 December 2017 (UTC)
  • Support Net positive. I love IPs and new editors, but they can either log in and wait 4 days or just wait 4 days to edit the Templates. L3X1 (distænt write) 18:53, 21 December 2017 (UTC)
I don't find zzuzz's argument convincing. "Autoconfirmed socks are easy to come by" If you bother getting your mouse over to the create an account button. Driveby vandals aren't usually socks. And I didn't think this was being proposed as a cure for socking, just vandalism which can be pretty hard to detect. I'm fine for the base limit to be raised to a thousand transclusions or something like that, but SEMI is a very effective anti-vandal lockdown. Also "encyclopedia anyone can edit" doesn't apply here. The template space is maintenance and framework of the encyclopedia, not the content. L3X1 (distænt write) 20:19, 21 December 2017 (UTC)
Oh the number of autoconfirmed socks I've blocked - these are dedicated regular vandals who do this, not drive-bys. But that's a minor point - I disagree with you strongly about the use of templates. Some are indeed maintenance and framework templates (particularly those targeted), but the vast majority of templates (particularly those edited by unregistered users) contain lists, and names, and numbers, and very much form part of the content. -- zzuuzz (talk) 20:36, 21 December 2017 (UTC)
  • Comment Primefac, wouldn't it be easier just to roll out an ACTRIAL like technical restriction rather than semi-protect every new template? TonyBallioni (talk) 19:08, 21 December 2017 (UTC)
    TonyBallioni, I'm not overly concerned about the creation of templates, I'm concerned about vandalism to templates. The vandalism to Template:Redirect-multi was done almost two years after the page was created. Primefac (talk) 19:24, 21 December 2017 (UTC)
    Right, but what I'm saying is that there may be a way simply to prohibit any editing to templates to non-AC users on en.wiki without having to manually protect them, which would be ideal. TonyBallioni (talk) 19:26, 21 December 2017 (UTC)
  • Oppose basically because of this. This proposal is fine in theory for long standing prominent, widely-used and heavily transcluded templates - typically maintenance templates. However there's a notable maintenance of less common templates by new and unregistered users, including those with dozens of transclusions. I find it's especially notable in sports templates, but several other topics - politics, media, software, all sorts actually. Many of these templates are almost exclusively maintained by unregistered users. Several hundred transclusions would be my floor. I would prefer instead that the current system of caching and purging is improved to reduce any vandalism's longevity. Also, autoconfirmed socks are incredibly easy to come by. -- zzuuzz (talk) 19:12, 21 December 2017 (UTC)
I do see that problem. Don't see why it has to be several hundred transclusions though. Most of those have less than 10 transclusions. Galobtter (pingó mió) 03:58, 22 December 2017 (UTC)
But plenty have more than ten transclusions. It's a figure based on experience. Take some random obscure examples recently edited by unregistered users: Template:Philip K. Dick - 184 transclusions; Template:Syracuse TV - 37 transclusions; Template:Miss International - 64 transclusions; Template:Cryptocurrencies - 109 transclusions; Template:Pixar - 110 transclusions; Template:Flash 99 transclusions. There's a lot like this. -- zzuuzz (talk) 07:22, 22 December 2017 (UTC)
  • Oppose Wikipedia is the encyclopedia that anyone can edit but there are only 159 editors with template editor right. I don't have this right myself and would resent being considered a suspicious vandal by default. We have far too much creeping lockdown of Wikipedia which is tending to kill the project. If such paranoia had been allowed to prevail in the early days, Wikipedia would never have been successful. Andrew D. (talk) 19:51, 21 December 2017 (UTC)
    @Andrew Davidson: This proposal is to semi-protect the templates, not template protect them. Just thought I would clarify that.—CYBERPOWER (Merry Christmas) 20:09, 21 December 2017 (UTC)
  • Oppose zzuuzz's argument is convincing. Jo-Jo Eumerus (talk, contributions) 20:01, 21 December 2017 (UTC)
  • Sort of oppose, sort of support. 10 transclusions is way too low a limit and the devil is in the details. Maybe 100+, or 1000+ and I'd be OK with this. But I feel a better approach might be to simply be identifying templates that do not need to be edited regularly, and semi-protect those (e.g. semi-protect maintenance templates, infoboxes, etc...). But I do not see a need to semi-protect templates like navboxes, for instance. Headbomb {t · c · p · b} 21:13, 21 December 2017 (UTC)
  • comment would it be better, perhaps, to use PC1? seems to me, aht it's a useful way to allow ipusers and new registered to make productive edits, without them going live immediately. (this may, however, require technical changes. -- Aunva6talk - contribs 22:32, 21 December 2017 (UTC)
  • Support semi-protting, but ONLY for templates with 250+ transclusions. The vandals are going to be drawn to those templates that are widely used in order to cause chaos, so the simplest thing to do is to semi-protect only those templates that are used in many articles at once. As per usual I oppose CRASHlock on ideological grounds, not to mention that only an idiot would want that many pages CRASHlocked all at once.Jeremy v^_^v Bori! 22:57, 21 December 2017 (UTC)
  • There must be some vague way to figure out if something is a maintenance or content template. Maybe make templates that take parameters semi-protected? Some sort of solution of 10+ transclusions and that. But it'd also have to be designed to prevent abuse. Galobtter (pingó mió) 03:58, 22 December 2017 (UTC)
  • Oppose. Aside from zzuuzz's points, it would vastly increase the workload on WP:Template editors (and admins who respond to requests that TE's can also do). Yes, non-TEs could respond to template-editing requests on templates that are only semi-protected, but most of them don't know that, and it would likely not be obvious what the protection level was when it came to any particular request. I think a more reasonable proposal would be to semi-protect templates with X number of transclusions. 100? 250? 1000? I'm rather agnostic on the matter. A good thing to do would be to find the sports-specific template that is used on the largest number of pages that is not an infobox (we do not want anons adding or deleting parameters from an infobox, because those templates are a massive WP:DRAMA factory as it is) and not a navobox (because we have rules about them, and anons mostly will not have read them). There are likely football (soccer) templates relating to team roster, uniforms ("kit"), league standings, etc., used on hundreds of articles at least, possible 1000+, to which anons with some experience could meaningfully contribute. Might give us an idea what number we should be thinking about. Anyway, I would actually like to see automatic semi-protection on somewhat-high-use templates as an anti-vandalism method, and also as a means for reducing the number of templates that have template-editor protection for which semi-protection would actually be sufficient. That will not only waste less TE time, it will get us more template development by anons and non-anons.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  05:07, 22 December 2017 (UTC)
  • Oppose. Excellent arguments made by zzuuzz. I read through the recent changes link, and surprisingly few of the diffs listed were vandalism. We might want to protect highly-used maintenance templates. Perhaps 5000 transclusions would be a good floor for this (from what I've seen at the most-transcluded templates report). Enterprisey (talk!) 05:16, 22 December 2017 (UTC)
  • Support Vandalism on template is affecting several pages at the same time. Any IP user can propose any meaningful change via edit request which normally doesn't last 24 hours without getting response. –Ammarpad (talk) 09:15, 22 December 2017 (UTC)
    Based on recent data this would affect around 1,500 edits every week. I think most wouldn't even bother making requests, but if even a proportion did I would expect that to increase. -- zzuuzz (talk) 10:53, 22 December 2017 (UTC)
  • I would support a proposal for using a bot to give all templates with more than 10 transclusions semi-protection, or pending changes protection if possible; and to remove semi-protection if templates, having been protected by the bot, have their number of transclusions reduced below 10. Automatic semi-protection of all templates is definitely overkill (having a bot find the number of transclusions is definitely possible), and 5000 as a minimum for semi is definitely too high (I'd say even 500 would work for template protection). Note that none of these would increase the workload of template editors, since they are only needed for editing template-protected templates and modules. The bot could also avoid protecting templates consisting solely of navboxes or sidebars, since they are supposed to be transcluded on many pages by design and are relatively easy to edit. Jc86035 (talk) 11:38, 22 December 2017 (UTC)
  • OP Comment Okay, a few things I've seen that keep popping up:
    First, all templates with 1000+ transclusions are already semi'd (and 5k+ TE'd). This proposal is talking about those with 0-999 transclusions being potentially vandalised.
    Second, the proposal is for semi protection, which would not increase Template Editor's jobs in any way, shape or form. They would of course be welcome to patrol the edit requests for Template-space issues, but not required.
    Third (going off the previous note) the TEs aren't exactly hammered under the weight of responsibility. We get maybe three TPER requests a week.
Just felt I should clarify those things going forward. I will admit that IPs aren't all bad with their changes, especially to Sports templates, but those type of frequently-updated templates are (for the most part) single-season templates that are rarely used on more than 10 pages (which would mean the 10+ option of semiprot wouldn't affect them). If Cyberpower says he can make a bot to do it, then it wouldn't involve any software changes. Primefac (talk) 13:22, 22 December 2017 (UTC)
And for what it's worth, I don't particularly care if we decide on 10+ or 250+ or 500+, but I think there should be some threshold for semi-protecting templates. Primefac (talk) 13:24, 22 December 2017 (UTC)
So... if we (assuming we can) run the numbers, looking at frequency of edits and number of transclusions, what does that graph look like? Is there some evidence based threshold beneath which most IP editors can happily plod along, while the rest of us can avoid having a cock and balls transcluded on a few hundred pages every few weeks? GMGtalk 13:44, 22 December 2017 (UTC)
  • Oppose, current protection level works generally well, and vandalism level on templates isn't very high. Openness ("anyone can edit") is more important than restricting vandalism to sleeper accounts. —Kusma (t·c) 18:17, 22 December 2017 (UTC)
  • Oppose blanket protection. zzuuzz's argument is compelling and this is the free encyclopedia that anybody can edit. At a certain number of transclusions, the tradeoff points in the direction of protecting. So I would support an x+ transclusions rule. Malinaccier (talk) 18:28, 22 December 2017 (UTC)
  • Oppose, there are template such as sports competitions, sport team lineups, list of stations etc, where IP contributions are mainly constructive and helpful. I could support the x+ protection, though 10 inclusions looks like a low bar for me (a football team lineup is at least 23 + the team + the coach), I would more think about fifty or so.--Ymblanter (talk) 00:00, 25 December 2017 (UTC)
  • Oppose This is the encyclopedia anyone could edit. Functionally, semi-protecting everything would be great, but its not what we do and it's fundamentally against our ideas. Don't do this kneejerk action. Be smart, and judge it on a case-by-case basis. !dave 08:17, 28 December 2017 (UTC)
  • Oppose. There are many templates that would be perfectly legitimate for newer editors to edit, especially navboxes and the like. I would support semi-protecting everything with 100+ transclusions. We probably should create an edit filter logging newer editor's edits to template namespace, as an aside. ~ Rob13Talk 08:24, 28 December 2017 (UTC)
    @BU Rob13: If you use the new filters form on RC/WL/RCL (see beta preferences), this is all non-EC edits to template space. --Izno (talk) 13:39, 28 December 2017 (UTC)
  • Support on templates used more than 100/200 times but Oppose generally. Doc James (talk · contribs · email) 05:59, 30 December 2017 (UTC)
  • Oppose entirely per my response to BU Rob13. The majority of changes made in the template space by non-EC users are good changes; routine updates to navboxes seemingly the majority of such changes. --Izno (talk) 06:32, 1 January 2018 (UTC)
  • Oppose Counting transclusions isn't that useful in template vandalism, you really care about page views. If a template is transcluded 30 times, but one of those pages is Obama, it's a highly viewed template and should be protected. But if a stub template is used on a thousand pages that barely get read, protecting it is of little use. Beside that, protecting an entire namespace is an extremely dangerous road to go down IMO. We should always default to open. Legoktm (talk) 07:11, 2 January 2018 (UTC)
  • Support Semiprotection is not an insurmountable hurdle. The benefit of this proposal outweighs concerns, imo. James (talk/contribs) 14:43, 2 January 2018 (UTC)
  • Support with a reasonable threshold of transclusions (say 200?). Peter coxhead (talk) 16:01, 2 January 2018 (UTC)
  • Support Templates that are used in more than 200 pages should be permanently semi-protected. However, it doesn't seem to be reasonable to semi-protect all templates. I have seen constructive edits made by IP editors to templates. Extended confirmed protection for all the templates that are used to warn users about their edits. Pkbwcgs (talk) 16:49, 2 January 2018 (UTC)
  • Support as long as a) there is a transclusion threshold, b) the bot removes protection when a page drops below the transclusion threshold, and c) there is a mechanism to request that a template be unprotected (and a flag that the bot will obey). --Ahecht (TALK
    PAGE
    ) 22:28, 2 January 2018 (UTC)
  • Oppose per zzuuzz, Kusma et al. Better to apply whatever protection is required manually on an individual basis. At the end of the day, newby vandals are unlikely to be aware of template space anyway, and those out to deliberately disrupt the project would have no problems about waiting till they're auto-confirmed. Optimist on the run (talk) 11:22, 4 January 2018 (UTC)
  • Oppose per zzuuzz et al, Not all IPs are vandals and the other point is "We're an Encyclopedia that anyone can edit" .... we'd be defeating the purpose of the object if we locked all templates, Whilst in theory I agree with this proposal unless we ban all IP editing (which sounds great!) then I think it's best to just stick with semi protecting here and there and blocking here and there. –Davey2010Talk 16:47, 5 January 2018 (UTC)
  • Support, no particular opinion on best number for cutoff. --SarekOfVulcan (talk) 19:02, 8 January 2018 (UTC)
  • Oppose on ideological grounds. This is the free encyclopedia that anyone can edit. Protection of so many templates runs contrary with Wikipedia's principles. AdA&D 19:28, 8 January 2018 (UTC)
  • Support. Templates are a gaping hole in our antivandal protection; one edit can splash an offensive image, a WP:BLP-violating message, or even a link to malware across dozens or even hundreds of pages. I feel for our IP editors, but that horse left the barn years ago (and wouldn't even be an issue at all if the WMF listened to its editors with regard to SITE, but that's an entirely different kettle of surstromming). This is something that must be done, because the alternative is to wait until we're forced to - under terms we probably won't get to dictate. - The Bushranger One ping only 07:10, 13 January 2018 (UTC)
  • Support. WP:IP addresses are not people. IPs are free to do basic editing, but this is a situation where the risk for damage outweighs the benefit of the edit to a template. My second choice would by limited the protection to templates that are used in a dozen or more articles. Dennis Brown - 18:56, 13 January 2018 (UTC)
  • Support semi-protecting templates with ~250+ transclusions (or some other reasonable number determined by consensus). Tony Tan · talk 03:59, 17 January 2018 (UTC)

Discussion (permanently semi-protect the Template space)

  • If the proposal is adopted, then the transclusion count cut-off point should be somewhere above 200. The vast majority of templates are navboxes: they don't get vandalised often and they do requite quite a bit of maintenance that anons are generally able and willing to help out with. – Uanfala (talk) 15:46, 24 December 2017 (UTC)
  • I havent observed the editing history of templates much. But Uanfala's comment above makes sense. Also, by doing this we will take away one more thing from "anybody can edit" thingy. Yes, anybody can edit, but you need an account. Also, you need to wait for 4-5 days, and make 11 edits before you can edit.
    Also, if a vandal who is going to vandalise through templates, i think he is already familiar with concepts of socks, and sleepers. So I dont see much point in implementing these proposals. courtesy ping to Uanfala to let them know that their comment was moved.usernamekiran(talk) 23:44, 24 December 2017 (UTC)
  • The template subspace not only contains templates but also their talk pages. New users should be able to ask for help on the talk pages of templates so the talk pages shouldn't be semiprotected. ChristianKl❫ 22:57, 31 December 2017 (UTC)
    • So far two ideas seem to be floating: one, that a bot protects any template with more than 10 transclusions (uses) or a sitewide configuration change for the template namespace. In neither case would talk pages be affected. :) Killiondude (talk) 03:31, 1 January 2018 (UTC)

Atleast can we have semi-protection for 100+ transclusions? Another incident occured today that shows why it really is needed. {{Sidebar person}} is transcluded on 564 pages, including Donald Trump. Yet it was completely unprotected, and was vandalized by someone so that a huge "fuck donald trump" showed for at least 40 minutes (probably more) at-least 2 hours (based on a reddit post), 2 hours after the vandalism was reverted (only for logged-out users, because apparently they get a cached version of the page - so regular editors did not see it) I'm thinking that after that automatic semi-protection, at admin discretion, maintenance templates that shouldn't be changed much can be preemptively template/semi protected. Galobtter (pingó mió) 11:25, 1 January 2018 (UTC) I'm wondering if there's a smarter way to do it. Templates that are transcluded onto other templates (like that one was) should be protected at a lower count. I'm sure there are reasonable ways so that sports stat templates etc are not protected while ones like these are. Galobtter (pingó mió) 11:52, 1 January 2018 (UTC)

This sub-transclusion problem is of course a major one not addressed above. What today's vandalism shows, yet again, is that it's templates with not merely tens or a hundred of transclusions, but several hundred transclusions. The templates which generated this thread were around 1,000 transclusions. But also the real problem is not the vandalism but the caching and no effective means to bust the caches. -- zzuuzz (talk) 12:03, 1 January 2018 (UTC)
Another tool might be an admin ability to mass purge cache, perhaps cache's generated in a certain period of time (when the template was vandalized) linked to a certain template. Galobtter (pingó mió) 12:15, 1 January 2018 (UTC)
Has anyone confirmed or heard if that was seen on any other page or did it just happen to Donald Trump? Emir of Wikipedia (talk) 16:49, 1 January 2018 (UTC)
Yes others[58][59]. -- zzuuzz (talk) 16:54, 1 January 2018 (UTC)
Wikipedia:Purge#forcerecursivelinkupdate is interesting Galobtter (pingó mió) 16:56, 1 January 2018 (UTC)
Apparently can force cache update of all transcluded pages.. Galobtter (pingó mió) 16:58, 1 January 2018 (UTC)
  • Another 900-page template got hit this morning. Primefac (talk) 16:38, 10 January 2018 (UTC)
  • 200-page template that got hit, as well as 110-page and 31-page templates. As a minor note, this was after I semi-protected all templates with 350+ transclusions, so while they're still being vandalised, the templates are having a smaller impact as they pick the (to quote Bushranger) "lower-hanging fruit". Primefac (talk) 14:34, 14 January 2018 (UTC)

Hashing out a number

It looks like about half of the "oppose" votes are opposing the "blanket" semiprot, which I sorta get. That half also mentioned that an alternate option was an "X+ transclusions" option. Seeing as how the % of !votes who would be amenable to that is more than the "hard oppose", I think it's time to flesh out a number. The numbers that were thrown around the most were 10+, 100+, and 250+. So, despite my personal concern that we'll never agree on anything, I'd like to see if we can try. Primefac (talk) 02:21, 4 January 2018 (UTC)

  • 100+ - it's a high enough bar that the sports-type templates that frequently get updated by the helpful IPs won't be affected, but keep "bigger" templates from causing more harm than necessary (and <100 pages is a piece of cake for someone with AWB to null edit in a hurry). Primefac (talk) 02:21, 4 January 2018 (UTC)
    250+ per the comments below. Still a low bar for AWB/null edits. Primefac (talk) 13:56, 8 January 2018 (UTC)
  • 250+; I've made my reasons why clear above. —Jeremy v^_^v Bori! 02:27, 4 January 2018 (UTC)
  • 250+ or 10+ semi-protected pages. (I'm not sure this suggestion is feasible) Templates like Template:Duke Blue Devils men's basketball navbox should be able to stay unprotected. Templates transcluded on high-profile pages should have a lower threshold. power~enwiki (π, ν) 11:56, 4 January 2018 (UTC)
    Wait, are we talking semi-protection, or pending-changes protection? I could support pending-changes for the entire namespace. power~enwiki (π, ν) 12:17, 4 January 2018 (UTC)
    @Power~enwiki: I don't think the software supports pending changes in templates, as the software will always transclude the latest version. I can't find where I read that, though. -- John of Reading (talk) 07:23, 5 January 2018 (UTC)
    Not to mention that that would be too much of a strain on the hive of idiots that is CRASH. Like I said above, only utter fools would want so many pages CRASHlocked. —Jeremy v^_^v Bori! 20:36, 5 January 2018 (UTC)
  • No numbers please. If we came up with a rule that references a particular number I'm afraid this will have the effect of discouraging the exercise of common sense. If there's any take-home message from the above discussion, it is that the circumstances vary between templates and that some basic judgement should be exercised. If a template is unlikely to ever be edited – say, if it's simply a wrapper for a module, or it produces some very simple code that is unlikely to be changed – then it may be protected even if it has a low number of transclusions (say, 30). On the other hand, if it's a large template that is likely to need some sort of regular maintenance (like a navbox) then it usually doesn't make sense to protect it, even if it's got thousands of transclusions. – Uanfala (talk) 15:23, 11 January 2018 (UTC)
    The entire reason for this discussion is because of the increasing frequency of vandalism regarding templates with hundreds of transclusions, since it grossly disrupts articles the template is then transcluded on; hence the numbers. Blanket semi-protection of the Template: space isn't workable or viable, so the goal should be to eliminate the most tempting low-hanging fruit to prevent this sort of vandalism. —Jeremy v^_^v Bori! 21:43, 11 January 2018 (UTC)
  • My druthers would be to protect all of them, as only protecting "the most tempting low-hanging fruit" will simply make the fruit on the next branch up increase in temptation value. But if a number must be set, 10+. - The Bushranger One ping only 07:10, 13 January 2018 (UTC)
Unfortunately, the same is true with semi-protection, it isn't difficult to reach autoconfirmed level with trivial edits, even in a sandbox... —PaleoNeonate – 10:39, 13 January 2018 (UTC)
Template vandalism is virtually always drive-by, however. Setting up an autocon-buster takes time, and since the goal of these accounts is to cause disruption for a quick laugh then move on, that takes more time and dedication than they are willing to spend. —Jeremy v^_^v Bori! 17:48, 13 January 2018 (UTC)
  • 250+ is a reasonable number. Tony Tan · talk 04:02, 17 January 2018 (UTC)
  • I'd be fine with 250+, yes. Headbomb {t · c · p · b} 22:48, 17 January 2018 (UTC)

RfC: Cross-wiki redirects to Wiktionary

Should cross-wiki recirects to Wiktionary be deleted, all or in part? Huon (talk) 00:46, 26 December 2017 (UTC)

Survey (Cross-wiki redirects to Wiktionary)

  • Delete all Huon (talk) 00:46, 26 December 2017 (UTC)
  • Save prefix/suffixes. For instance: -ic, -izzle, Petro-, -ous, it seems appropriate for these. Brightgalrs (/braɪtˈɡæl.ərˌɛs/)[1] 13:56, 27 December 2017 (UTC)
  • Delete them all. I've always hated this cross-project redirects, and interwiki search results make them even less useful. FACE WITH TEARS OF JOY [u+1F602] 18:34, 27 December 2017 (UTC)
  • Delete all per NOTDICTIONARY, which they basically turn us into. TonyBallioni (talk) 19:13, 27 December 2017 (UTC)
  • Delete all yeah, don't see the value in them, NOTDICTIONARY and all that. Galobtter (pingó mió) 19:24, 27 December 2017 (UTC)
  • Delete all, unless the search filters out the results for a term (e.g. " ", though that page isn't a Wiktionary redirect). Jc86035 (talk) 08:54, 28 December 2017 (UTC)
  • Keep {{wiktionary redirect}} is not really a cross-wiki redirect, it's little more than a replacement for the standard "Wikipedia does not have an article with this exact name" message, and doesn't over-emphasize Wiktionary, but is infinitely more useful for readers that get there via a wikilink or google search.--Ahecht (TALK
    PAGE
    ) 17:48, 5 January 2018 (UTC)
  • Keep. I don't understand the rationale behind this proposal. {{wiktionary redirect}} serves a valuable function in helping to prevent the creation of dict-def articles. olderwiser 20:56, 5 January 2018 (UTC)
  • Keep. I think this keeps Wikipedia from being a dictionary. Otherwise we'd have articles that would be a definition. The soft redirect highlights the difference without leaving users in a lurch. Users are unlikely to click on a red link and then search and then click on the wiktionary suggestion. Nessie (talk) 17:03, 7 January 2018 (UTC)
  • Keep all per NessieVL's reasoning above. WP:NOTDICTIONARY says "Wikipedia is not a dictionary, phrasebook, or a slang, jargon or usage guide" (emphasis added). Linking to a dictionary does not make Wikipedia a dictionary just like linking to YouTube does not make it a video sharing platform. The redirect serves a valuable function in cases of (accidental) linking and actively prevents users from creating dictionary entries by making it clear that someone has already thought about it and decided that this is not a subject that should have an article. The template's documentation already limits the usage to a few cases but those are useful ones. Regards SoWhy 10:31, 8 January 2018 (UTC)
  • Keep per the rationales above. The links to Wiktionary help direct readers to the actual dictionary definition, which prevents a duplicate article from being created here. --Jayron32 16:38, 8 January 2018 (UTC)
  • Delete all - Wikipedia is not a dictionary. Jack1956 (talk) 00:42, 11 January 2018 (UTC)
  • Delete all per others and WP:NOTDICT, especially now that interwiki search results exist. Even when some users use a gadget via preferences settings to opt-out/hide the results, I don't see necessity to preserve all crosswiki redirects to Wiktionary entries as they take up a lot space and lack valuable encyclopedic content. Some of them can be either converted to or reincarnated as encyclopedic articles. Well, I perceive potential re-creations of some crosswiki redirects to those entries, but that's something that can be individually raised at RfD (or DRV) in the future. I wonder whether WP:G4 applies to those redirects if deleted per this discussion and then re-created.

    WP:R#KEEP guideline shows what reasons are to avoid deleting redirects; however, even when R#KEEP is enforceable for those redirects, I don't see how preserving those crosswiki redirect pages helps improve Wikipedia. Even the conditions of WP:R#DELETE aren't met for most of them. WP:GUIDES says to make some exceptions and use common sense in case that the guideline doesn't help much.

    Other things already do the same roles that those redirects do. Disambiguation pages and {{Wiktionary}} are sufficient enough and can take over the roles of those cross-wiki (soft) redirects. In response to an argument saying that those redirects are meant to prevent dictionary entries, the protection system, which includes creation-protection and EC-protection, already does the role (but by preventing re-creation) if things get out of hand. George Ho (talk) 09:23, 11 January 2018 (UTC)

Your argument fails to take into account direct links to such pages (R#KEEP #2 and #4), which includes links from other websites. People coming from such sites are not helped by the fact that the search does find Wiktionary entries now. As for the idea that they "take up a lot of space", Wikipedia:Don't worry about performance. So far neither you nor anyone else arguing for deletion has explained how WP:NOTDICT applies to links to a dictionary (because the page certainly does not say so) or how the project actually benefits from deletion (which is basically what WP:R#DELETE requires). Regards SoWhy 16:45, 11 January 2018 (UTC)
  • Keep all, per SoWhy. Those that can be converted to articles certainly should be, but anyone can be BOLD and do that. As for the rest, if we leave these as redlinks, people are persistently going to be driven to recreate them, and it's really not plausible to create-protect 1300+ pages. ♠PMC(talk) 09:57, 11 January 2018 (UTC)
  • Keep all until someone can point to several AfDs that have shown a clear consensus to delete individual cases. The purpose of NOTDICTIONARY is to ensure that people don't make fake articles that consist merely of a definition padded with some Google hits—an article needs encyclopedic content about the topic, but the cases being discussed are explicitly not articles. Johnuniq (talk) 21:34, 11 January 2018 (UTC)
  • Delete all - per above and WP:NOTDICT. Hummerrocket (talk) 00:41, 12 January 2018 (UTC)
  • Keep all. WP:NOTDICT is the reason these redirects exist, not a reason to delete them. The project would not be improved by this; in fact, quite the opposite, as there would suddenly be several hundred odd redlinks, that 1. would no longer be directing people to where they could find the information they want (interesting tip: not everyone uses, or knows how to use, search, so "interwiki searches exist" is not a viable reason either) and 2. acting as bait for people to create content that does fall foul of NOTDICT. Unless it's being suggested that every wiktionary redirect come with a serving of WP:SALT on the former title? In short: this wouldn't improve the encyclopedia, it would in fact harm the encyclopedia and have well-within-reasonable-plausibiity potential for further harm, and would require additional work from editors afterwards. (Also, did someone seriously say delete them because they take up space? DWAP aside, redirects take less server space than deletions do...) - The Bushranger One ping only 07:02, 13 January 2018 (UTC)
  • Yeah, I didn't think this would be so evenly split, otherwise I would've chimed in sooner. Of course these should be kept per what Bushranger and others above me have said. Killiondude (talk) 07:07, 13 January 2018 (UTC)
  • Keep per The Bushranger. MichaelMaggs (talk) 10:48, 13 January 2018 (UTC)
  • Keep. The Bushranger sums it up perfectly, so I won't parrot him and just say I completely agree. Dennis Brown - 18:54, 13 January 2018 (UTC)
  • Keep all per SoWhy, The Bushranger. These redirects exist because of WP:NOTDICT, not in spite of it. From a practical standpoint, like it or not, there will be people who try and use Wikipedia like a dictionary, and in those cases, we should direct them to Wiktionary, which is the sister project that is actually a dictionary. Having these redirects informs the above people of Wikitionary's existence and prevents them from creating half-assed dic-def pages that Wikipedia would then have to delete. ---- Patar knight - chat/contributions 16:32, 17 January 2018 (UTC)
  • Keep all per The Bushranger who's put it better than I ever could - These redirects all serve a useful purpose so as such should all be kept. –Davey2010Talk 16:44, 17 January 2018 (UTC)
  • Keep all, per Bushranger mostly. But also because some people might think it's worth linking food items in a sentence like "he had the soupe du jour and a croissant". Headbomb {t · c · p · b} 22:53, 17 January 2018 (UTC)
  • Keep per The Bushranger. Ckoerner (talk) 21:00, 18 January 2018 (UTC)

Threaded discussion (Cross-wiki redirects to Wiktionary)

There are some 1,300+ cross-wiki redirects to Wiktionary, many of them making use of Template:Wiktionary redirect. Since the default search has been adapted to show results from sister projects (including Wiktionary) when there's no WP page of that title, those redirects don't serve much of a purpose any more. The template was recently nominated for deletion; the discussion resulted in "speedy keep" and a finding that the fate of the redirects should be discussed at the village pump instead. So I'm bringing it here. The only redirects that arguably still serve a purpose are those where the Wiktionary page redirected to doesn't share a name with the WP page with the redirect. So keeping those and only deleting those where target name and origin name are identical is an option. Personally I don't think that's worthwhile. Huon (talk) 00:46, 26 December 2017 (UTC)

  • No comments on the merits of this proposal.As the closer of the original TfD, this is the correct venue for such discussions.Regards:)Winged BladesGodric 08:29, 26 December 2017 (UTC)
  • Support this deletion. And yes, a discussion here is the right way to handle these, not a TFD discussion (although a case could be made for a mass-RFD, a discussion here is probably better). עוד מישהו Od Mishehu 10:35, 26 December 2017 (UTC)
  • If there is a mass deletion, would links to the deleted pages be changed to wikt links? Or failing that, notification sent to authors/watchers of pages linking to the redirects so that editors can update pages? Nessie (talk) 13:31, 28 December 2017 (UTC)
  • What do you all think should be done with a page such as Floccinaucinihilipilification (one of the soft redirects affected by this proposal)? Redlinked, so that people will keep trying to create it? Hard redirect directly to the Wikitionary entry? "Just not have these pages" is an unlikely outcome, since many of these soft redirects are already protected due to repeated re-creation. WhatamIdoing (talk) 19:52, 28 December 2017 (UTC)
  • Are we sure that all people likely to end up on such soft redirects come to the soft redirects via the site search? Direct links to Wikipedia pages do exist, as does Google search. Jo-Jo Eumerus (talk, contributions) 10:53, 29 December 2017 (UTC)

Linking

I think the real issue is about linking, where most people will see these pages - should they be linked (they currently are somewhat), or should the wiktionary entry be directly linked, or is it that there is no reason to ever link them (or if there is, there should be an article instead of redirect)? If they shouldn't be linked I think they should be deleted to prevent linking. Galobtter (pingó mió) 10:25, 11 January 2018 (UTC)

I'm unsure whether MOS:LINK and WP:Red link help resolve this situation. I see cute hoor and moonless not used in mainspace pages. Local battery and cocksucker are used by a few pages. Per annum is used by multiple pages. See others at Special:WhatLinksHere/Template:Wiktionary redirect. George Ho (talk) 11:07, 11 January 2018 (UTC)

Bot to ping IP user talk pages when they're mentioned on another talk page

Hi, I've been working on a bot that will notify IP users when they're mentioned with a {{replyto}} by putting a {{ subst:Please see}} on their talk page. Thoughts?
Wikipedia:Bots/Requests for approval/Bellezzasolo Bot
Bellezzasolo Discuss 22:10, 7 January 2018 (UTC)

Do IP users have talk pages?Vorbee (talk) 07:57, 8 January 2018 (UTC)
Yes Galobtter (pingó mió) 08:20, 8 January 2018 (UTC)
Excellent idea. Annoying to ping IPs, and I'm sure there are quite a few pings that are missed because someone thought IPs can be pinged.. Galobtter (pingó mió) 09:22, 8 January 2018 (UTC)
The address–person relationship is often very short-term, sometimes even a matter of hours. Depending on the type of connection and how much time has passed, the person behind the IP address may be at a different one, with a different talk page. You might even be notifying a different person by then. Seems flimsy. ―Mandruss  02:03, 9 January 2018 (UTC)
The bot is able to respond in a matter of minutes. Obviously, IP editors are an issue, but a talk message like that could easily be a warning for vandalism- or indeed a block. Bellezzasolo Discuss 02:39, 10 January 2018 (UTC)
I'm not talking about bot response time, but I'll withdraw my objection after more thought. Before coding a "replyto" for an IP, an editor should consider the amount of time since the IP editor's activity, just as they should do now before posting on an IP talk page. The bot would not introduce a new problem. ―Mandruss  03:34, 10 January 2018 (UTC)
  • Could be a shared address, so a different person reacts to a ping regarding something they didn't do, even if it is just a few minutes. Many universities, offices, schools, have shared IPs. Plus IP addresses are not people applies here. If they want the benefits of being a user account, they need to get a user account. Dennis Brown - 18:51, 13 January 2018 (UTC)
Agree broadly with this. Not having an account is a choice. Accounts are free and anonymous, if they want the benefits of an account they can have one in under a minute. Beeblebrox (talk) 20:30, 13 January 2018 (UTC)

Should mathematical Equations be text instead of images?

There have been many times that I have wanted to use mathematical equations I found on Wikipedia, so that I could put them into a text document or online calculator like wolfram alpha and realized that they were inline images rather than formatted text. If I just want the equation as is, that would be fine, but I often want to use the equation or slightly edit it, and images are not usable. I just have to open multiple tabs and hand copy it over.

I am not sure how this would be implemented, but it would help end users like me. — Preceding unsigned comment added by Michalchik (talkcontribs) 23:01, 8 January 2018 (UTC)

I'm confused. Taking a few examples from template:math:
f(x) = bx = y
and
1/21/3 = 1/6
copy/paste just fine from WP directly into Wolfram Alpha for me using Win10 and Google Chrome.
+∞
0
ex dx = 1
does not. From the above, though, I'm not sure what alternative presentation you are suggesting. Wtmitchell (talk) (earlier Boracay Bill) 02:49, 9 January 2018 (UTC)
@Wtmitchell: A) The user is probably commenting on <math> tags, which for B) the majority of users and all readers (not logged in users) are served images, rather than some obviously copy-and-pasteable stuff. --Izno (talk) 03:35, 9 January 2018 (UTC)

Having mathematical equations as text seems to make sense for me - after all they are not images. Vorbee (talk) 11:53, 12 January 2018 (UTC)

@Whatamidoing thanks for the ping. It would be great if average users could copy equations on Wikipedia the same way as on other websites. For example two days ago user:Elcap wrote: "Bei der Schreibweise der Formeln und den Einheiten habe ich Probleme, seitdem ich Windows 10 habe. Die Formeln und Einheiten mit "math" geschrieben werden beim Kopieren nicht in Word eingefügt, deshalb in geschriebener Weise." [60] (= he cannot copy equations into microsoft word) I did not enquire further since the discussion was on improving the article, but from my expericence with <math>, the very old "use html for simple formulas" was copyable, the png images could be copied as images (with obvious drawbacks), MathJax (as opt-in for registered users) was copyable and the current rendering is not, unless you are for example a firefox user and have installed the "MathML Copy" addon.
My suggestion would be to use MathJax like on math.stackexchange.com, however it appears to be difficult to integrate into MediaWiki and my proposal [61] did not get enough votes. I hope this changes with MathJax 3.0 (a first alpha version was released recently) which has built in support for node.js.--Debenben (talk) 17:05, 13 January 2018 (UTC)
@Michalchik: In Preferences -> Appearan