Would it be extremely controversial to propose that the relevant passage WP:IMGLOC reads something like:

"place images of people,animals, vehicles and/or moving objects so that they "look" or "move" toward the text..."?

I have been trained (as a professional journalist/book editor) according to a stylistic convention that positions images so that all living/animate/moveable things appear to be facing/pointing into text.

For an example of what I mean, see the images of similar trains on the left and right. That is the usage of Image 1 and Image 2a are in accordance with the layout convention to which I am referring (while the use/positioning of Image 1a and Image 2 is not). Assuming that there are no technical/content issues with Image 1 (vis-a-vis Image 2), it will always be preferred, in terms of this particular convention.

Grant | Talk 05:27, 15 April 2018 (UTC)[reply]

I agree it's a very good style idea. Not obviously the sort of thing that the Manual of Style usually covers, though. I wonder if there's a better venue to try to educate users about such visual composition style issues. Dicklyon (talk) 05:35, 15 April 2018 (UTC)[reply]

It is exactly what WP:IMGLOC (Wikipedia:Manual_of_Style/Images#Location) covers, currently saying: "It is often preferable to place images of people so that they "look" toward the text. (Do not achieve this by reversing the image, which creates a false presentation; faces are never truly symmetric even in the absence of scars or other features.) Probably there are other places - User:Grant65, you should always be very clear exactly where proposed changes here should go. Johnbod (talk) 15:12, 15 April 2018 (UTC)[reply]

Thanks User:Johnbod; I have updated my original post and heading to address this. Grant | Talk 02:15, 16 April 2018 (UTC)[reply]

To play Devil's advocate, I've seen suggestions that things should always look to the right because looking to the left is often seen as looking backwards. ( http://www.artlebedev.com/mandership/137/ ) Also, we often have a very limited selection of images, many of them being too dark, poorly framed, out of focus, distracting backgrounds, etc. To have to reject a good quality image and use a lower quality image solely because it points in the right direction is likely to crop up again and again. Or we have to put the good image on the opposite of the page but that often conflicts with page layout too (eg, the lower left image intrudes on the first sentence of this paragraph at the screen settings I am using). The idea is good but I think our lack of good images to choose from is going to cause conflicts. Perhaps we can say that images pointing towards to the text (or possibly to right) are preferred when choosing among similar quality images.  Stepho  talk  06:08, 15 April 2018 (UTC)[reply]

I agree withStepho-wrs, I have run into the problems described above in GA and FA reviews. It is nice to have the picture "look" towards the centre, but not always practicable. One thing we do not want, is for people to mirror images to make them look inwards. That way lies abomination. · · · Peter (Southwood) ^(talk): 07:02, 15 April 2018 (UTC)[reply]

• It's nice when it can be done, but it can't always, and having guidelines for it will only give ammunition to people who have little better to do than enforce such things. So if we want to add such wording, we should make it clear that it is just an option. FunkMonk (talk) 13:37, 15 April 2018 (UTC)[reply]

Before even considering putting some of this in the guidelines, authoritative sources should be brought forward to confirm what is stated here as a mere opinion. −Woodstone (talk) 14:39, 15 April 2018 (UTC)[reply]

Not really necessary, it is a matter of stylistic preference, and therefor not really essential to provide authoritative sources. We can come up with a consensus preference based on our opinions and do not have to go with someone else's opinions. The practical problem that it is often not possible without degrading the page in some other way is far more important. · · · Peter (Southwood) ^(talk): 15:42, 15 April 2018 (UTC)[reply]

You could try looking at any professional magazine or website, but here's a book, and there are various snippets from this search. Johnbod (talk) 04:04, 16 April 2018 (UTC)[reply]

• Yes, we should do this. The current text at WP:IMGLOC, quoted above, is too restrictive. This universally understood principle of page design applies just as much to horses seen in profile as "people", and to moving objects too. The current language is "It is often preferable ...", which could hardly be milder, and ought to sooth the worries expressed above. Johnbod (talk) 15:18, 15 April 2018 (UTC)[reply]
  • I would go so far as to say it is preferable, when not problematic for other reasons, of which there are several possibilities, so that it will only occasionally be practicable with our current stock of images. In 10 years? Who knows? · · · Peter (Southwood) ^(talk): 15:42, 15 April 2018 (UTC)[reply]
    • ???I'm not sure you've grasped the proposal here. It means placing some images on the left rather than the right, which is normally no great problem. Commons has 46 million images. Johnbod (talk) 03:57, 16 April 2018 (UTC)[reply]
      • I speak from personal experience that though commons may have 46 million images, for some specific subjects it has precisely one, when it even has the one. (Not to speak of the difficulties finding the right one when it exists, that is another issue)
      • There are times when putting an image on the left side is a problem. Normally no, but occasionally yes. A page should look acceptable in all widths from mobile to wide screen desktop. Cheers, · · · Peter (Southwood) ^(talk): 14:07, 16 April 2018 (UTC)[reply]
      • Are you proposing moving infoboxes to the left to suit the photo? · · · Peter (Southwood) ^(talk): 14:12, 16 April 2018 (UTC)[reply]
        • • No, certainly not. But I am glad to see you are retreating from your earlier position that "it will only occasionally be practicable", which was, well, wierd. Johnbod (talk) 18:34, 16 April 2018 (UTC)[reply]
            • OK, I concede that there will be rather a large number of occasions, possibly even the majority of occasions. Difficult to analyse, and not a good choice of expression. The point is that there are occasions where is is not the best option, and this might happen quite often. Cheers, · · · Peter (Southwood) ^(talk): 07:56, 17 April 2018 (UTC)[reply]
• Comment Our article on Egyō currently includes an image in its lede that is kind of a stand-in for the infobox that isn't there yet (read: it's not going to be moved to the left. The image is a scan of an old game card and a number of other articles in the series include images from the same set. The subject of the article is depicted facing right, essentially by accident. The image cannot be mirrored because of the prominent text, which would become gibberish. Then there's Lafcadio Hearn, who deliberately concealed his left eye in photographs: mirroring those photos would completely destroy the "meaning" of them, and keeping all images of the subject on the left-hand side of the page is a stylistic nightmare. I know no one here is seriously proposing anything like that, but any change to the MOS should make it clear that it should only be implemented with care for the specific image and context. Hijiri 88 (聖やや) 09:43, 18 April 2018 (UTC)[reply]

Well, shit happens. Lead photos should almost always go on the right, certainly. But please note that "The image cannot be mirrored because" MOS explicitly forbids this, and correctly too! I repeat that the current language is "It is often preferable ...", which could hardly be milder. Johnbod (talk) 13:13, 19 April 2018 (UTC)[reply]

• Where are with this? Comments above have mostly concerned the general issue of images facing into the page. I'd remind people that WP:IMGLOC has said for years "It is often preferable to place images of people so that they "look" toward the text. (Do not achieve this by reversing the image,...". As far as I know this has not led to the sky falling on our heads, plagues of boils, or the slaughter of the first-born. The proposal here is to add to "people" the words "animals, vehicles and/or moving objects". There have not so far been comments that say this is inappropriate, ie that it works for people but not animals, vehicles and/or moving objects. Does anyone feel this? Johnbod (talk) 02:56, 27 April 2018 (UTC)[reply]

  Just do it. Then you'll see if anyone objects. Dicklyon (talk) 02:58, 27 April 2018 (UTC)[reply]

Unless I'm mistaken, both WP:IMAGE and standard graphic design already prefer that in the main article body, images not look off the page. The exception is the infobox, where the image is always on the right and sometimes of necessity must look off the page.--Tenebrae (talk) 04:16, 27 April 2018 (UTC)[reply]

I think you are mistaken re WP:IMAGE, a rather short page that doesn't mention the issue that I can see. The existing text at WP:IMGLOC (part of Wikipedia:Manual_of_Style/Images) is quoted a number of times above. We are discussing adding to that, as it currently only refers to "images of people". You are correct about "standard graphic design", also discussed above. Johnbod (talk) 12:55, 27 April 2018 (UTC)[reply]

Sorry; I meant MOS:IMAGES, which states "It is often preferable to place images of people so that they 'look' toward the text," while noting the exception that applies primarily to the infobox.--Tenebrae (talk) 18:40, 27 April 2018 (UTC)[reply]

All other things being equal, images facing in to text is preferred. However, 1) images of a subject may not be equally divided between left- and right-facing examples, 2) images are never to be changed to reverse the orientation, 3) higher quality images should be used even if they would be facing the "wrong" direction, 4) infoboxes (a major use of images) must always be on the right, 5) moving an image to the other side of the page may not be a viable solution (it may create "sandwiched" text or interfere with other formatting). --Khajidha (talk) 12:40, 27 April 2018 (UTC)[reply]

Yes, agreed (all mentioned above). So presumably you are in favour of the proposal. Johnbod (talk) 12:55, 27 April 2018 (UTC)[reply]

• Oppose We don't need MOS guideline for this. ·maunus · snunɐɯ· 12:57, 27 April 2018 (UTC)[reply]

Any reason why not? We already have one, but only covering people. It is proposed to add 5 words to it. Do you actually disagree with the broad principle? That would be a refreshing novelty. Johnbod (talk) 13:00, 27 April 2018 (UTC)[reply]

Yes, I disagree with the broad principle. But also per instruction creep. It is entirely irrelevant where people are looking and moving in an image, and should not be a decisive factor especially not one that is MOS mandated, but just one factor among many to take into account using standard editorial judgment. It is simply overregulation and micro-management of article space. Also in my own publishing I have never encountered a style guide that included any mention like this, and if it did as an author I would be annoyed at having my judgment of what is a good illustration of a topic interfered with by some arbitrary aesthetic preference of a publisher.·maunus · snunɐɯ· 15:44, 27 April 2018 (UTC)[reply]

So would you support the removal of the text on this that has been in the page for years? Johnbod (talk) 15:47, 27 April 2018 (UTC)[reply]

I would.·maunus · snunɐɯ· 17:57, 27 April 2018 (UTC)[reply]

• Oppose Some line needs to be drawn somewhere, and this level of pedantry is, to my feeling, a bridge too far. Yes, with portraits of a single person, it is somewhat more aesthetically pleasing to have the person face the center of the screen when their image is placed on one edge or the other, I get that, but to then offer guidance for all sorts of objects like trains and cars and the like is starting to get a little too prescriptive from my feeling. There's no need for this level of guidance. The guidance for personal portraits is fine, but this is too much. --Jayron32 16:30, 27 April 2018 (UTC)[reply]
• Comment. An example of an article which might be affected is Train (appropriate, given the example that started this discussion). The first image is of a train speeding away from the article. Would the page be improved by substituting a different image, or moving the existing image to the left? Pburka (talk) 18:04, 27 April 2018 (UTC)[reply]
  • Since that image is essentially in the spot of an infobox image and can't really lead the article on the left side of the page, it's not really a good example. If there were a different image in that spot and this train image were in the article, proper graphic design would place it on the left. --Tenebrae (talk) 18:33, 27 April 2018 (UTC)[reply]
    • If you search commons, you'll find we have a handful of other train images we could choose from. Pburka (talk) 19:43, 27 April 2018 (UTC)[reply]
    • Indeed, given that one type of image we certainly not short of is ones of trains, yes, I'd change it for one heading into the page. Johnbod (talk) 03:42, 29 April 2018 (UTC)[reply]
• Support It's just proper, ordinary graphic design, and since most people aren't graphic designers, I believe it's practical and useful to mention. We could even say it more simply with a net one-word addition: "It is often preferable to place images of people photographic subjects so that they 'look' toward the text." --Tenebrae (talk) 18:44, 27 April 2018 (UTC)[reply]
  • Yes, of course by no means all images 'look' anywhere, but then it just doesn't apply. Johnbod (talk) 03:42, 29 April 2018 (UTC)[reply]

There is currently a discussion regarding various interpretations of the Film MOS going on over at Wikipedia talk:Manual of Style/Film specificly regarding interpritations of how production sections should be set up/worded. You can view or join the discussion here. --Deathawk (talk) 04:42, 26 April 2018 (UTC)[reply]

From the title I was expecting a proposal to film us in debate here. Tony (talk) 06:49, 29 April 2018 (UTC)[reply]

The US gov has some gnarly styling that shows up in a few article titles such as San Jose–San Francisco–Oakland, CA Combined Statistical Area; the jamming together of city names with hyphens, as they usually do, was moved to en dashes in this one recently, but it still exhibits the use of the postal code, with mismatched comma, and the unnecessarily capped Combined Statistical Area (which they sometimes abbreviate to CSA). Most of our articles that once had titles of that sort have been moved to more rational titles, especially since they're not really about the statistical areas per se. Here is an Obama WH doc that lists all these things, showing off further stylings like hyphen-connected pairs or triples of state postal codes as in New York-Newark-Jersey City, NY-NJ-PA Metropolitan Statistical Area, double hyphens in things like Nashville-Davidson--Murfreesboro--Franklin, TN Metropolitan Statistical Area, etc. It's pretty hideous, but thankfully these don't show up in too many articles. Here's another title: Evansville, IN–KY Metropolitan Statistical Area. And Joplin–Miami, MO–OK metropolitan area is one where the hyphens changed to dashes OK, and the caps are reduced, but the unbalanced commas around the "MO–OK" postal code pair still looks weird and cryptic.

I'm not proposing anything in particular at this time, just seeking help if anyone wants to help figure out how to rationalize some of the place where these do show up. Dicklyon (talk) 00:33, 29 April 2018 (UTC)[reply]

I just noticed I participated in a discussion about this five years ago, at Talk:Lafayette-Opelousas-Morgan_City_CSA#Proposed_move. It didn't go anywhere useful. We should discuss again. Dicklyon (talk) 05:02, 29 April 2018 (UTC)[reply]

• Yeah, the names of these “statistical areas” are often clunky (and even contrary to the normal rules of English grammar). However, I think we need to present such names as they appear in the real world (ie sources), and not try to “correct” them to what we think they “should” be. When it comes to the presentation of names, we should only step in when sources are mixed in their presentation. Blueboar (talk) 11:35, 29 April 2018 (UTC)[reply]
  • The "external sources" meme might be ok when there's consistency out there. But as we all know, much naming is inconsistent in reliable sources. Tony (talk) 13:24, 29 April 2018 (UTC)[reply]
  • These names don't appear in a lot of sources. It's not clear that statistical areas are even "notable" – they're basically just line items from a long list of stats, and the "areas" they correspond to are usually known as something more sensible (and most already correspond to articles by other names). And even the gov docs don't refer to them consistently, sometimes adding a second comma, sometimes omitting or spelling the states, using dashes, etc. (e.g. here the US Department of Labor uses en dashes and matched comma; and this one from them uses em dash between state codes). Dicklyon (talk) 15:40, 29 April 2018 (UTC)[reply]

In the case of Joplin–Miami, MO–OK metropolitan area, I've moved it back to be about the metropolitan area as opposed to one or the other statistical area. As far as I can tell, there's no such thing as the claimed Joplin–Miama MSA, but there is a CSA. There are essentially zero sources for anything in this article. Dicklyon (talk) 16:32, 29 April 2018 (UTC)[reply]

Hmmm... I am beginning to think the real question here has more to do with WP:Notability, rather than WP:MOS. Are these "statistical areas" really notable enough for a stand-alone article... or should they be subsumed into other articles dealing with the geographic region? (If we subsume, then we won’t have to worry about using the clunky names as titles). Blueboar (talk) 17:31, 29 April 2018 (UTC)[reply]

A further annoyance with these areas is that they have a tendency to expand and change their names. A discussion at WT:WikiProject Cities#Former/deprecated CDPs touched upon this area. For me, when the only information unique to some bureaucratically defined area is a bunch of statistics, it is not really notable. Articles for such places are either deserts of stats, or they get fluffed up with info copied from other articles. Kill them, kill them all damn it! Batternut (talk) 19:15, 29 April 2018 (UTC)[reply]

Yes, I agree that what's notable about these areas is not their statistics, and as I said before, most such articles have already been renamed to be about the actual areas. The remaining couple dozen can't just be deleted, in many cases; they need to be looked at, moved, or merged. In any case, let's do try to get these funky things out of titles one way or another. Dicklyon (talk) 20:09, 29 April 2018 (UTC)[reply]

MOS:FOREIGNITALIC has advice on the use of italics for isolated foreign words. What if the foreign word is a unit used by {{convert}}? Please join the discussion at Wikipedia talk:Manual of Style/Dates and numbers#Unit names that are foreign words. Johnuniq (talk) 00:32, 3 May 2018 (UTC)[reply]

At Manchester Small-Scale Experimental Machine and other articles, User:Eric Corbett has styling the reference sections in a novel way using Template:style-nt that he created recently, to give himself control over text point size, whether or not an edit button appears by the headings, whether they show up in the TOC or not, and what-all. The coding looks cryptic, and it's hard to discern any good reason for not going with the usual default style that one gets with normal section and subsection heading markup. He keeps putting it back, with little justification; see User talk:Eric Corbett#What does Template:style-nt do?. Does the MOS have anything to say about editors going their own way on such styling? Dicklyon (talk) 04:28, 7 May 2018 (UTC)[reply]

What does it do? What's the point of writing documentation if nobody reads it? Eric Corbett 04:55, 7 May 2018 (UTC)[reply]

This template should probably be submitted to WP:TFD. The headings are the way they are and users really shouldn't be trying to Make Their Pages Perfect With Respect To Their Preferences. There is also a bit of false documentation regarding whether bold headings are allowed by MOS--they aren't. --Izno (talk) 05:15, 7 May 2018 (UTC)[reply]

That's not what the MoS says at all. What it explicitly discourages is the use of the semicolon as in ";pseudo-heading" to produce bold headings, not bold headings per se. And it strongly encourages the use of heading markup as in "===Real heading===" for accessibility reasons, which this template supports. But I'm interested in which part of the MoS you're using to justify your assertion that "users really shouldn't be trying to Make Their Pages Perfect". Do you have a link? Eric Corbett 06:45, 7 May 2018 (UTC)[reply]

Focusing on the template issue is really to miss the point. I could, for instance, achieve a similar result to the template by prefixing a normal section header with something like <div id="section-header" style="font-size:14px;"> and suffixing it with </div>, or I could even override the default look of a level 3 header - or any other - by writing a new CSS definition. What would the MoS have to say about that, and why should it care? Eric Corbett 07:12, 7 May 2018 (UTC)[reply]

Yes, you could do that, and it would likely get reverted (I see you've made a pointy edit to that effect at already). The use of the template is more insidious, as the naive editor will see it and just think it's some widely used way of making some consistent styling, rather than your personal idiosyncratic way of styling, which is what it really is. Can't we all just use a consistent style? Aren't you a software engineer? Have you not bought in to the advantages of coding with a shared and understood style guide? Dicklyon (talk) 14:23, 7 May 2018 (UTC)[reply]

Why would it get reverted? In what way does it go against the guidance in the MoS? Of course we could all use a visually consistent style, this one for instance, which is more aesthetically pleasing than the default site-wide css for level 3 headers. Is it necessary to point out that the purpose of such css definitions is so that they can be overridden? And it's rather insulting to call my demonstration, clearly labelled as such, as pointy, but insulting behaviour appears to be your forte. One final thing: inconsistency in other areas of the MoS is actively encouraged, date formatting and spelling are two obvious examples. Is your next campaign going to be to force a single date format down everyone's throats? Eric Corbett 14:35, 7 May 2018 (UTC)[reply]

That sounds uncomfortable. Dicklyon (talk) 14:46, 7 May 2018 (UTC)[reply]

To address the broader question: MoS is a guideline primarily about the most common WP-writing "style" (spelling, grammar, tone, layout, etc.) questions and problems. It is not the One True Source of all common sense and consensus on Wikipedia, the general operating principle of which is that what has been working fine for a long time and is well-accepted by the community is the consensus, even if it was not established in a particular discussion. If someone changes something about that de facto consensus, and the change isn't met with little or no objection then widely adopted by others, it becomes part of the new consensus. Otherwise, we'd have to have millions more consensus discussions and a huge database to keep track of them, a project that might exceed the scope fo WP's actual public-facing content. "MoS doesn't have a rule stopping me" doesn't equate to "I can do anything I want". Otherwise MoS would have to be longer than The Chicago Manual of Style combined with New Hart's Rules, to account for every imaginable style idea. PS: I have no objection at all to adding an explicit MoS rule against using CSS tricks (manual or templated) to alter the default formatting of headings and other page elements, except inline CSS within a heading to make it conform to a particular MoS expectation. There may be some other already-accepted tweaks of this nature, such as ToC template options to suppress display of level-3 and lower headings in some cases when necessary to prevent excessively long tables of contents. If there's something wrong with how elements like the headings work on Wikipedia, and it can be addressed in CSS, then the idea should be proposed at Mediawiki talk:Common.css for inclusion in the site-wide stylesheet. If it's a sweeping change, it should probably be proposed at WP:VPTECH first.  — SMcCandlish ☏ ¢ 😼  00:45, 8 May 2018 (UTC)[reply]

One more question: what does the name style-nt mean? nt for "next thing" maybe? Dicklyon (talk) 14:24, 7 May 2018 (UTC)[reply]

What does it matter? I would have preferred to call it simply {{style}}, but a template with that name already exists. Eric Corbett 14:40, 7 May 2018 (UTC)[reply]

So why not style-ec? It matters because the Template namespace is intended to be understandable and usable by editors; it's not your personal playground. Dicklyon (talk) 14:46, 7 May 2018 (UTC)[reply]

I've really done with discussing anything with you, anywhere. You're quite impossible to deal with. Eric Corbett 14:51, 7 May 2018 (UTC)[reply]

In what way? His point is correct and sensible, though what this template is named is the least of the concerns about it.  — SMcCandlish ☏ ¢ 😼  00:45, 8 May 2018 (UTC)[reply]

Template:Style-nt A specimen, for delectation. I like gadgets, this is fun! Batternut (talk) 11:08, 7 May 2018 (UTC)[reply]

Apparently WP isn't meant to be fun. ;-) Eric Corbett 12:00, 7 May 2018 (UTC)[reply]

When misinterpreting WP as a CSS hacking playground and display case of Web-styling wizardry, that assessment is essentially correct. WP is meant to be an enjoyable environment in which to work on building an encyclopedia, but it's not even intended to be "fun" for readers, but simple and informative. It's not an entertainment website or a MMPORG, nor a place to flex one's Web coding skills in personally aesthetic ways. This is all covered at WP:NOT (#GAME, #WEBHOST, and some other sections).  — SMcCandlish ☏ ¢ 😼  00:45, 8 May 2018 (UTC)[reply]

• See Wikipedia:Templates for discussion/Log/2018 May 7#Template:Style-nt Jc3s5h (talk) 13:16, 7 May 2018 (UTC)[reply]

  I was about to suggest TfD.  — SMcCandlish ☏ ¢ 😼  00:45, 8 May 2018 (UTC)[reply]

• I don't think this really has anything to do with references, apart from the fact that the headings being formatted are in reference sections. The issue is using markup to change the way that section headings are formatted. The MOS does not cover this explicitly, but that's because it does not try to discuss every convention. In this case, there is a clear convention across the project not to try to change the font, size, weight, or other aspects of section titles. So editors should just leave that formatting as is, rather than trying to achieve some kind of special heading formatting in specific articles. I don't think this needs to be in the MOS, actually - 99.99% of editors seem to follow the convention without any trouble, so it's just a matter of fixing any uncommon articles that don't follow the convention. — Carl (CBM · talk) 15:18, 7 May 2018 (UTC)[reply]

  Agreed. This isn't about refs, but about consistency of standardized interface elements (or, rather, about unusual deviations from that consistency which don't seem to provide enough reader utility to cover the editorial cost of the divergence, or the cost to reader expectations in loss of consistency. There's a reason we don't do things like switch to a green background and a Celtic-y uncial font at articles about Ireland, and so on, despite the sense that "designer" types have that it would be fun and evocative to do so. WP is not a brochure, nor a Web-design experimentation platform.  — SMcCandlish ☏ ¢ 😼  00:45, 8 May 2018 (UTC)[reply]

Background

Over two months ago we had an RFC on linking to Wikidata, the result of which was "no consensus". I initiated the RFC after a user was continually adding links to wikidata to replace articles that were deleted through AfD for notability concerns, here is an example. Unfortunately, I did not create the question that we voted on and it was worded with the extreme position of "Never link to Wikidata" which got mixed support. I think most people generally agree that the links are the sidebar are useful (in particular the inter-language links) and should not be removed. However, within the body of the article there was less support for using wikidata. Some people also indicated that inline interlanguage links (see WP:ILL) may also be appropriate. However, almost everyone agreed wikidata links should not be a substitute for a red-link (or a deleted article). While I agree that linking different language versions of wikipedia is a great feature, otherwise I find wikidata to be unreliable and directly linking to it would be confusing for the average user.--Rusf10 (talk) 00:50, 10 May 2018 (UTC)[reply]

RFC Question

Should we ban links to wikidata within the body of an article?

NOTE- Since there is another RFC on using wikidata in infoboxes, none of the options below will apply to the usage of wikidata in infoboxes since that is being determined separately.

I'm providing three options:

• Support- Wikidata should not be linked to within the body of the article (this includes hidden text links). This will have no impact on the sidebar links nor Wikipedia:Authority control
• Support, but with exception for inline inter-language links- Same as above, but allows for exception for use of Template:Interlanguage link
• Oppose-Link to Wikidata if an article does not exist

I am adding an additional option to clarify: --RAN (talk) 03:16, 10 May 2018 (UTC)[reply]

• Oppose- Allow hidden text links with Wikidata Q-numbers such as <!-Q1123456--> so that a duplicate Wikidata entry is not created in the future

Survey

• Support- full ban in body of article as proposer.--Rusf10 (talk) 00:50, 10 May 2018 (UTC)[reply]
• Oppose - This appears to be about Rusf10 removing hidden links Q-numbers formatted as <!-Q123456--> to Wikidata from tables that list multiple people that do not currently have an entry in English Wikipedia. The Wikidata entry links to Wikipedia entries in other languages and links to Wiki Commons and Wiki Quote, even if they do not have an English Wikipedia entry. The hidden links will let an editor know that if an article is recreated or a new entry is created for this person, an entry at Wikidata already exists. This will hopefully reduce duplication of Wikidata entries. It also allows Wikipedia to disambiguate people that appear in articles and lists that currently do not have Wikipedia entries. This way a person can know that say "John Smith, Mayor of Yourtown<!-Q123456-->" in an article on Yourtown is the same person as "John Smith, President of BigCompany<!-Q123456-->" that appears in the article on BigCompany. It will allow someone who creates an article in the future to search for hidden text on the string "Q123456" and find both entries and create the properly disambiguated link to the article. Of course only someone actually editing an article will be able to see the hidden link Q-number. --RAN (talk) 02:06, 10 May 2018 (UTC)[reply]

This will do absolutely nothing to prevent duplicate entries in wikidata for topics that already have articles in wikipedia, so it seems to me to just be an excuse, not a real solution to a problem. If duplicate entries is really a widespread problem in wikidata then why doesn't wikidata come up with its own solution for this that doesn't involve wikipedia?--Rusf10 (talk) 03:38, 10 May 2018 (UTC)[reply]

Okay, to clarify what I think RAN is talking about: Suppose there is a redlink here. Somebody sees it, creates an article, and then creates a Wikidata entry for the new article. What I think RAN is suggesting is that any hint we can give here is useful, that a Wikidata item already exists, and so if/when a new article is created here, then it should be linked to the existing Wikidata item, rather than have a new one created for it.

Wikidata users make quite an effort to try to hunt down and merge duplicates, eg trying to spot potential duplicates that matching birth/death dates, or the same value for an external ID, or apparent duplicates that come up organically in search. But all these are playing catch-up, and are never 100%. It's altogether better if the new article gets linked properly from the outset.

Another reason (IMO) may also be worth considering why such references in comments might be useful, namely that if a wikidata item exists, it may have some useful information and references for basic facts like full names, dates, external identifiers, places of activity, birth, death, etc that all may be of use to somebody creating an article. Jheald (talk) 10:54, 10 May 2018 (UTC)[reply]

• Support a ban, or at least strongly discourage them, similar to the language in WP:EXTLINKS. Pburka (talk) 02:38, 10 May 2018 (UTC)[reply]
• Oppose Such links should be allowed to be used where they can provide extra information to readers and editors about the topic. They are not completely external links, they are links within the Wikimedia movement. Thanks. Mike Peel (talk) 12:07, 10 May 2018 (UTC)[reply]
• Support, but with exception for inline inter-language links. I oppose the concept of comments that point to Wikidata, because there is no unambiguous format to determine the exact meaning of such comments, or exactly how the comment would be associated with the text in the article. Such a situation is an invitation for people to write bots that screw things up. Jc3s5h (talk) 12:20, 10 May 2018 (UTC)[reply]
• We should not link to wikidata at all. Inline interlanguage links have always been discouraged in practice (notice how few of them exist). There is no reason to add an exception for Wikidata about them. — Carl (CBM · talk) 12:40, 10 May 2018 (UTC)[reply]
• Support with exception for interlanguage links per Jc3s5h. Ealdgyth - Talk 13:16, 10 May 2018 (UTC)[reply]
• Support with exception for interlanguage links per Jc3s5h and Ealdgyth. ILLs may be rare due to the fact that the English Wiki is currently standing at 5,646,567 articles, well ahead of most other languages (wp:List of Wikipedias). (Indeed if you ignore those articles written by Lsjbot, well over double the size of any other Wiki.) Therefore few articles will appear in another language and not in English, except for small geographic features and locally notable persons. ILLs are invaluable for setting up a link that can be subsequently translated either full or as guidance. When I was working on Peter Harlan I used an ILL to get the basis of the article and there are still ILLs for Cornelia Schröder-Auerbach [de], Hanning Schröder and Castle Sternberg [de] within it. It means the reader has at least the possibility of finding the information until someone has the time to create an English version. Martin of Sheffield (talk) 13:40, 10 May 2018 (UTC)[reply]
• Oppose any restriction per my comment in the previous RfC. This an utter baby-with-the-bathwater case, which would disallow links to Wikidata in tables, for example. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:35, 10 May 2018 (UTC)[reply]
• Mu I'm all for creating a policy to explain how and what sorts of links are useful. This sort of RFC, which is too restrictive and too ignorant of nuance, is not the way to do it. --Jayron32 14:51, 10 May 2018 (UTC)[reply]
• I cannot choose any one of the four options, although the closest thing would probably be "support with exception" + "allow hidden comments". The status quo appears to be to discourage inline interwiki links in general, except for Wiktionary and Wikisource links and those generated by {{Interlanguage link}}. Regardless of whatever concerns there are with Wikidata at this juncture, I think the current Manual of Style guidance should be sufficient, although I would update it to explicitly permit {{ill}} links to the Wikidata item. Banning hidden comments based on innocuous material, if the proposer is indeed in support of this, is patently ridiculous and unnecessarily heavy-handed, especially since these are not actually links and readers aren't supposed to see them. I don't think it's necessary to lump them together with real working links. Aside from the issue with hidden comments, I think the RfC should be clarified to indicate that the proposer is, at least according to their own words, in support of the status quo that currently exists. Jc86035's alternate account (talk) 15:06, 10 May 2018 (UTC)[reply]

Overlaps with another RFC

• Please note - This RFC overlaps somewhat with another that is still ongoing (see Wikipedia:Wikidata/2018 Infobox RfC). I do not believe that there is any intentional forum shopping involved... but we do need people to know that similar questions are being discussed elsewhere. Blueboar (talk) 15:01, 10 May 2018 (UTC)[reply]

Thank for letting me know about this, I will add a statement above to clarify the proposal will not apply to infoboxes since that is being decided elsewhere.--Rusf10 (talk) 16:07, 10 May 2018 (UTC)[reply]