Wikipedia:Village pump (miscellaneous)

From Wikipedia, the free encyclopedia
  (Redirected from Wikipedia:VPM)
Jump to: navigation, search
  Policy   Technical   Proposals   Idea lab   Miscellaneous  
The miscellaneous section of the village pump is used to post messages that do not fit into any other category. Please post on the policy, technical, or proposals pages, or – for assistance – at the help desk, rather than here, if at all appropriate. For general knowledge questions, please use the reference desk.
« Older discussions, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54
Centralized discussion
Proposals: policy other Discussions Ideas

For a listing of ongoing discussions, see the dashboard.

Protected edit requests[edit]

I've noticed that, with many protected edit requests, editors brush them off with a request to be more specific, even if it's reasonably clear what the person wants. It seems to me like an easy way out, but if an editor can't be bothered spending time on the request, why answer it at all? Is there a better way of dealing with these requests?--Jack Upland (talk) 00:28, 18 November 2016 (UTC)

WP:SOFIXIT. If you come across a request that you can act on, act on it, even if someone previously has declined to. No one will stop you from making Wikipedia better. --Jayron32 01:34, 18 November 2016 (UTC)
Well, that's nice when it works, but it's not helpful if you can't make the edit or if you saw the request after someone else already brushed them off. OTOH, stale requests sitting around for weeks isn't good, either. It's not easy. WhatamIdoing (talk) 23:30, 22 November 2016 (UTC)
I think one problem is that some editors think they're doing everyone a favour dismissing these pesky edit requests. I would rather see a stale request than one summarily dismissed, especially one dismissed for a spurious or inadequate reason. Wikipedia isn't perfect, and it won't be made better by dismissing feedback. Alternatively, rather than dismissing feedback, it would be better for protected pages not to allow edit requests at all. What is the point of asking for feedback if the feedback is bureaucratically dismissed??? Do editors just like frustrating other people?--Jack Upland (talk) 11:00, 24 November 2016 (UTC)
No editor should be faulted for expecting requesters to follow the instructions clearly outlined at Wikipedia:Edit requests. They essentially say that the requester should do all of the editor work except the actual edit operation, including all writing, placement, and identification of any required references (I might be persuaded to format the necessary CS1 citations given links, but that's as far as I'm going). If the instructions are inappropriate or unhelpful, work to change them (I would oppose). They should be seen as representing current community consensus on the matter, which apparently is that edit requests are for IPs who know how to edit Wikipedia.
Many edit requests should be simple discussion threads instead; use the process as it was designed to be used. There would be nothing wrong with the responder suggesting a discussion thread instead, as they close the edit request as "not done". For that matter, the responder could convert the edit request to a discussion thread with a change of heading and removal of the template, although the requester might have difficulty finding it in that case. In the case of IP requesters, IPs can't be pinged, so the responder would have to post on their user talk page and hope they read it there. ―Mandruss  11:16, 24 November 2016 (UTC)
While it might follow the "instructions", it is clear that this is a faulty mechanism, which is worse than having nothing at all. Nothing at all seems the best option at the moment.--Jack Upland (talk) 09:21, 25 November 2016 (UTC)
I don't see what's faulty. As far as I can tell it works as well as it could for its intended purpose, which is to allow IP editors to edit semi-protected articles, if only by proxy. It is not meant to be a way for readers to request changes to articles, that can be done in a discussion thread. The only issue I see is the case of long-term semi-protection at an article with very low activity, so low that no one is likely to see the discussion thread and respond to it. My take on that is that (1) no solution is perfect, and (2) the reader is free to register an account and try their hand at Wikipedia editing. It's accepted that registration has its benefits. ―Mandruss  11:03, 25 November 2016 (UTC)
Registering an account doesn't help at all if you don't actually know how to make the change, and it's not enough if the page requires an admin or template editor. I believe that I once had an edit request declined on a template that was fully protected, on the grounds that I didn't provide a cut-and-paste copy of the code – which I didn't, because I didn't know how to write it. So your solution is, at best, incomplete. IMO it would have made a lot more sense to leave the request open until a knowledgeable and interested admin or template editor could have handled it. WhatamIdoing (talk) 19:19, 28 November 2016 (UTC)
That's exactly the point I was making. Some editors simply decline requests for the weakest of reasons, because that is the path of least resistance. Sure, you can heap the blame on the person who makes the request for imperfectly following procedures they are unlikely to understand. Or you can put the responsibility onto other editors who could follow up the request after it has been declined. Or you could put blame where it lies: on the mindless bureaucrats who apparently think they have completed a "job" or made Wikipedia a better place simply by rejecting a suggestion to improve the encyclopedia.--Jack Upland (talk) 12:31, 30 November 2016 (UTC)

Need opinions on canvassing vs. notices[edit]

I spend almost all my time on-wiki working on featured articles, either writing content or reviewing candidates. There's a MoS discussion, here, that I'd like to post a note about at WT:FAC because a lot of content writers would see it there, and I think it would be good to get more input on this (and other) MoS discussions from experienced content writers. A previous note of mine at WT:FAC on a related MoS discussion was considered by at least one editor, SMcCandlish, to be canvassing, so I asked him how I could leave a neutrally worded notice to let editors at FAC know of the discussion, without running afoul of WP:CANVAS. His response is that any such notice would be canvassing no matter how I worded it: "Quotation formatting is not an intrinsically FA-related subject, so it would be taken as canvassing of a special interest group regardless, by various participants". This doesn't seem to me to be in line with the intent of WP:CANVAS, but I don't want to unilaterally annoy a MoS regular and get into a fight over this. Can I get opinions here on whether it's OK to post the kind of notice I would like to post? Or if in fact SMcCandlish is right that no such notice is possible within the rules? Mike Christie (talk - contribs - library) 13:21, 19 November 2016 (UTC)

Don't be concerned with annoying me in particular. The constant personalized character assassination against me and other MoS regulars by the WP:FAC clique, and the general "screw the MoS, let's start our own anti-MoS" campaigning at WT:FAC, and farcical scapegoating by them of MoS people for things that have nothing at all to do with MoS at all, like infobox disputes (MoS is entirely neutral on infoboxes) has pretty much driven me to the verge of quitting this project. I basically don't respond to anything I don't get an e-mail about, and I may even turn that off. The reason to not try to canvass FAC people to an MoS discussion that has nothing in particular to do with FAC is the same reason to not canvass any other special interest to your preferred side of any discussion on WP. The last time that happened (and at least 3 or 4 people flagged it for canvassing, with me being the last one to do so), about two months ago, the result was predictably a big histrionic, demonizing flamewar from which no consensus resulted on anything, because it was not about the merits of the discussion, but about two camps of conflicting personalities. I repeat what I already said in earlier discussion with you: Doing the same thing again and expecting different results isn't a rational or useful approach. People who actually care about the discussion on its own merits already know about it or will through normal channels like WP:FRS and individual discussion. A particular enclave of anti-MoS pitchfork bearers do not need to recruited again to light yet another witch-burning pyre.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  02:42, 20 November 2016 (UTC)
My reading of WP:APPNOTE suggests that it would be inappropriate to post a message regarding threaded discussions at WT:FAC. FAC people are not 'directly related to the topic under discussion', and from SMcC's response, seem very much more like they might be 'selected on the basis of their opinions'. --Tagishsimon (talk) 03:08, 20 November 2016 (UTC)
It's going to be rare, if ever, that a MoS discussion is going to relate to FAs more than any other area of the encyclopedia. However, FA writers and reviewers are (we hope) experts on how to write and lay out high quality articles. A MoS discussion on how to format a set index article is clearly not of particular interest to FA writers, but a discussion about, say, the structure of article leads is one where they could be expected to have useful opinions. I suspect many at FAC don't watch the MoS pages because there's a lot of tedious (but useful) work that goes on there that doesn't interest them, but I think the input of anyone interested from that group could be helpful. It's not that plenty of good content writers don't already watch MoS pages, but more input tends to lead to longer-lasting consensus. In this particular case I don't plan to post at WT:FAC unless there's a clear consensus here that it would be OK to do so, but I would like to say that I have no idea if anyone who might see such a post would care, or which way they would !vote. I haven't !voted myself and still haven't decided on the issue. Re SMcCandlish's comments about anti-MoS pitchfork bearers; he's right that there are strong feelings and harsh words but that's not a good reason to avoid discussion. Mike Christie (talk - contribs - library) 11:40, 20 November 2016 (UTC)
None of which alters the price of bread w.r.t. WP:APPNOTE. --Tagishsimon (talk) 12:42, 20 November 2016 (UTC)
APPNOTE says the intent must be "to improve the quality of the discussion by broadening participation to more fully achieve consensus", which is the case here; and that notifications are inappropriate if the intention is "influencing the outcome of a discussion in a particular way", which is not the case here. I acknowledge that the phrase you quote, "directly related to the topic under discussion", allows the argument that FAC is not a valid place to leave a notification, but given that MoS issues are mostly about form and not content, wouldn't that reading imply one could almost never notify anyone about MoS discussions? I think that leaves the encyclopedia worse off. We should be trying to get more inclusive on discussions that impact every editor, as the MoS does. Mike Christie (talk - contribs - library) 13:33, 20 November 2016 (UTC)
I have no problem including anyone who will be there to improve MoS rather than undermine it. Meta debates about MoS belong in a separate venue from MoS talk pages, such as, I guess, WP:VPP or WP:VPR. MoS talk pages are for discussion about how to improve MoS, just as article talk pages are about how to improve the respective articles. On MoS talk pages, those meta discussions are equivalent to WP:NOTFORUM violations and should be prohibited. Absent such prohibition, I don't think we need to go out of our way to invite such violations, although we can't prevent people from watching and violating. The bottom line question for me, then, is whether FAC people in fact have tended to engage in that kind of discussion on MoS talk pages, and I don't know the answer since I have no experience in that area. I haven't known McCandlish to distort or misrepresent such things, much. ―Mandruss  19:48, 20 November 2016 (UTC)
Mandruss, if I understand you correctly you're talking about SMcCandlish's comments about some users being anti-MoS. Do you have an opinion about the original question? Is it OK to post notices about MoS discussions to WT:FAC, and by extension to other talk pages that aren't focused on topics (e.g. WT:GAN or WT:PR)? Mike Christie (talk - contribs - library) 16:03, 21 November 2016 (UTC)
@Mike Christie: Perhaps I'm just thick, but I thought his comments were relevant to the original question. If FAC has shown a pattern of bringing MoS opposition to MoS talk pages, my opinion is no. That is not per p&g, but it appears that p&g does not give a clear answer so I'm left to my judgment. Disclaimer: I don't claim to be an expert in this area, but I think I have a handle on the WP political environment. ―Mandruss  17:03, 21 November 2016 (UTC)
OK, now I understand the point you're making. But even if it were true that FAC regulars had such a pattern, surely that's not a reason not to notify them? After all, a proposal at WT:MOS to, say, severely limit the size of sports-related navboxes would be almost certain to attract opposition from the affected Wikiprojects, but that wouldn't be a reason not to notify them. Would someone notifying a sports Wikiproject be canvassing? Mike Christie (talk - contribs - library) 01:21, 22 November 2016 (UTC)
You really don't want to drop this stick, do you, Mike? In your scenario, the sports wikiproject would be 'directly related to the topic under discussion' and so it would, per WP:APPNOTE, be appropriate to notify them. --Tagishsimon (talk) 01:31, 22 November 2016 (UTC)
OK, I'll drop it. I'm surprised by the response, and I wish more people had expressed an opinion, but we can leave it at that. Mike Christie (talk - contribs - library) 01:38, 22 November 2016 (UTC)
I'm kind of underwhelmed by the reasons given here. AFAICT they are:
  • FAC regulars frequently disagree with MOS regulars in style matters (debatable, especially since editors such as Dank, SlimVirgin, and Tony1 have historically been among the most prolific contributors to both pages.)
  • FAC regulars don't have sufficient respect for the MOS (e.g., the "anti-MOS" comments).
  • FAC regulars aren't a subject area, so you can't invite them to anything at all.
    • This is claimed even though changes to the MOS affect them far more than anyone else. They may have to decline candidates and send previously approved articles through FAR as a result of this discussion, but they should not be told that the discussion is happening.
    • In fact, the underlying claim is that no group of people (except perhaps WP:WikiProject Manual of Style) can be invited to any discussion about general style matters (e.g., the best way to handle quotations), because no "general" style matter could be "specific" to any group of editors.
    • Mike, a more appropriate example would have been a proposal at WT:MOS to severely limit the size of all the navboxes, but it happens that the sports navboxes are the ones most affected (because nearly all the others are smaller). Can you notify the sports-related WikiProjects, on the grounds that their work is affected, or must you leave them ignorant of this discussion on the grounds that it's not "specific" to them?
  • FAC shouldn't be informed about this RFC, because if they Truly Cared™, then they'd already be watching the RFC pages or the main MOS page (or all the MOS pages), or would have just known somehow or another.
  • Multiple FAC regulars participated in a previous discussion on an identical(!) topic, but we don't want them back, so don't tell them that we're having this discussion again. It doesn't matter if WP:APPNOTE (heretofore only quoted to claim that the entire guideline militates against letting them know about this discussion) directly says that "Editors who have participated in previous discussions on the same topic (or closely related topics)" can be/should be invited them to this discussion; we don't want them and their disagreeable opinions.
I'm not impressed with these reasons. FAC people are disproportionately affected by changes to the MOS. It is therefore reasonable for them to be informed about what's going on. In fact, I wouldn't consider it unreasonable for some FAC regular to post a weekly update on changes to and discussions about the MOS and all the style-related RFCs so that group knows what's going on. I put this in the same category as transcluding {{cent}} on a WikiProject page (which FAC might also want to do): if a group wants to know what's going on, then there's no rule against them organizing themselves to find out what interests them. And if their "organization" looks like "Mike (or the FAC coordinators, or whoever) regularly tell us about anything that might affect FAs", then that's okay. WhatamIdoing (talk) 22:18, 22 November 2016 (UTC)
To whatever extent your comments refer to mine, mine are quite simple. 1. Anti-MoS sentiments in discussions about improving MoS are off topic, wrong venue, and disruptive. This is a well-known problem. 2. Repeated violators needn't be accommodated. 3. I don't know whether the group in question are repeated violators, but that is the only question in my mind. McC says they are, if I read him correctly. That could be proven to my satisfaction with ten or so diffs. 4. I welcome constructive participation in any discussion, anywhere, on any topic. ―Mandruss  22:51, 22 November 2016 (UTC)
I think that you may have developed an incomplete picture of the relationship between FAC and MOS people. FAC editors follow and enforce the MOS more completely and precisely than any other editors. Multiple FAC regulars are regular, long-time contributors to the MOS. I doubt you would find anyone who regularly engages in the FAC process who would claim to be "anti-MOS" – "anti-stupid-stuff-in-MOS", sure (I hope that sentiment is widespread), but not actually "anti-MOS".
What could easily be demonstrated is that some (not all, probably not even most) FAC editors have disagreed with SMcCandlish at some point over the years on various style guidelines. I've both agreed and disagreed with him myself over the years. But "disagreeing with one person who likes to hang out at WT:MOS", even if it happens consistently, is not actually the same thing as being "anti-MOS".
I am making some assumptions; I'm assuming, for example, that Mike intends to post a note at WT:FAC that is nearly identical to the one that SMcCandlish posted about this same subject at WT:NPOV back in August (and at MOS:ICON, and at IMAGES, and at NOR – I think I'll stop looking now), except instead of saying that, in his opinion, the size of quotation marks was a matter of DUE weight or that it was like an image, it would say something about a change possibly triggering the need to re-check some old FAs. But I'm having a very hard time understanding why such notices would actually be problematic for anyone (except possibly someone who thinks that he'll "lose" an RFC if more experienced editors find out about it).
(Oh, and if you're interested: I'm anti-pull quote myself. If it were up to me, all of those templates would have been deleted long ago and replaced with plain old blockquote tags.) WhatamIdoing (talk) 23:27, 22 November 2016 (UTC)
I don't know how many differemt ways I can say it, or how I can say it any more clearly. I know nothing about FAC-MoS, I have made that fact crystal clear, but I read McC's comments as saying they were a part of the problem I describe. My comments were completely contingent on the accuracy of his comments and my interpretation of them, and I went out of my way to underscore the word If to make sure I wasn't misunderstood. I guess I should have blown it up to 200% and bolded it too, maybe put arrows and stars around it. Can we make text blink, or beep? I commented that I have not known McC to distort such things. ―Mandruss  23:30, 22 November 2016 (UTC)
@WhatamIdoing: Re: '"[D]isagreeing with one person who likes to hang out at WT:MOS", even if it happens consistently, is not actually the same thing as being "anti-MOS".' — That would be true, but a red herring. I'm not talking about people disagreeing with me, I'm talking about at least two distinct proposals at WT:FAC to fork their own style guide against MoS (what could be more anti-MoS that writing an actual Anti-MoS?); demonizing of all the MoS regulars as a group/class by multiple FAC regulars who back each other up in erecting false dichotomies and will brook no disagreement; threats by others in that scene to resign WP editing over not getting their way when wanting to ignore MoS but meeting resistance and/or over those particular editors' continual, escalating fights against those they mischaracterize as MoS editors (who are in fact more often pro-infobox people, infoboxes not being an MoS topic at all); and other patterns of collective and irrational "us versus them", FAC-against-MoS territorial ritualized combat antics, that closely mirror (with considerable individual editorial overlap) similar anti-MoS torch-waving at WT:CITE and (a while back) WT:AT. If I had never even been born, all of this would be continuing exactly as it is now, other than some individual besides me would be the most frequently scapegoated target (probably whoever is next in the stats as the most frequent WP:MOS or WT:MOS editor, or perhaps just whichever one spokes up and didn't still still for being treated like a second-class member of the project by those people).

As for the '"lose" an RfC' comment: just see WP:WINNING, WP:NOTAVOTE, WP:NOT#DEMOCRACY, WP:RFC, etc. The purpose of RfCs is to get input from people who care and have something pertinent to say, after they actually understand whatever is under discussion, with an eye to what is best for the project and its readers; not to rally allies to a cause, to swing a vote based on argument to emotion and reactionary territorialism or proprietary sentiment, which is usually what happens when one pointedly canvasses a wikiproject or other editorial cluster with a known, clearly demonstrated bias with regard to the topic under discussion, especially a bias based on their personal level of control/power over particular pages. Fortunately, this is basically moot, since the discussion in question has archived without resolution. I suggest just forgetting about it. If it re-arises after considerable time has passed, I would trust that everyone's cooled heads will prevail.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  11:53, 2 December 2016 (UTC)

  • It's probably a matter of politeness for someone at MOS talk to ping FAC talk if an important topic is under way. Tony (talk) 08:47, 23 November 2016 (UTC)
  • Mike, yes, it's important to let WT:FAC know about proposals likely to affect them. I would suggest WT:GAN and WT:PR too. SarahSV (talk) 00:49, 28 November 2016 (UTC)
  • When I added the word "directly" to wp:canvass, it was intended to prevent someone from posting a notice to every WikiProject talk page in wikipedia. It wasn't intended to prevent notification of discussion at a collaboration talk page. I've clarified the text. - jc37 23:09, 1 December 2016 (UTC)

Prepare Yourselves[edit]

Absolutely nothing useful or interesting to see here ^demon[omg plz] 02:27, 1 December 2016 (UTC)

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

Everyone get ready. A Wikipedia raid is happening Thursday, December 8th by feminists and the BBC. Constantly check your favorite articles; make sure they stay accurate. I'm not saying that feminism is bad or to revert all changes by feminists, I'm just saying that we'll be seeing a large user influx, which could bring many false edits. AA Quantum (talk) 22:34, 29 November 2016 (UTC)

What makes you think that the odd website ageofshitlords.com is a credible source for any claim that such a conspiracy is afoot? -- Hoary (talk) 22:50, 29 November 2016 (UTC)
Come on now, I was just about to remove this under WP:DFTT. --Majora (talk) 22:51, 29 November 2016 (UTC)
You wouldn't meet any resistance from me, Majora. The website does seem to be a mere pile of what we may be in, or may soon enter, the age of. -- Hoary (talk) 00:05, 30 November 2016 (UTC)
A raid by feminist activists would not be a "large user influx".--Jack Upland (talk) 00:12, 30 November 2016 (UTC)
I, for one, welcome our new feminist overladies. AA Quantum refers to the forthcoming BBC 100 Women editathon, to which all are invited. There is a BBC 100 Women redlist up & running, courtesy of the subversives who hang out at WikiProject Women in Red. When will it end, you ask? Well, probably when the ratio of male to female biographies is better than the current 1,421,449 to 237,676, or 83.28% to 16.72% - see WHGI. --Tagishsimon (talk) 02:01, 30 November 2016 (UTC)
  • Let's see... the last two articles OP edited were Ku Klux Klan and Swastika. Now, those edits are innocuous enough by themselves, but combined with panicking over women being out of the kitchen? And citing an alt-right blog as supposed justification for said hissy fit? Ian.thomson (talk) 02:23, 30 November 2016 (UTC)

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

The SVG Debate: Inkscape or Not[edit]

The template: Template:Noinkscape doesn't give any reasoning for why the otherwise wikipedia-endorsed Inkscape is worse than text-editors. It also doesn't explain how editing Inkscape inhibits future use of text-editors. Can anyone help me understand and solve this issue? I imagine that adapting Inkscape could fix this problem. @Prccy27, Brythones, and Gage: Could people who worked on the 2016 Electoral College map weigh in on this? Thanks! Houdinipeter (talk) 23:38, 29 November 2016 (UTC)

@Sameboat: Do you want to comment on the purpose of {{Noinkscape}} which you created? At any rate, the template appears to only be used at File:SacramentoKings.svg. Johnuniq (talk) 03:34, 30 November 2016 (UTC)
The Commons version of the template is in rather wider use.
I expect it's mostly an objection to the bloat Inkscape adds if you save as an "Inkscape SVG" instead of "Plain SVG". In the case of File:SacramentoKings.svg, it doubled the svg's size. —Cryptic 03:47, 30 November 2016 (UTC)
That makes sense, thanks. I have uploaded a couple of SVGs created using Inkscape and I wondered which of the options should be used—I think I used "Plain SVG". Johnuniq (talk) 04:00, 30 November 2016 (UTC)
I have loads of reasons besides the file size exported from Inkscape being substantially larger and polluted by useless metadata and attributes which define the default value (think of it adding <span style="color:#000000;font-weight:normal;font-size:normal;font-family:Liberation Sans,Arial,Helvetica,sans-serif">Text here</span> for every single section of text, Inkscape is doing something worse than that). For SacramentoKings.svg specifically, Inkscape's default curve tool only supports editing with cubic Bézier curve command. If Inkscape detects other curve commands, namely quadratic Bézier curve and elliptical arc curve, upon editing the path, it will instantly convert them to cubic Bézier curve command. The issue with cubic Bézier curve command is that adjusting its control points for creating a perfect circular arc is extremely cumbersome for all the irrational decimals, even if the angles of the entry and exit points are pointing to the cardinal directions. For example, if I want to draw a circular arc from (0,0) to (100,100) clockwise, turning 90 degree and 100px radius, this is what the elliptical arc curve command will look like: A 100,100 0 0,1 100,100. And this is what cubic Bézier curve command will end up after conversion by Inkscape: C 55.228475,0 100,44.771525 100,100. -- Sameboat - 同舟 (talk · contri.) 02:54, 1 December 2016 (UTC)
Additionally, "no Inkscape" also includes Inkscape's "Plain SVG" format which still contains all the default-value-attribute craps and polluted curve commands issue. -- Sameboat - 同舟 (talk · contri.) 04:21, 30 November 2016 (UTC)
Any suggestions on alternatives? Inkscape is pretty nice to use. Johnuniq (talk) 04:50, 30 November 2016 (UTC)
Just learn writing SVG/XML codes in Notepad. I have absolutely no objection if you're drawing something like this, but for most vector diagrams, text editor is my only answer. -- Sameboat - 同舟 (talk · contri.) 05:01, 30 November 2016 (UTC)
Notepad!! My editor can do this in a single search-and-replace. Johnuniq (talk) 05:09, 30 November 2016 (UTC)
I had no trouble making all these topological diagrams in Notepad++. -- Sameboat - 同舟 (talk · contri.) 05:17, 30 November 2016 (UTC)
I could have done the same in VisualEditor with 2 clicks... --Izno (talk) 13:34, 30 November 2016 (UTC)
Having used Inkscape and other vector programs, I do agree that Inkscape does like to "take over" a saved SVG into its own format since it has a lot of non-standard SVG extensions (good for creation, bad for revisions). I think we should be clear in the language of this template that should explain this issue and to add that it should only be applied to SVG images that were created outside of Inkscape (such that Inkscape editing doesn't screw them up). It should not be taken that we do not accept Inkscape-made SVGs, just that non-IS SVGs should not be edited by IS. (That said, I haven't tested enough to know if a program like Adobe Illustrator has similar "take over" actions on the SVGs it produces) --MASEM (t) 15:37, 30 November 2016 (UTC)
@Masem: The code neatness of SVG exported from Ai is slightly better than Inkscape, but there can still be many issues with these SVG files if the original work wasn't really prepared with SVG specification in mind. Commons:Help:Illustrator details the issues as much as possible. To me personally, the worst offender has to be intentionally not translating text-align setting of "center" and "right" to text-anchor property ("middle" and "end" respectively) but replacing with translating the text position which almost guarantees poorly positioned text after uploaded to Wikimedia. Because of the Creative Cloud barricade, that means most of our Ai contributors still stick with the older versions of the vector application and they will never ever receive any update if Adobe finally has decided to improve its support for SVG. In other words, they will be highly tempted to convert all text to outlines before exporting SVG just for neat presentation on Wikimedia but hell for revision and localization. -- Sameboat - 同舟 (talk · contri.) 01:10, 1 December 2016 (UTC)
Inkscape is the only free general-purpose SVG editor listed at Wikipedia:Graphics Lab. If the general SVG output from Inkscape is not suitable, then Wikipedia/Wikimedia/Commons should describe somewhere (perhaps Wikipedia:Graphics Lab/Resources/SVG) which options should be used to save/export the right kind of SVG. If InkScape is not currently capable of producing the features (or lack of customisations) that we require/would like, then Wikipedia should make a list of what changes we would like, then have someone file a series of bug report/feature requests to InkScape, perhaps with a "Save as Wikimedia-friendly" checkbox. Having InkScape explicitly support Wikipedia and be recommended by Wikipedia should benefit both projects. --Scott Davis Talk 03:42, 3 December 2016 (UTC)
@ScottDavis: The purpose of placing this "no inkscape" banner in some of our SVG files is that we don't rule out Inkscape (actually including all other vector graphic editors/VGE like Adobe Illustrator) but rather to tell our contributors which SVG file can be touched by VGE and which shouldn't be. Generally if an SVG file starts out with text editor, it should not be touched by any VGE at all. There is also the free online SVG optimizer to clean up all the unnecessary metadata and floating points which are generated by VGE so Inkscape contributors are still welcomed but they need to be prepared that once their works are uploaded to Wikimedia, their works will be "optimized" by other contributors at any time. This optimization is usually done for the purpose of allowing easier access in text editor by other contributors when the SVG image is going to be heavily updated by many different users such as this one. If the SVG image is created in VGE and the uploader is the sole contributor of that image, then the image can retain its original state unless it hits the rendering limitation of libRSVG. -- Sameboat - 同舟 (talk · contri.) 04:22, 6 December 2016 (UTC)

Location-based pages with separate more detailed pages on the same subjects[edit]

I hope this is the right place to ask why location based pages (towns, counties etc.) have sections on, for example, "History of Wikiville", "Geography of Wikiville", "Sport of Wikiville" but also separate pages in the encyclopedia on exactly the same subjects?

If you are - as I am - trying to pull one of these sites into shape, the double-page just creates extra work, with a lot of sections having to be edited twice, and decisions made as to what goes in the summary section and what goes on the fuller page.

However the real downside is that, over time, individual editors find one page or the other, and make additions, corrections or deletions without editing the other page. So we end up with conflicting information - sometimes quite factual stuff like figures or dates - that conflict between the two pages.

Surely it would be better to decide, either a) we have a full page on Wikiville with all the detailed information on it (if people don't want to read the history or whatever, they can always minimise the section) or, b) we have all the gripping event-by-event history of Wikiville set out on one page, with a simple link to it from the main Wikiville page? User:IanB2 1 December 2016

Having dug around the site a little, I think this issue will affect a very large number of sites indeed. Nevertheless the way the site is currently set up makes life a lot more difficult for editors, and potentially confusing for users.

See Wikipedia:Summary style. Large articles are broken out into smaller subject based articles when they become to big to manage. The way it is SUPPOSED to work is that the parent article still should have a paragraph or two of overview material, and the child articles have more exhaustive detail. Where it doesn't happen is because people haven't yet made it work right. --Jayron32 12:51, 1 December 2016 (UTC)

Hi - thanks for the quick reply. I can see the logic for a topical page, where you don't want all the minutiae of a detailed sub-subject set out on the main page. But my point is that for subjects like "History of Wikiville" - which is essentially a series of discrete events set out over the full span of human history - the logic doesn't really work very well in practice? User:IanB2 1 December 2016

I don't see a problem with it for an article on the history of a place. Summary style is really there to limit article size; an article on, e.g., New Orleans that included a fully detailed history of the city would be unwieldy. I think a summary of that history in the main article seems like a reasonable approach; what problem do you see with it? Mike Christie (talk - contribs - library) 13:41, 1 December 2016 (UTC)

I think the problems are: a) extra work for someone trying to pull a location page into shape, having to double-edit everything, b) individual editors add or change things to one page or the other, but not both, so the two pages grow apart, and occasionally conflict on basic factual details, c) a history - essentially a sequence of discrete events - is not always easy to summarise User:IanB2 1 December 2016

"Wikiville#History" should more or less match the summary of "History of Wikiville", with some extra phrases. --NaBUru38 (talk) 21:34, 3 December 2016 (UTC)

Has using Wikidata descriptions as page subtitles in mobile view been discussed here?[edit]

It seems that this new feature (see phab:T135433) will be "tested" on the French WP during one month starting next Monday, and kept if there is no "major objection". Will there be such a thing here on the English WP or has it been discussed somewhere? The answer could help the French WP know what to do about this "test". Oliv0 (talk) 13:52, 2 December 2016 (UTC)

I thought something like this was already happening? Or perhaps it was just the app. Sam Walton (talk) 15:46, 2 December 2016 (UTC)
This was mentioned in the Technical Village Pump, but it only pointed to a page on mediawikiwiki. Jo-Jo Eumerus (talk, contributions) 16:16, 2 December 2016 (UTC)
Mobile search has used Wikidata descriptions for the English Wikipedia since October 2015. There were no comments to the announcement at Wikipedia:Village pump (technical)/Archive 141#Wikidata descriptions. They are also used for the search box at https://www.wikipedia.org. PrimeHunter (talk) 21:51, 2 December 2016 (UTC)
This new feature is not in the search but is under the title of the article using d:WD:description as a page subtitle. I found the place where it was mentioned in the Technical Village Pump: WP:Village pump (technical)/Archive 148#.5BIdea.5D Wikidata descriptions to help disambiguate article topic on mobile web (with only very little discussion), pointing to mw:Reading/web/Projects/Wikidata Descriptions (with some discussion on the talk page 3 months ago). Oliv0 (talk) 07:05, 3 December 2016 (UTC)
Thanks Oliv0, no this hasn't been discussed here yet, but now I see it is being discussed already :). The feature has been running on all language versions, on stable, except for a very few languages. It could be activated for English Wikipedia soon, as well. Thanks for starting the conversation --Melamrawy (WMF) (talk) 02:50, 5 December 2016 (UTC)

Is Wikidata d:Q42 not an external link?[edit]

I am developing infoboxes, using Wikidata. For carbon monoxide, I see

My question is: why is Wikidata presented as an internal link? Is that a web-design choice? To me (and probably most Readers), d:Wikidata is an external site. Can someone clarify? -DePiep (talk) 21:15, 2 December 2016 (UTC)

Wikidata is another wikimedia property, like wikimedia commons, and so can be presented as an internal link. And I'd expect it to be shown as an internal, not an external. YMMV. --Tagishsimon (talk) 21:25, 2 December 2016 (UTC)
Yes, wikilinks are the usual method for Wikimedia sites. See Help:Link#Interwiki links. "Internal link" usually means to the same wiki. Interwiki links have a slightly different color (see Help:Link color) and are neither called internal nor external. PrimeHunter (talk) 21:41, 2 December 2016 (UTC)
I can get this. Now, does King Reader wants it this way too? (not to cause trouble, but I'm interested it the web-design aspects. Readers' perspective). -DePiep (talk) 22:01, 2 December 2016 (UTC)
I doubt there have been any reader surveys and most readers probably don't know what Wikidata is so the result would depend strongly on how the question is formulated. We have always used interwiki links for Wikimedia projects, e.g. in {{Sister project links}} like at Carbon#External links. It's a feature of the Mediawiki software that links made with url's get an external link icon by default (plainlink can suppress it), and interwiki links don't. I like it that way. PrimeHunter (talk) 22:23, 2 December 2016 (UTC)
There has been some research on readers (e.g., m:New Readers), but I don't think that any of it specifically addressed this question. Whatamidoing (WMF) (talk) 23:39, 4 December 2016 (UTC)
Thanks Y'all. -DePiep (talk) 08:08, 5 December 2016 (UTC)
Great stuff, thanks. -DePiep (talk) 00:41, 6 December 2016 (UTC)

RM problem[edit]

For starters, I would like to say that I do apologize if this is the wrong place to put this.

Now, I have twice relisted a move discussion at Talk:Aleksandar Jovanović (footballer, born December 1992). However, shortly after I relisted a second time, a user moved the page, but didn't close the discussion. Now another user has commented and requested a new title, even though the RM is technically "over". I am unsure of what to do; can anyone be of assistance (also note that I am not involved with the article except for the relistings). JudgeRM (talk to me) 16:34, 4 December 2016 (UTC)

Can we simply close it right now (after the deed), and move on? After all the RM was open for weeks without contests. Otherwise, reading Wikipedia:Move review gave me some hints on current options in the process. -DePiep (talk) 08:32, 5 December 2016 (UTC)