Policy | Technical | Proposals | Idea lab | Miscellaneous |
New ideas and proposals are discussed here. Before submitting:
|
« Older discussions, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130 |
Centralized discussion | |||
---|---|---|---|
Proposals: policy | other | Discussions | Ideas |
Note: inactive discussions, closed or not, should be archived.
|
|||
Contents
- 1 banner invite for more info
- 2 New Village Pump page?
- 3 Towards a standard biography footer
- 4 Close down Possibly Unfree Files
- 5 Proposal: Enable Hovercards by default
- 6 We should not accept pictures with pixelated people's faces
- 7 Suggested languages template
- 8 Consensus Talk Index (CTI) idea
- 9 RFC: Corrections on Main Page?
- 10 Displaying pronunciatiin of a word in regional language
- 11 2 proposals
- 12 "Research help" proposal
- 13 Notice: RfC on Citation coding style
- 14 Banter
banner invite for more info
So this must be a poll?
Going through the works of famous people I noticed that most of them (who are alive)don't seem to contribute to their own pages. (eg.: date of birth, portraits,etc.). So I propose a banner invite. For example: banner: "The following purpose is only for encyclopaedic purposes and is subject to it as such. We request 'famous' (link: WP: noteworthy) people to donate the portraits of famous people or themselves, and pictures, recordings, etc. of their works to wikimedia, and also to help editors edit their page. They may even give a vocal reading of their own names or perhaps the whole article (if they wish to). The invitation extends to the people who helped them get there to help contribute to their pages and articles related to them." 117.207.234.48 (talk) 08:08, 26 March 2016 (UTC)
New Village Pump page?
I've been thinking for a while that it might be good to have a Village Pump page specifically to facilitate WMF-Community engagement. In particular I was just collaborating with one of the WMF teams drafting an RFC to get feedback from us on one of the projects they're working on. The only place to post it would be Village pump (miscellaneous). Meh. It's unclear how big the discussion would become, and I think it would be beneficial if this sort of thing were to become a common practice. Alsee (talk) 23:32, 2 March 2016 (UTC)
- There is definitely a perceived need for better WMF-Community engagement. Coupled with the lack of a proper forum, it seems to be channeled to Jimbo's talk page a lot. I hope there is a way to make engagement constructive; lately I've been disappointed by this. If there is a way to make the new Village Pump something that encourages constructive engagement instead of Foundation bashing, then I welcome it. One thing to consider though is that WMF works on a variety of areas (technical, legal, "vision" ... in short there is an inherent "miscellaneous" aspect to it). – Finnusertop (talk ⋅ contribs) 11:55, 3 March 2016 (UTC)
- Wouldn't there be a risk of that becoming a page for endless rants? How do you see it being useful? Praemonitus (talk) —Preceding undated comment added 20:04, 3 March 2016 (UTC)
- Praemonitus, I understand the concern about "rants". I've been one of the ranters myself. But I'm seeing real positive changes. Gather was agreeably uninstalled after our RFC requesting it. I just helped the WMF draft a request-for-feedback that is basically ready to go, where one of the opening lines is The WMF... does not want to push it on Wikis that do not want it. It also contains says they made a mistake not consulting us earlier. The project lead is very concerned to avoid any perception that they are "doubling down" to push something out. I'm trying to help the WMF figure out how to talk to us and engage us, the way we want. Alsee (talk) 08:03, 4 March 2016 (UTC)
- I just realized I didn't really address How do you see it being useful? I see the WMF posting new project ideas there, so we can comment before they start building stuff. They can post requests for feedback on things, and most significantly ask us if we want feature-X built or enabled. The WMF ran some feature-enablement RFCs semi-recently regarding Visual Editor on the proposals page. That would probably shift to the WMF page. And yeah, things like the recent RFC to disable Gather would probably move to the WMF page. To be honest I'm not fully sure how it would evolve, but I think it's a needed page. I believe it will help us build better WMF-Community relations. Alsee (talk) 08:16, 4 March 2016 (UTC)
- @Alsee: thank you for your contributions to the improvement of the communication between the Wikimedia Foundation and the communities. In the case of this proposal, I think the intention is correct, but the implementation might not be the best one. One example: what happens when a dozen more wikis decide to follow your steps, creating their own WMF Village Pumps? Can we stop them? Can we satisfy their expectations? Most probably not.
- The WMF plan is to have a product development process open to the participation of all communities. Resolving the communication equation is definitely not simple, but the solution probably needs to start with a centralized location with possibilities for translation and equipped with subscriptions to very specific news (e.g. "New project ideas", "Requests for design review", "Feedback on deployment plans"...), and cross-wiki notifications. This way any individual could subscribe to the types of review corresponding to their interests and skills, and they would receive the updates in their own wikis. All the pieces needed for this process already exist. If you want to join the discussion about product development process and communication channels, please check phab:T124288.--Qgil-WMF (talk) 21:03, 8 March 2016 (UTC)
- Qgil-WMF, thanks for your work on Community engagement and your comment here. I fully share your concerns about scalability to multiple wikis. I have longer term ideas where the Communities may help solve those problems for you. This needs to be tackled from both ends. Your plans for a WMF-Central location is a necessary step, but I believe it is also necessary to have a local page where we can build local processes to assist you. The WMF was nearly overwhelmed trying to handle the Media Viewer Community Consultation, the process and outcome were widely viewed as completely illegitimate and literally making the situation worse. Expecting even larger numbers of people showing up in countless languages, on a WMF ruled wiki, won't work. It's non-scalable and it completely misses the community's fundamental objection: limiting engagement to individuals in bulk, without acknowledging or respecting Communities and consensus.
- Regarding the proposal here, this is a community proposal for a community page where the WMF would be welcome to post. We now have a mixed WMF-response. If the WMF does not find it desirable post here, that is absolutely fine. I still believe the community will find it useful for various purposes. I have some other community-projects in the works that I believe will be valuable, and Village_Pump_(WMF) is absolutely the place for it. Alsee (talk) 01:22, 9 March 2016 (UTC)
- Alsee, indeed, local communities need to have own spaces to organize their participation as stakeholders in the product development process. How you organize yourselves, that is up to you. No matter what, we will continue reaching out for feedback and involvement.
- I just want to stress that this proposal raises higher expectations. We cannot expect that a discussion in en.wiki (or any local project) will decide whether a new project idea moves into development or is parked. Wikimedia communities should have the power to promote or stop new software projects, but in a place and under a process that is common to all the communities. When it comes to local deployments sure, that is a discussion to be handled locally. However, note that even then we need a centralized process to communicate decisions to the teams in charge of the deployments.--Qgil-WMF (talk) 11:41, 9 March 2016 (UTC)
I have drafted the page, but not linked it into the main Village Pump structure. See Wikipedia:Village pump (WMF). Alsee (talk) 11:22, 4 March 2016 (UTC)
- Wikidata has a similar page at d:WD:Contact the development team, which is a hybrid VPT/VPWMF, for the most part. It's very useful, but that may be because Wikidata as a technical project has refined project coordination. That said, most of the big proposals from the technical team which may need social buyin end up at the singular Village pump there, which we don't have here. --Izno (talk) 13:03, 4 March 2016 (UTC)
- Support great idea, fills a big need here. --Tom (LT) (talk) 08:45, 5 March 2016 (UTC)
- Worth trying in principle, although if it did become non-constructive as a venue it would have to be closed down. What do any staffers think? BethNaught (talk) 11:32, 7 March 2016 (UTC)
-
- BethNaught: "What do any staffers think?" - I'm not making any claim about the WMF as a whole, or that there has been widespread WMF comment on it, but I have gotten a clear positive response. A project manager said "I am excited to see your new village pump area, too!" and a liaison used the thanks feature on one of my posts in this section. Assuming no sudden opposition shows up, I plan to make the page live as soon as the WMF greenlights their first official post there. Alsee (talk) 16:25, 7 March 2016 (UTC)
- No. It should go to a WMF site. It's a distraction from English Wikipedia, here. Alanscottwalker (talk) 21:13, 8 March 2016 (UTC)
- Putting efforts for engagement on another wiki, where fewer people will see it, is counterproductive. Moreover if the issue at hand is restricted to enwiki, discussing it here makes eminent sense. BethNaught (talk) 21:18, 8 March 2016 (UTC)
- No it does not. We have four pumps already, English Wikipedia does not need yet another forum to argue over. Put a notice on the relevant pump, if you want to draw attention to a discussion on a sister WMF wiki, people will see it. Alanscottwalker (talk) 22:34, 8 March 2016 (UTC)
- Putting efforts for engagement on another wiki, where fewer people will see it, is counterproductive. Moreover if the issue at hand is restricted to enwiki, discussing it here makes eminent sense. BethNaught (talk) 21:18, 8 March 2016 (UTC)
Ping Risker: If/when the new page goes live, would you like to post your WMF Content Checklist there? The WMF was extremely enthusiastic about it. People could make sure it covers all the bases, and we can establish consensus backing. Alsee (talk) 01:31, 9 March 2016 (UTC)
- Just registering my support for this idea. I think it would be an advantage to have a centralized place for enWP to communicate with the WMF, and this might also help with establishing expectations on process (either formally or de facto). If there are any problems with disruption, we can decide to shut it down again. It might lead to some duplicate discussions, as mentioned above, but all the wikis are independent and make their decisions separately in any case. Sunrise (talk) 05:52, 9 March 2016 (UTC)
I agree that improved communication is necessary, but I have questions about adding this channel, Alsee. How do you envision this new VP working? Do you think it would best operate as a beacon to notify enwiki community of happenings over on Meta or MW in order to direct people to those channels (if they actually check or watch it), or is the expectation that this is an added channel for all staff to communicate in, taking away time from centralized and movement-wide venues such as Meta? Would it be a place for communities to discuss and then decide to bubble issues up to the WMF, or is the expectation that a staffer will be watching it at all times or even some of the time? Or is there another way it could function?
Getting feedback from all of the projects is already time-consuming when it's scattered across multiple venues, and I have doubts about adding this venue for that reason. It's understandable that when testing or launching a project (technical or otherwise) to a particular project, that the specific communities should be able to communicate with the WMF team working on that initiative, but trying to collate different opinions from different locations on a constant basis already takes a significant amount of staff energy that may be best used elsewhere. I'd love to see a solution that supports less channels, rather than more. Do you think there's a way that creating this VP might eventually achieve that goal? -Rdicerb (WMF) (talk) 19:20, 9 March 2016 (UTC)
- Ping Rdicerb (WMF), Qgil-WMF. I'll reply to both together, as you raise related concerns. I apologize if I created an impression of placing a burden on WMF staff. To the contrary, I am trying to build a less burdensome solution. Imagine this possible future: The WMF places ONE post on your central page. It could be brought to various community pages by the community, by a bot, or by some cross-wiki-transclusion(if available). The community could take responsibility for translating that one message. The community can fully apply our local processes to have our big messy discussions. The community then generates a summary result. The community translates that ONE summary back to English (if necessary), and it gets delivered to the WMF. That does scale, and it minimizes load on staff. If the WMF posts a new product idea to default all text to Comic Sans, the Community may return a Consensus Oppose. That would translate as "Go forward with the project if you like, but we are unlikely to support any deployment phase here". If you get conflicting responses from different communities, we'll work together on sorting that out reasonably. Alsee (talk) 21:26, 9 March 2016 (UTC)
- Thank you so much for clarifying, Alsee. I appreciate your intention FWIW :) It sounds like a bit of a project that would require some buy-in from different stakeholders (from staff around workflows to communities agreeing to create summaries), but it isn't impossible. I'm glad there's a little more clarification around how this would work.-Rdicerb (WMF) (talk) 22:24, 9 March 2016 (UTC)
- Rdicerb (WMF), generating discussion summaries is something we already do all the time. We call them Closes :) These would generally be more detailed than usual, and we would probably add a validation step before submitting them, but the importance would make it more rewarding than our usual work. It's all just a general concept. I was hoping we could take baby-steps trying to figure it out together, starting at EnWiki. (Shared language, with the largest and oldest community, makes this the natural place to start.) I helped the Reading team create a very-cautious request for feedback to post here. A toe-in-the-water test. The project manager seems enthusiastic to give it a try, I'm just waiting for the liaison to give the greenlight Alsee (talk) 00:53, 10 March 2016 (UTC)
- Alsee, yes, your description above fits the idea I have in mind. Feedback and help to design and implement that process are very welcome. However, a WMF Village Pump in en.wiki is not a hard requirement for such process. I keep being concerned about the expectation that a forum with "Wikimedia Foundation" / "WMF" in its title will arise, and this concern is shared by other WMF colleagues I have checked with. If en.wiki thinks a new Village Pump is needed, we the WMF have nothing to say about that. Just don't call it WMF anything, please.--Qgil-WMF (talk) 10:59, 10 March 2016 (UTC)
- Does anyone have any suggestions for an alternate name? Alsee (talk) 18:11, 10 March 2016 (UTC)
- ("Anyone" reading this, or anyone at WMF? I'll assume the former.)
I don't understand the concern about WMF in the name, as it wasn't explained. If you can't use WMF, it limits the ability to be accurate and descriptive, and the name becomes somewhat opaque. People seeing it for the first time will have no clue what it is, and may or may not take the time to find out. If that's acceptable, perhaps something like Community Liaison would be a little better than, say, Blue Page. If we're still talking about the title of a Village Pump page, and I'm confused about that, it would be Wikipedia:Village pump (community liaison).
One shortcut would need to be WP:VPC (all current pumps have a 3-character shortcut VPx), and that redirect would have to be stolen from Wikipedia:Valued pictures, which doesn't list it in its shortcuts box and is inactive in any case. An alternate shortcut could be WP:VPCL, as in WP:VPIL. ―Mandruss ☎ 03:30, 12 March 2016 (UTC)- Mandruss, yes I was asking "anyone". I believe the concern was that a "WMF" page might be interpreted as being officially connected to the WMF, rather than merely a community page on the topic of the WMF. Also concern that people might form an expectation that WMF staff were obligated to devote time there. In particular, what if every language made a WMF page and they all expected staff to devote time at each of them. Alsee (talk) 07:11, 12 March 2016 (UTC)
- Upon further consideration, the description at WP:VP would make WMF in the page title less important, assuming (1) the page is shown there, and (2) the description actually mentions WMF. Not to mention the description at the top of the pump page itself. But would the same concerns exist for those descriptions? At what point would it be ok to show the letters WMF? ―Mandruss ☎ 07:41, 12 March 2016 (UTC)
- I think the WMF may be over cautious on how editors might interpret the page, but I want do whatever I can to resolve any concerns. I can't imagine they would object to descriptive text that includes things like "this is a page for developing proposals that will be sent to the WMF" or similar. They don't want editors having unrealistic expectations of what the WMF is "supposed" to do there. Alsee (talk) 03:25, 13 March 2016 (UTC)
- Yes, the main concern is the expectation that a certain VP is officially supported by the WMF. This is a factor to consider even when having a perfect title and description for that VP. For instance, Jimmy Wales or (until recently) Lila Tretikov would get routinely questions and requests related to the WMF in their Talk pages just because a critical mass of editors have the expectation to get a reply there. If a forum in en.wiki looks like a channel to file questions or requests to the WMF, I expect that type of expectation to become even more solid.
- Also, it looks like the scope discussed here are software products and major features, but the scope of "WMF" and even "WMF community engagement" is wider. If you do create a new VP, the scope should be clearly defined.--Qgil-WMF (talk) 10:06, 14 March 2016 (UTC)
- Qgil-WMF, part of the challenge is that the scope is fuzzy. For example some of us were talking about building a basic overview guide about us. (The idea is to offer it to you, in the hopes you'd find it useful.) The assumed audience would be a new WMF hire with no familiarity beyond reading article pages. It would give a superficial explanation of core community concepts and how we work. For example I suspect some staff might be surprised that we commonly refer to "Admin" as a janitorial position (a.k.a. "the mop"). It reinforces, in a lighthearted way, that the "Admin" role does not follow the conventional assumptions. It's not a power-position in a hierarchy. Alsee (talk) 06:23, 15 March 2016 (UTC)
- "a basic overview guide about us" where us is en.wiki or the Wikimedia movement in general? Meta has this kind of documentation, en.wiki probably too, and the WMF internal office.wiki too. I agree new employees of the Foundation would benefit from a better onboarding, but yet another source of information is probably not what they need. Anyway, this conversation is getting too far from the original topic.--Qgil-WMF (talk) 12:52, 16 March 2016 (UTC)
- Qgil-WMF, part of the challenge is that the scope is fuzzy. For example some of us were talking about building a basic overview guide about us. (The idea is to offer it to you, in the hopes you'd find it useful.) The assumed audience would be a new WMF hire with no familiarity beyond reading article pages. It would give a superficial explanation of core community concepts and how we work. For example I suspect some staff might be surprised that we commonly refer to "Admin" as a janitorial position (a.k.a. "the mop"). It reinforces, in a lighthearted way, that the "Admin" role does not follow the conventional assumptions. It's not a power-position in a hierarchy. Alsee (talk) 06:23, 15 March 2016 (UTC)
- I think the WMF may be over cautious on how editors might interpret the page, but I want do whatever I can to resolve any concerns. I can't imagine they would object to descriptive text that includes things like "this is a page for developing proposals that will be sent to the WMF" or similar. They don't want editors having unrealistic expectations of what the WMF is "supposed" to do there. Alsee (talk) 03:25, 13 March 2016 (UTC)
- Upon further consideration, the description at WP:VP would make WMF in the page title less important, assuming (1) the page is shown there, and (2) the description actually mentions WMF. Not to mention the description at the top of the pump page itself. But would the same concerns exist for those descriptions? At what point would it be ok to show the letters WMF? ―Mandruss ☎ 07:41, 12 March 2016 (UTC)
- Mandruss, yes I was asking "anyone". I believe the concern was that a "WMF" page might be interpreted as being officially connected to the WMF, rather than merely a community page on the topic of the WMF. Also concern that people might form an expectation that WMF staff were obligated to devote time there. In particular, what if every language made a WMF page and they all expected staff to devote time at each of them. Alsee (talk) 07:11, 12 March 2016 (UTC)
- ("Anyone" reading this, or anyone at WMF? I'll assume the former.)
- Does anyone have any suggestions for an alternate name? Alsee (talk) 18:11, 10 March 2016 (UTC)
- Alsee, yes, your description above fits the idea I have in mind. Feedback and help to design and implement that process are very welcome. However, a WMF Village Pump in en.wiki is not a hard requirement for such process. I keep being concerned about the expectation that a forum with "Wikimedia Foundation" / "WMF" in its title will arise, and this concern is shared by other WMF colleagues I have checked with. If en.wiki thinks a new Village Pump is needed, we the WMF have nothing to say about that. Just don't call it WMF anything, please.--Qgil-WMF (talk) 10:59, 10 March 2016 (UTC)
- Rdicerb (WMF), generating discussion summaries is something we already do all the time. We call them Closes :) These would generally be more detailed than usual, and we would probably add a validation step before submitting them, but the importance would make it more rewarding than our usual work. It's all just a general concept. I was hoping we could take baby-steps trying to figure it out together, starting at EnWiki. (Shared language, with the largest and oldest community, makes this the natural place to start.) I helped the Reading team create a very-cautious request for feedback to post here. A toe-in-the-water test. The project manager seems enthusiastic to give it a try, I'm just waiting for the liaison to give the greenlight Alsee (talk) 00:53, 10 March 2016 (UTC)
- Thank you so much for clarifying, Alsee. I appreciate your intention FWIW :) It sounds like a bit of a project that would require some buy-in from different stakeholders (from staff around workflows to communities agreeing to create summaries), but it isn't impossible. I'm glad there's a little more clarification around how this would work.-Rdicerb (WMF) (talk) 22:24, 9 March 2016 (UTC)
Maybe call it Interwiki? I've been racking my brain on an alternate name, and that's the best I've come up with. It could handle anything with non-local aspects. Alsee (talk) 22:46, 18 March 2016 (UTC)
An article such as, for example, Kylie Minogue includes a number of common templates, each of which contain no parameters, as they draw their values from Wikidata:
{{Commons category}}
{{Wikiquote}}
* {{Official website}}
* {{IMDb name}}
{{Authority control}}
It would seem sensible to try to combine templates like these into a single template, say:
{{Biography footer}}
or, for specialist fields of endeavour, one of:
{{Musician footer}}
or
{{Cricketer footer}}
and so on. These could display (or not) the appropriate values and labels on a case-by-case basis. How might we move towards such a template? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:45, 3 March 2016 (UTC)
- Support - simplify the article page. The way to do it would be to look at the common footers based on occupation, and create the templates based on them. עוד מישהו Od Mishehu 15:44, 3 March 2016 (UTC)
- Comment, leaning oppose Most of those templates are problematical if added indiscriminately. {{Official website}} gives a big ugly red error if wikidata has no listing. {{Commons category}} and {{Wikiquote}} claim information is available and create links to potentially nonexistent pages. {{IMDb name}} generates a link to potentially nonsensical search results. It looks like the only one that can consistently be added {{Authority control}}. A unified template could be carefully used where all of the sub-templates happen to be valid, but any added convenience seems minor and I see a downside. It's more confusion and hassles when less familiar editors try to figure out what's going on, or potentially copy it inappropriately. If someone puts the unified template on an article but one of the items is invalid, it is a hassle and extremely non-obvious that they need to swap the unified template for the three correct subtemplates. Alsee (talk) 17:07, 3 March 2016 (UTC)
- The template could check for the existence of the appropriate Wikidata properties (see hu:Template:Filmlinkek for an example). – nyuszika7h (talk) 18:59, 3 March 2016 (UTC)
- For example, Latvian and Norwegian Wikipedia (OK, we (Latvians) simply copied from Norwegians :) ) has template sports external links, which adds some profiles (from Wikidata) to articles. --Edgars2007 (talk/contribs) 08:27, 4 March 2016 (UTC)
- The template could check for the existence of the appropriate Wikidata properties (see hu:Template:Filmlinkek for an example). – nyuszika7h (talk) 18:59, 3 March 2016 (UTC)
- Oppose As has been pointed out, very little upside and a huge downside. We have way too many biographical articles and of a very diverse nature; the proposal would only benefit a very small group of articles. Chris Troutman (talk) 15:46, 4 March 2016 (UTC)
- This isn't a vote, and in any case you appear to be opposing a proposal that I haven't made. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:32, 4 March 2016 (UTC)
- Umm, this is Village pump (proposals), which I guess escaped you since you claim not to be making a proposal. In any case, be honest and just say you don't appreciate my opinion rather than talk at me while not pointing to "!vote" to those who agree with you. I don't think we should be moving "towards such a template". Chris Troutman (talk) 20:54, 5 March 2016 (UTC)
- This isn't a vote, and in any case you appear to be opposing a proposal that I haven't made. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:32, 4 March 2016 (UTC)
- Oppose for now this particular implementation, but the underlying idea is viable per all of the above comments and replies. Right now, we need to add features to pages as they are required. The proposed template would not simplify anything because, as noted, the templates it would call are problematic when not needed or not used properly, so they can't be on by default, but having them off by default puts us in exactly the same position as having no template for this, since they won't be active on the pages that need them until someone manually enables them. The general idea of auto-generating sister-project links and such from Wikidata is a good one, because most users a) don't even know about these features, and b) would have a hard time figuring them out. The present state of things is just too half-baked to do this now. Maybe this could be done with custom code that doesn't throw errors, generate useless links, etc., instead of shelling out to extant templates that have these problems. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 17:49, 4 March 2016 (UTC)
- I don't know which "particular implementation" you think you're opposing, but I haven't proposed one; I asked a question. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:32, 4 March 2016 (UTC)
- I'm extremely skeptical the closer or anyone else would be confused by my statement, but just in case: I'm obviously referring to "try to combine templates like these into a single template", which you then gave a proposed name for, and then essentially contradicted yourself and proposed different topical templates of a similar combined, multi-function character, for biographies, or even for narrow things like music and cricket. Please see WP:BLUDGEON, and don't badger people with "I will force you to state the obvious, just because" nit-picks, especially when they're expressing support for developing the idea more concretely later. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 05:35, 21 March 2016 (UTC)
- @SMcCandlish: Sounds like you're not going to disbelieve me, but you did make a confusing statement. Not everyone contributing here sees your opinions as clearly as you do, so please respond to requests for clarity more courteously and in a Wikipedian spirit. MartinPoulter (talk) 16:55, 22 March 2016 (UTC)
- Fair enough. My tone was based on previous interactions with the same editor in which I feel I'm being needled with nit-picks. I'm sure he has complaints about me, too, and it will blow over. Our interaction is constructive more often than not over the last year or so. @Pigsonthewing:: If you really found my statement confusing, I apologize. Aw, hell, I'll apologize anyway, it's been a long day and I'm cranky. And it's far from over, ha ha. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 17:50, 22 March 2016 (UTC)
- @SMcCandlish: Sounds like you're not going to disbelieve me, but you did make a confusing statement. Not everyone contributing here sees your opinions as clearly as you do, so please respond to requests for clarity more courteously and in a Wikipedian spirit. MartinPoulter (talk) 16:55, 22 March 2016 (UTC)
- I'm extremely skeptical the closer or anyone else would be confused by my statement, but just in case: I'm obviously referring to "try to combine templates like these into a single template", which you then gave a proposed name for, and then essentially contradicted yourself and proposed different topical templates of a similar combined, multi-function character, for biographies, or even for narrow things like music and cricket. Please see WP:BLUDGEON, and don't badger people with "I will force you to state the obvious, just because" nit-picks, especially when they're expressing support for developing the idea more concretely later. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 05:35, 21 March 2016 (UTC)
- I don't know which "particular implementation" you think you're opposing, but I haven't proposed one; I asked a question. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:32, 4 March 2016 (UTC)
- There seems to be an inflexibility here. Consider
{{Commons category}}
- that is supposed to go at the top of the last section.{{Authority control}}
by contrast is towards the end of the last section - but before the categories and stubs. There are a number of items, not mentioned above, that should appear between these - such as the true external links (those not covered by templates like{{Official website}}
), succession boxes, and navboxes. It seems that a change to WP:FOOTERS would be necessary before a standardised template like{{Biography footer}}
is introduced, such change would permit the true external links, succession boxes and navboxes to go before the{{Commons category}}
, or after the{{Authority control}}
. I don't think that such change is likely. --Redrose64 (talk) 21:42, 4 March 2016 (UTC) - Great idea - and easily implementable; we already do something similar with infoboxes. I wonder if in future all articles will automatically have in-article links where other wikilinks exist - eg quotes, with wikidata, commons and so forth. @Pigsonthewing. I suggest move this discussion to village pump (ideas) if you don't want a heated support/oppose discussion. --Tom (LT) (talk) 08:53, 5 March 2016 (UTC)
- Oppose for now. This is clearly the direction we are headed and a welcome development, but the way Wikidata and Wikipedia work together isn't just ready yet. This would be a huge development and overwhelming consensus is needed on templates that are transcluded on such a large number of articles. Standardization like this seems to work best with things that are actual standards, i.e. library classifications in Authority control. – Finnusertop (talk ⋅ contribs) 21:20, 5 March 2016 (UTC)
- Maybe It's an interesting idea but I don't like the idea of variations such as {{Cricketer footer}} which will cause trouble when people have more than one possibility. And some people would like us to have the entire article generated by such an omnibus template, which would automatically "fill in the blanks" from Wikidata and other external repositories. We're not there yet. Andrew D. (talk) 08:37, 6 March 2016 (UTC)
- Support. Agree with Pigsonthewing and Od Mishehu. Good way to increase uniformity and ease of standardization through help from our sister project friends at Wikidata. — Cirt (talk) 16:09, 9 March 2016 (UTC)
- Oppose. Proposal or not this strikes me as over-design and would raise the hurdle for new editors to understand how the page is rendered by adding another layer of abstraction. In general, I think we should avoid "jars within jars" to the extent possible. KISS principle and all. Jason Quinn (talk) 17:37, 14 March 2016 (UTC)
- having five templates when one template would do seems to be an obvious violation of the KISS principle. MartinPoulter (talk) 16:55, 22 March 2016 (UTC)
- Oppose Too inflexable, adn inappropriate on too many articles, as mentioned above. moreover, at this time, Wikidata entries have too few eyes on them and are too easily the targets of subtle vandalism to have any article content automatically depend on them. Indeed i oppose the sue of templates such as {{Official website}} at this time. DES (talk) 00:19, 19 March 2016 (UTC)
Close down Possibly Unfree Files
At this discussion, we reached consensus to close down non-free content review and instead send all such discussions to Files for Discussion. Possibly unfree files (PUF) has many of the same issues. It doesn't get enough attention - current there are unclosed discussions from December. And, more importantly, it isn't clear to many editors, nor to any new editors, whether such a deletion discussion should happen at PUF or FFD. Files for discussion is perfectly capable of handling the additional discussions.
The proposal is this: Close down Possibly Unfree Files, with all future discussion at Files for discussion Oiyarbepsy (talk) 03:48, 6 March 2016 (UTC)
Close PUF
- Support closing. While they may officially have different purposes, in practice they duplicate each other, and we'd do better to have less processes rather than more anyways. --Jayron32 16:30, 7 March 2016 (UTC)
- Support. With the way that the English Wikipedia has evolved over the years, it just makes sense to have all discussions for "File:" namespace pages to happen in the same place. Steel1943 (talk) 19:02, 7 March 2016 (UTC)
- Support - It only makes sense to limit the places that deletion discussions take place; having a different place for each specific reason for discussion leads to bureaucracy. It does make sense to have different places for files, templates, categories, articles, and "other" pages, but since FfD and PUF are essentially duplicating work and many (if not most) editors are not aware of PUF (for example, I was not aware PUF existed), they need to be merged. — Jkudlick • t • c • s 13:34, 8 March 2016 (UTC)
- Support - Easier just to have one place to discuss all the particular aspects of files local to Wikipedia, most of which relate to a files particular free-ness. Redirect to FFD or mark historical with a big pointer to FFD. --Izno (talk) 14:21, 8 March 2016 (UTC)
- Support – I've had users respond with confusion when I took a file to PUF rather than FFD, the former being less well known. Would be simpler and easier for everyone just to have the one venue for everything. CT Cooper · talk 18:06, 8 March 2016 (UTC)
- Support. Seems like unnecessary duplication. --Regards, James(talk/contribs) 18:14, 8 March 2016 (UTC)
- Support Per all the above. Having too many forums for discussion of basically th same thing is unhelpful to the project. Beeblebrox (talk) 18:35, 8 March 2016 (UTC)
- Support – Reduces bureaucracy, improves efficiency. RGloucester — ☎ 19:17, 8 March 2016 (UTC)
- Support - decreases red-tape, and increases performance. — Cirt (talk) 01:39, 9 March 2016 (UTC)
- Support. The distinction was often unclear to me, too. Sandstein 08:15, 9 March 2016 (UTC)
- Support as IMHO it's a completely pointless board - It's pretty much a duplicate of FFD so there's not much point in keeping it around, FFD seems to be the best choice here. –Davey2010Talk 03:07, 10 March 2016 (UTC)
- Support simplification and centralization and elimination of this and other bureaucratic cul de sacs. Carrite (talk) 12:29, 11 March 2016 (UTC)
- Support: fewer is better. Esquivalience t 20:57, 12 March 2016 (UTC)
- Support I never understood why it was necessary to have multiple venues for files in the first place. — JJMC89 (T·C) 22:00, 12 March 2016 (UTC)
- Support per nominator. Reduction of confusion in regards to "where to go" by removing essentially duplicate spaces is appreciated. I, JethroBT drop me a line 01:24, 14 March 2016 (UTC)
- Support. This is a logical next step for reasons already stated above. I'd be interested in feedback from PUF regulars on what they would need to be best accommodated in FFD. czar 03:29, 14 March 2016 (UTC)
- Support Thanks to the broadening of FFD's mandate it now can handle non-deletion outcomes. Also, I see rather frequently the freeness of an image being disputed in FFD when PUF would be the right place.Jo-Jo Eumerus (talk, contributions) 17:21, 14 March 2016 (UTC)
- Support. Simpler. -- Ϫ 01:56, 15 March 2016 (UTC)
- Support – when a process does not get much activity, and can easily be replaced by another process, it is best to close it down. sst✈ 05:45, 15 March 2016 (UTC)
- Support --- PUF doesnt get much anyway Ⓩⓟⓟⓘⓧ (talk) 18:52, 16 March 2016 (UTC)
- Support -FASTILY 21:59, 16 March 2016 (UTC)
- Support per the KISS principle. Andrew D. (talk) 17:44, 18 March 2016 (UTC)
- Support Hamid Hassani (talk) 16:47, 20 March 2016 (UTC)
- Support. Good reduction in WP:BUREAUCRACY and WP:CREEP, and consistent with the previous closure of the other redundant process of this sort. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 06:55, 21 March 2016 (UTC)
- Support. In the long run, PUF is just a specialization or a branch of FFD. Anything at PUF can also be conered at FFD. epicgenius (talk) 13:56, 22 March 2016 (UTC)
- Support - PUF gets little attention. It serves the same purpose as FFD. It is therefore redundant and should be closed. Ethanlu121 (talk) 15:56, 22 March 2016 (UTC)
- Support - I'm a relatively experienced user yet have been confused by this. Arguments for simplification are compelling. --LukeSurl t c 14:15, 24 March 2016 (UTC)
- Support I'm very concerned if the page might be overwhelmed or not, I simply hope not. The idea seems good, imo. --QEDK (T 📖 C) 16:29, 25 March 2016 (UTC)
- Support Seems to make the process similar. Other supports make good arguments. Particularly swayed by SST's support. Wugapodes (talk) 00:47, 28 March 2016 (UTC)
Keep PUF
- Support keeping PUF. PUF and FFD have clearly distinct purposes, and the discussions are typically closed after around a week. Also, most PUF discussions are closed by the same users as those who close the FFD discussions, so if you close down PUF because you think it's backlogged, you will just move a backlog from one place to another place and thus not achieve anything. --Stefan2 (talk) 11:19, 6 March 2016 (UTC)
- Yeah, the policy pages say they're different, but when you actually look at the discussions, they aren't. And giving the closers one place to look instead of two will reduce the backlog for that simple reason. Oiyarbepsy (talk) 16:33, 6 March 2016 (UTC)
- Exactly, ×2. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 06:56, 21 March 2016 (UTC)
- Yeah, the policy pages say they're different, but when you actually look at the discussions, they aren't. And giving the closers one place to look instead of two will reduce the backlog for that simple reason. Oiyarbepsy (talk) 16:33, 6 March 2016 (UTC)
- Keep as the file is not so often deleted. Graeme Bartlett (talk) 00:16, 14 March 2016 (UTC)
- WP:FFD is "files for discussion", not "files for deletion". RGloucester — ☎ 00:37, 14 March 2016 (UTC)
- User:Graeme Bartlett, when non-free content review was closed down, Files for Deletion was renamed to Files for Discussion so that it could handle all the issues that non-free content review covered. For examples, many recent discussions have ended with the result of remove from this and that article without deleting the image. Similarly, with PUF merged in, you could have discussions ending with the result image is free or image is not free, without actually deleting it. Oiyarbepsy (talk) 01:38, 14 March 2016 (UTC)
Discussion (PUF)
- Comment: Just wondering how the cleanup is going to proceed if this RfC is approved. Just going by what happened after the NFCR/FFD merge, it seems there were many in favor of the merge who decided to not get involved in the cleanup, thus causing it to take much longer than it probably should have. A few editors really spent a lot of time updating templates, closing discussions, etc. and few admins worked their way through NFCR files which were added to FFD to help reduce the backlog. Not sure how many PUF discussions will be added to FFD, but it would be nice if there was also some consideration given to the post-merge cleanup. -- Marchjuly (talk) 02:24, 9 March 2016 (UTC)
-
- @Marchjuly: I already have a bit of an overview about what will need to take place after this merge is approved. This merge probably will not be as complicated as the FFD rename since rather than a forum being shut down and a forum renamed, instead, we only have a forum to shut down. The technical details will include AnomieBOT having to stop creating daily subpages after the merge is finalized, Twinkle needing to be updated to have the WP:PUF option removed, and the instructions at WP:FFD to be updated to encapsulate everything. And, with this proposal, almost no templates should need to be updated due to no forum being renamed (I know that was the biggest headache with the NFCR to FFD merge.) Steel1943 (talk) 03:24, 9 March 2016 (UTC)
-
- Although I didn't mention you by name Steel1943, you were one of the editors who did a lot of the heavy lifting post merge. So, if you feel things will not take as much time as before than that's good enough for me. Still there may be some discussions on PUF which require further discussion or an admin to close. Is the plan to relist them in stages at FFD like was done with NFCR or will everything be moved at once? Not sure which approach is best. I guess it depends on the number of unresolved discussions at the time of the merge. -- Marchjuly (talk) 04:16, 10 March 2016 (UTC)
- @Marchjuly: I think the first step is to have what I outlined above accomplished first (halting the creation of the daily subpages.) Afterwards, if after a while PUF entries do not get closed, then relating could be an option. (I do not see the need to relist PUF discussions on FFD immediately being as necessary as the NFCR to FFD merge since PUF has daily subpages and most of those discussions are being closed in a somewhat more orderly fashion than NFCR was.) Steel1943 (talk) 21:51, 13 March 2016 (UTC)
- Although I didn't mention you by name Steel1943, you were one of the editors who did a lot of the heavy lifting post merge. So, if you feel things will not take as much time as before than that's good enough for me. Still there may be some discussions on PUF which require further discussion or an admin to close. Is the plan to relist them in stages at FFD like was done with NFCR or will everything be moved at once? Not sure which approach is best. I guess it depends on the number of unresolved discussions at the time of the merge. -- Marchjuly (talk) 04:16, 10 March 2016 (UTC)
- I'll add that this should be way easier to close since PUF actually has daily subpages, making things trackable, unlike NFCR which had squat. Oiyarbepsy (talk) 04:03, 9 March 2016 (UTC)
-
- That's a good point Oiyarbepsy that I forgot about. You also were one of the editors who helped clean things up post merge so if you feel things are going to be more manageable this time, then everything sounds good to go. -- Marchjuly (talk) 04:19, 10 March 2016 (UTC)
- With regards to the existing backlog, in case it isn't clear - for NFCR, the page was just left open and listed at WP:ANRFC, and new requests were directed to FFD by a template. Sunrise (talk) 06:00, 9 March 2016 (UTC)
Proposal: Enable Hovercards by default
Hovercards is a Beta feature that displays a short summary of an article and an image when a user hovers over a link. When enabled, there is an option to disable it by clicking on the gear icon and selecting "Disable previews", which can be undone by clicking a link in the footer, similar to the disabling system used by Reference Tooltips.
Hovercards can be tested via Special:Preferences#mw-prefsection-betafeatures. Currently, about 46,000 English Wikipedia users are testing the feature.
Some background information: Navigation popups, a tool providing easy access to article previews and several Wikipedia functions, was created as a user script in 2005 primarily by User:Lupin, with help from numerous other Wikipedians. It was made into a gadget in 2007, and became one of the most popular gadgets, with over 40,000 users opting in to use it on the English Wikipedia, and nearly 40,000 more users on other Wikipedias. In 2014, the Wikimedia Foundation started working on "Restyling and Enhancements" for the feature, greatly simplifying the appearance of the popups, emphasizing the lead image, and hiding by default the extra Wikipedia functions, targeting the feature primarily towards casual readers. The new version was re-branded as "Hovercards", and made into a Beta feature. In 2015, Hovercards was rolled out to all users on the Greek and Catalan Wikipedias for a two month test, gathering feedback via a survey, which mostly received positive responses, along with many bug reports and suggestions for improvement.
Note that this feature still has several remaining bugs, including the popups occasionally getting "stuck" and not vanishing properly, and popups having issues with certain types of article leads. Hovercards is also still lacking many features supported by navigation popups. (Currently, if one has navigation popups enabled and selects "Advanced" mode to use the extra features, navigation popups-style popups are displayed instead of Hovercards-popups.) For links to certain articles, an image not directly related to the article topic is displayed, due to a bug in the PageImages API.
If anyone considers any particular bugs/gaps/tasks to be blocking (that is, we should wait until they're fixed before enabling the feature by default), please say so. Waiting until certain things are fixed is an option. Simply not turning the feature on by default at all is also an option. So is waiting until it has received more testing on other projects. The WMF is willing to work on this as necessary, provided the community actually wants the feature.
Should Hovercards by enabled by default on the English Wikipedia? --Yair rand (talk) 10:29, 16 March 2016 (UTC)
NOTE: There is a discussion at policy talk: Non-free_content#Hovercards. It seeks to determine whether it is acceptable for non-free images to appear in Hovercards. Alsee (talk) 16:55, 16 March 2016 (UTC)
Discussion
- Wait until the extension has reached feature parity with navigation popups, then reconsider. Note that popups have always been opt in for editors. MER-C 11:03, 16 March 2016 (UTC)
- Hovercards are primarily intended for readers who don't need all the fancy bells-and-whistles of Lupin's navigation popups. These are also the people who can't easily "opt-in" or "opt-out" of this feature, as most of them aren't logged-in. Power-users can easily disable Hovercards using the button on the card. With 45,955 registered users already having opted-in at the moment, I think "enable by default with an easy opt-out" would be the sensible default setting. —Ruud 11:34, 16 March 2016 (UTC)
- This will never happen (within the next five years), nor was it a goal of hovercards. (disclaimer, i'm a former navigation popups developer) —TheDJ (talk • contribs) 12:24, 16 March 2016 (UTC)
- In which case, oppose for editors. Let's make it opt in for readers first while the bugs are squashed then try to measure how many readers found it useful and how many turned it off, and perform A/B tests. MER-C 06:50, 23 March 2016 (UTC)
- I need to understand "(Currently, if one has navigation popups enabled and selects "Advanced" mode to use the extra features, navigation popups-style popups are displayed instead of Hovercards-popups.)" -- As I don't use NPopups, is the "Advanced" mode part of popups or hovercards? Does that basically mean that popups is hooking into hovercards? --Izno (talk) 11:39, 16 March 2016 (UTC)
- @Izno: The option for "Advanced" mode is in the Hovercards menu, but the option currently only appears when one also has Navigation popups turned on, and those popups themselves come from Navigation popups. Hovercards normally suppresses Navigation popups to avoid duplication. I'm pretty sure that all the "Advanced" setting does is turn off Hovercards and remove the suppression of the Navigation popups. (I imagine the eventual plan is to have "Advanced" mode actually be fully part of Hovercards and not use the gadget.) --Yair rand (talk) 11:58, 16 March 2016 (UTC)
- Enable by default. However, I would consider either phab:T105782 or phab:T92932 to be blockers of the definite sort and not just the "kinda'" sort that we usually associate with blockers in Phabricator, so one of the two needs to be resolved prior to enabling by default. --Izno (talk) 12:21, 16 March 2016 (UTC)
- I've been using Hovercards for at least a few months now and the "getting stuck" thing happens perhaps once a week or so. The easy solution is to press F5 and refresh the page. So it's not really a blocking issue for me. But if it could be fixed, that would be better, yes. —Ruud 12:44, 16 March 2016 (UTC)
- Oppose. Should be opt in only. NOT enabled by default. These things are quite cumbersome when reading articles anywhere on the Internet and bothersome. They are extremely incredibly distracting to readers and editors alike. Both during the reading process or editing process. — Cirt (talk) 14:39, 16 March 2016 (UTC)
- Well, I personally find this feature to be incredibly useful. You actually need to hover your cursor over the link for a while before the card opens, so I rarely open it by accident. The survey among readers does indeed show that there is a strong "love it" or "hate it" response:
- but 1) the people that like it vastly outnumber the people that don't (6 to 1) and 2) it's much easier to disable this thing (click the button on the card) than it is to enable it (create an account and find a checkbox hidden on one of the preferences tabs). —Ruud 15:45, 16 March 2016 (UTC)
- Enable by default I find Hovercards to be very useful and based on the number of people that have enabled this Beta feature and the survey responses I think this will be useful for a majority of the readers. Most of those readers won't be able to enable this feature if it remains as an opt-in feature, while those that find this a nuisance can disable it quite easily. —Ruud 16:51, 16 March 2016 (UTC)
- Enable by default, but first they should add the standard "X" at the top right allowing the user to close the card, doubleso if there is a bug that sometimes prevents them from closing automatically. Diego (talk) 17:51, 16 March 2016 (UTC)
- Enable by default provided there's a means to disable the feature from the card itself. (Disclaimer: I've used Lupin's popups for the past several years.) —Jeremy v^_^v Bori! 21:03, 16 March 2016 (UTC)
- Very Strong Enable by Default This is very, very useful. When I get on WP at lunchtime from work to just browse stories, I find it horrible that I have to actually click a term link to find out the bare info about it. Annoying. I am on several computers a night and hardly ever in the same location again. To me, the hovercard is a godsend for quick reading about items and terms I may not be that familiar with. With my casual reader hat on, I find it is a huge time saver. It should be available standard, with an opt-out feature for those who don't like it. GenQuest "Talk to Me" 22:28, 16 March 2016 (UTC)
- Oppose Just leave NAVPOPS alone(Redacted)--Stemoc 23:36, 16 March 2016 (UTC)
- Enable - I've used hovercards for years. I like hovercards. And I'm not going to argue with the data at mw:Beta_Features/Hovercards#Qualtrics_Survey_Results. But the WMF should just get more data to avoid these discussions where input is limited to a small group of power-users who are not representative of the audience and have no insight into design or usability. Just run A/B tests on x% of the audience, find out how hovercards effect their behaviour. Bring in volunteers on site in SF and do eye-tracking or something. Anything to expedite circular discussions on-wiki. - hahnchen 23:55, 16 March 2016 (UTC)
- Enable For once a Mediawiki beta feature that is really good and everyone should get. Oiyarbepsy (talk) 04:41, 17 March 2016 (UTC)
- Oppose per Cirt. Any kind of pop up content should be disabled by default. I assume that be having this on by default, page load time would be increase and that there would be further drain on client resources by Javascript. - MrX 12:56, 17 March 2016 (UTC)
- Oppose - one of the most annoying things on web pages is when unexpected popups appear. While anyone who wants this would certainly not complain, it shouldn't be forced on anons, nor enabled for registered users except by explicitly asking it to b enabled (such as in the "Preferences" page). עוד מישהו Od Mishehu 15:42, 17 March 2016 (UTC)
- Try hovercards, if they were default on, those popups would not be unexpected - they only appear after hovering over a link for a second. The reader survey above suggests that "forcing" this upon anons would prove useful. - hahnchen 16:46, 17 March 2016 (UTC)
- You move the mouse carelessly, happen to leave it on a link, and then a popup shows up... that would certainly be unexpected. I do use Lupin's popups, but would certainly oppose it being imposed on anons or enabled for registered users by default. עוד מישהו Od Mishehu 18:14, 17 March 2016 (UTC)
- Try hovercards, if they were default on, those popups would not be unexpected - they only appear after hovering over a link for a second. The reader survey above suggests that "forcing" this upon anons would prove useful. - hahnchen 16:46, 17 March 2016 (UTC)
-
- @Od Mishehu: Note that we have already decided to enable the very similar Reference Tooltips popups as an opt-out feature for both registered and for non-logged-in users (Wikipedia:Village_pump_(proposals)/Archive_89#Reference_Tooltips).
- I think that it is to be expected that there are going to be some users who will like these popups and some that are going to be annoyed by them. (The survey that was run shows that 76% of readers like them, 13% don't like them, and the remaining ones don't care either way.) Whether you want to use them should indeed be an individual choice. But if we leave this as an opt-in for registered users only, most people will not have the opportunity to make that choice, simply because they have no way of knowing that making the choice to enable this feature is an option. Making this an opt-out feature is probably the closest we're going to get to giving everyone a chance to make that explicit choice for themselves. Yes, a few people will be annoyed when these popups appear, but disabling them is easy. Enabling them, on the other hand, is nigh impossible for most readers at the moment. —Ruud 19:53, 17 March 2016 (UTC)
- Reference links are quite a bit smaller than regular links, so I'm not sure the comparison works all that well. --Yair rand (talk) 21:49, 17 March 2016 (UTC)
- If my first experience with Wikipedia had been a popup showing up unexpectedly, I would have probably decided it was a spam site and stayed away from it. עוד מישהו Od Mishehu 14:47, 18 March 2016 (UTC)
- Reference links are quite a bit smaller than regular links, so I'm not sure the comparison works all that well. --Yair rand (talk) 21:49, 17 March 2016 (UTC)
- Oppose Who the hell do you people think you are? So now you think we should have users experience pop-ups by default without them specifically asking for it? That's nonsense. Look, I use navigational popups and I think everyone should but I'm not supporting enabling intrusive features for users without their consent. I'm guessing someone wants to push hovercard use and isn't happy with the number of opt-ins; this is a sad measure to force the issue. Chris Troutman (talk) 21:32, 17 March 2016 (UTC)
- Oppose. Great feature, but no way this should be enabled by default. Doing so will only cause confusion for those who have dealt without them for so long, some of which may have never touched the "Preferences" tab before. However, as a caveat, I am neutral on this being enabled by default for IP editors only; this opinion is similar to how the "media viewer" ended up being set up. — Preceding unsigned comment added by Steel1943 (talk • contribs)
- Oppose - No it fucking shouldn't be the default, I've just enabled it and well I absolutely hated it .... so it's now disabled and I'd rather leave it like that, If I wanted to know what for example a "convertible" was I would read a dictionary not expect some irritating pop up to tell me every single linked word my mouse goes over!, Although I do support enabling it for IPs as that way IPs might hate it as much as I do and would hopefully signup .... Anyway no don't enable it - Just let people who want it to enable it via their preferences. –Davey2010Talk 22:50, 17 March 2016 (UTC)
- Oppose. This would reduce article traffic, and interferes with the reading of text when readers unintentionally hover their cursor on a wikilink. Personally, I find this feature annoying. sst✈ 02:03, 18 March 2016 (UTC)
- How would it reduce article traffic? Hovercards are very simple to understand, and users can still just click on the link to open the article in a new page, there's no difference in behaviour there. If you feel that by serving up the lead to readers in a hovercard, that the reader will not then read the rest of the article, you are saving time and resources needed to serve a new page. - hahnchen 23:43, 18 March 2016 (UTC)
- Comment – I can see the use for this, but I can also see how it can become really annoying. What we really need is a solution that would make it much easier for readers (that is, non-editors) to notice these add-ons and enable them voluntarily. Something like a prominent "reading preferences" menu at the top of the page, next to "Create account", that all of our users could have to personalize their reading experience. If there is widespread support for a particular add-on from this setup, a discussion of whether to enable by default would be more successful. Mz7 (talk) 05:03, 18 March 2016 (UTC)
- @Mz7: How would you define "widespread support"? (Currently there are 46,071 registered users who enabled this beta. A survey among anonymous users found that over three quarters found this useful, one in eighth disliked it.) —Ruud 09:56, 18 March 2016 (UTC)
- @Ruud: Careful with statistics! Those 46,071 are less than 0.2% of the 27,868,642 registered users of English WP – is that widespread support? How self-selecting were those who responded to that survey among anonymous users? Stanning (talk) 10:21, 18 March 2016 (UTC)
- @Stanning: It would indeed be very interesting to know not only how many people have enabled a particular feature, but also how many enabled it at some point and then decided to disable it again. So we could classify people into "tried it and liked it", "tried it and didn't like it", and "didn't try it yet". We could even break this number further down into categories for "very active registered users", "active registered users" and "registered users that don't edit". And plot these numbers over time. All of this information should ideally be visible on the Beta tab.
- But even if we know these numbers, my original question still stands. How should we define "widespread support"? —Ruud 11:12, 18 March 2016 (UTC)
-
-
-
- @Ruud: I didn't envision any sort of quantitative definition of "widespread support." A lot of the opposition (and support) in this discussion is based on personal preference; if we notice that one add-on feature is generally getting more attention among our readership than others, then that would indicate that our readers prefer the feature and could be a more solid basis on which to enable by default. The statistics you mentioned are encouraging to that effect, and as of now, I'm not strictly opposed to enabling Hovercards by default. I still think, perhaps for future feature add-ons, that giving our readers a centralized "reading preferences" menu would allow them to personalize their Wikipedia experience in the way they like it, rather than trying to force a feature on everyone. If we do end up enabling Hovercards by default, then it is important that we make it very easy for users that don't want it to opt-out. Mz7 (talk) 18:33, 18 March 2016 (UTC)
- How about a large scale A/B test on the English Wikipedia? While the data we have from the Greek and Catalan Hovercards trial is useful, we could do with a lot more. Instead of solely relying on survey responses (which is still useful), the foundation should be looking at performance impacts, hovercard disable rates, hovercard "alive" times (are people reading the hovercards), click-through rates (do hovercards encourage more page views, or do they keep the reader focused on the current one?). At some point, there should be enough data one way or another that those arguing on "personal preference" can be mostly ignored. - hahnchen 23:43, 18 March 2016 (UTC)
- @Ruud: I didn't envision any sort of quantitative definition of "widespread support." A lot of the opposition (and support) in this discussion is based on personal preference; if we notice that one add-on feature is generally getting more attention among our readership than others, then that would indicate that our readers prefer the feature and could be a more solid basis on which to enable by default. The statistics you mentioned are encouraging to that effect, and as of now, I'm not strictly opposed to enabling Hovercards by default. I still think, perhaps for future feature add-ons, that giving our readers a centralized "reading preferences" menu would allow them to personalize their Wikipedia experience in the way they like it, rather than trying to force a feature on everyone. If we do end up enabling Hovercards by default, then it is important that we make it very easy for users that don't want it to opt-out. Mz7 (talk) 18:33, 18 March 2016 (UTC)
-
-
- Oppose. I agree with Mz7: can be useful, can be annoying. But no way should it be enabled by default, even for IPs, even with a little gear-wheel to turn it off (if you know what the gear-wheel means).
As Mz7 says, it'd be good anyway to make Preferences, or some of them, available to IP users (I guess that'd mean a WM change to keep some preferences on the device, instead of centrally, for non-logged-in users).
Maybe a compromise would be to enable it by default once only and on first pop-up include a line saying something like "Do you want this feature? Click here to enable it" and if the user doesn't click, turn it off at once (not the other way round).
Personally I dislike pop-ups because usually they're ads or otherwise irrelevant. Of course on WP we're pure and undefiled, but that doesn't mean that we should feel free to push features like this, however 'cool' they seem to us. Stanning (talk) 09:41, 18 March 2016 (UTC) - Oppose for now. I would support if they contained no images. The current WMF fad to include large images in everything (this, related articles, Gather before it was disabled, apparently some new search as well) is very annoying; we are a knowledge engine (ha!) that also includes images, not an image repository with some accompanying text. (The indication of how long ago the hovered page is last edited is also completely unnecessary, as it gives no information related to the hovercard text or even interesting to 99.9 of the people using the hovercard) Fram (talk) 11:37, 18 March 2016 (UTC)
- I think an image usually adds value to the card. What I don't particularly like is that the PageImage extension tries way too hard to extract an image from the article. If we have an image in the lead section, great, use it. But don't pick an image that's several sections down in the article. You can find complaints all over the place about this, ranging from nonsensical images being displayed, to outright problematic ones. —Ruud 12:00, 18 March 2016 (UTC)
- Oppose per the KISS principle. Andrew D. (talk) 17:49, 18 March 2016 (UTC)
- Oppose It's a useful feature but I would expect it be a preference to have enabled or not, and starting with it on by default is not good as well made impede people on older computers or browsers. I would reasonably expect to have a banner announcement that this feature is now available and how to enable it for those that want it. --MASEM (t) 18:00, 18 March 2016 (UTC)
- Oppose forcing it on readers as the default - not everyone is going to know they can turn it off and may want to for the reasons given above. Doug Weller talk 11:50, 19 March 2016 (UTC)
- comment (leaning on oppose). I use them for some time. They are quite good in giving us a glimpse about the linked to article, often that is enough to get why it is linked from 'here' and to know if we want to get there. Still they have two issues that make me think that not having it by default is better. One, these things can be quite annoying when you do not want them, so I'd rather have people missing them for a while until they realise they can have them, than annoying the readers. Two, the images, as many already said, are often a poor choice. Don't try too hard to have an image, if there is not one in the lead, do not look any further (if there was a good image, generally describing the subject in a whole, full, proper way, our editors will push them to the lead soon enough, no need to have a script making guesses) - Nabla (talk) 18:22, 19 March 2016 (UTC)
- Oppose: I have reason to believe that activating this feature by default would only give more ground to North America exceptionalists to created unnecessary templates like {{Football squad start2}}, {{football squad player2}}, etc. while using accessibility as their excuses. Cédric wants to abolish "Convention №. 2" like abolishing slavery. 21:49, 19 March 2016 (UTC)
- @Cendric than cantonais:: Please explain. What you've said doesn't mean anything concrete to most of us, especially since football squads (soccer teams, in American English) are little-known in North America, so the examples you provide don't seem to illustrate anything about "North America[n] exceptionalism". — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 06:43, 21 March 2016 (UTC)
- @SMcCandlish: Glad to explain. Templates like {{Football squad start2}}, {{football squad player2}} are specially created for and are only used for in articles of North American association football teams. Certain users has argued that templates like {{Football squad start2}}, {{football squad player2}} are created so readers on mobile devices can access these pages more easily, but the way I see it, these templates (along with certain "conventions" like "Don't decorate captains in articles of North American association football teams") exists for promoting North American exceptionalism and little else.
- @Cendric than cantonais:: Oddly enough, I just addressed some of this in a different context, at WT:CFD. Short version: MOS:TIES, though basically an article content rule, can affect templates, if they generate content for articles; so, it is essentially required that there be AmEng templates that use AmEng terms in lieu of Commonwealth English ones, for AmEng articles. There is also a consensus against using US state flags for things; MOS:ICONS wants flags in sport to be for sporting nationality, period, and this has been arrived at through years of contentious discussion. If this still doesn't address your concern, I must be missing too much of the back-story regarding disputes about these particular templates. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 21:55, 21 March 2016 (UTC)
- When it comes to enabling hovering images, my main concern is that North American exceptionalists would attempt to come up with new "conventions" like "Don't use certain kind(s) of images in North-American-related articles". Cédric wants to abolish "Convention №. 2" like abolishing slavery. 21:47, 21 March 2016 (UTC)
- @SMcCandlish: Glad to explain. Templates like {{Football squad start2}}, {{football squad player2}} are specially created for and are only used for in articles of North American association football teams. Certain users has argued that templates like {{Football squad start2}}, {{football squad player2}} are created so readers on mobile devices can access these pages more easily, but the way I see it, these templates (along with certain "conventions" like "Don't decorate captains in articles of North American association football teams") exists for promoting North American exceptionalism and little else.
- @Cendric than cantonais:: Please explain. What you've said doesn't mean anything concrete to most of us, especially since football squads (soccer teams, in American English) are little-known in North America, so the examples you provide don't seem to illustrate anything about "North America[n] exceptionalism". — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 06:43, 21 March 2016 (UTC)
- Support enabling by default. It's an extremely useful, time-saving feature. I've been using for many months in multiple browsers and OSes with no problems. Turning it off is trivial, finding and turning it on is not. WP cannot remain exactly the same "built in 2005" site forever. We are losing readers because of our shite interface and utility, and this is great improvement to it. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 06:43, 21 March 2016 (UTC)
- Conditional support. Looking at the survey above in this discussion, I think this feature is great for previewing articles because many people said they like it (301 participants), but some said they don't (52 participants). So, we would want to balance the needs of the majority of supporters to the few people who say they disagree with it. Therefore, The hoverboards should give a brief explanation of what they're, so they won't keep readers and editors wondering "What is that little popup"; Facebook uses a similar method when introducing new features, and also, they should clearly explain how to opt out of using this feature and to turn it back on as they wish because it can get a little bothersome to some readers and editors alike, as per some commentors above. Sam.gov (talk) 18:48, 21 March 2016 (UTC)
- Great idea. For anons, I guess it could work on the cookie basis; any that accept the cookie, and don't want the hovers can save that preference, and not lose if if their IP address changes, at least in theory. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 21:55, 21 March 2016 (UTC)
- Yes, but not now. Hovercards needs some tweaks before being rolled out by default, but I strongly support it being rolled out by default eventually. {{Nihiltres |talk |edits}} 21:22, 21 March 2016 (UTC)
- Support, but with the option to opt out easily delineated on each popup. Hovercards isn't perfect, but maybe we can implement an opt-in option first, then we can roll it out by default after the bugs are fixed. epicgenius (talk) 13:59, 22 March 2016 (UTC)
- Oppose. There is no need to force this feature on the users who find this feature annoying (and it looks like the number of such users is noticeable). Also, I suspect that seemingly the main argument of the supporters - that otherwise those other anonymous readers will not be able to use this feature without registering - seems to be outweighed by the fact that such state of affairs would gently encourage such users to register, and, perhaps, to start editing as well. For examle, I have also registered to get a "registered-only" feature (justified alignment). --Martynas Patasius (talk) 22:03, 23 March 2016 (UTC)
- Oppose - If the feature always performed as well as the display in the example screenshot of this proposal, enabling them would be something to discuss.—Godsy(TALKCONT) 07:27, 24 March 2016 (UTC)
- Oppose – Not for every user's taste, or CPU. A rather gratuitous add-on feature, not a core necessity, should be off by default. SteveStrummer (talk) 01:47, 25 March 2016 (UTC)
- Oppose It's not just the number of users on each side but the minor additional value for those who like it, and the major distration for those who do not. DGG ( talk ) 04:27, 25 March 2016 (UTC)
- Oppose As far as I remember, it was enabled my default, then I went and disabled it. I find hovercards useful. You know what, I'm gonna try it right now and decide. --QEDK (T 📖 C) 06:48, 25 March 2016 (UTC)
- Why does it have to pull a picture and there's no infobox information, just the lede. Random hovers are an issue but they're an issue on every website with hovercards enabled. It's going to work just fine on most articles but on ones with linked ones, it will definitely be annoying. Sometimes, the preview text is absolutely useless and the picture isn't useful in most cases either (it'd be good for animals and plants but those are very limited uses). --QEDK (T 📖 C) 06:57, 25 March 2016 (UTC)
- In the name of God, enable by default. Frankly, hovercards increase the quality of Wikipedia in that they are useful for obtaining information quickly and easily. As has been stated above, anyone who dislikes hovercards has the option to disable them, and those who do find them useful will be grateful of their existence. While there are a few problems (such as the inclusion non-free images, etc.), I see no great cause of concern over their activation. If anything, we can enable them sometime in the future when all of the bugs have been worked out, but personally, I feel they're just fine as is. Colonel Wilhelm Klink (Complaints|Mistakes) 16:43, 25 March 2016 (UTC)
- Don't you dare mess with the preferences of existing registered users. As for IPs, oppose, at least until the bugs are ironed out. BethNaught (talk) 22:15, 25 March 2016 (UTC)
- Comment I think the primary question here is about IP's and NEW accounts. I agree with BethNaught that changing existing editor preferences should not be on the table. For IPs, enabling by default and making it very easy to turn off is being proposed to solve the issue of discoverability for a feature that the majority of readers appear to like (when it was auto-enabled in Greek and Catalan). Without enabling the feature, we don't have a great way of allowing users to try it. There is no user preference area (solvable, but not easily) and, even if there was, there is no good way we have identified to help users discover this feature without showing them. Someone above mentioned running a central notice banner to inform users that it is an option, but this raises other issues--when do you turn the banner off, for instance? Do we turn it on 1 day a month in perpetuity? I am very interested in hearing suggestions, but tend to feel that allowing organice discovery when a user mouses over a link and then providing a very easy way to disable is the way forward. It seems that an easy path to disablement is the biggest issue. Maybe a blocker for rollout would be developing a dialogue on that first hover that shows users how to turn it off? Just an idea. Jkatz (WMF) (talk) 00:18, 26 March 2016 (UTC)
-
- I really liked Stanning's alternative proposal earlier of showing a hovercard once, and with it a dialogue asking whether the reader would like to continue using the feature. If no response, we would assume no and disable it. I also think the idea of a reader preference area deserves some looking into—if not for Hovercards, then for future add-on features. Ultimately that's what enabling and disabling these kind of features boils down to: preference. Wikipedia has enabled by default a host of these add-ons now—VisualEditor, Media Viewer, Reference Tooltips—and while it is possible to disable each even without a registered account, it would be easier if there were a centralized location for readers (i.e. unregistered users) to switch these on and off. It could also be a place to put beta features like Hovercards, in order to expose them to our readership (the ones who really matter). Mz7 (talk) 18:31, 29 March 2016 (UTC)
- Oppose. Screen clutter which should be opt-in only.--Smerus (talk) 09:03, 26 March 2016 (UTC)
- Support WP:ILikeIt. As an editor I find it useful for quickly telling if the link is correct. It also makes Wikipedia look more professional. AIRcorn (talk) 02:01, 27 March 2016 (UTC)
- Support, I've been using Hovercards for some time and I love it. Really improves my reader experience. --SSneg (talk) 09:44, 27 March 2016 (UTC)
- Strong Support For once, let's think of the readers. I've been using it for a while and it's one thing I really miss when I'm reading on my phone or other computers. It solves a major problem: clicking on links in running prose. When I'm reading an article on a subject I don't know a lot about, I can hover over a blue link, read a brief blurb to try and get the gist of the term, and keep going without having to open a new tab or leave the page. It makes reading and understanding text easier. Enabling by default will introduce a number of people who don't even know this exists to the feature and if they don't like it they can easily opt out. For IPs, it not only makes it easier for them to read and understand articles, but it also enhances our user experience and spurs innovation.
- I'm not convinced by these opposes of "screen clutter" or that it will encourage users to register. It's only screen clutter if you hover. If you don't hover on links, it doesn't clutter your screen. I'd be willing to say most registered users don't even know about this feature, so the idea that an unregistered user would find out about it and be so amazed by the feature that they make an account is not something I find hard to believe. For its bugs it is actually really stable in practice and having it enabled by default will probably get those bugs fixed even faster. I strongly believe that this feature will drastically improve the experience of anonymous readers, even if some editors find it suspect. We are an encyclopedia first, and this is a well designed feature that easily, minimally, and creatively solves a big problem readers have. If that harms your editing workflow, then opt-out, but I don't see why we should be blocking a useful feature because editors don't want to talk the 30 seconds to opt-out of it. Wugapodes (talk) 14:11, 27 March 2016 (UTC)
- Strong support per what Wugapodes said Common: how many experienced editors don't have navigational popups turned on? over 44,000, its our most commonly used opt-in gadget. Our readers would greatly benefit from that simple little bit of help finding the content. I can't believe we are making "clutter" arguments. The readers that are using desktop (an increasingly shrinking portion), are used to this kind of design in almost every other website -- lets not take our own IDONTLIKEIT arguments, to assume they apply for our readers. Sadads (talk) 13:57, 28 March 2016 (UTC)
Accessibility
Please can someone point us to the accessibility impact assessment for hovercards, showing their effect on people with disabilities, and/ or those using assistive software? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:57, 28 March 2016 (UTC)
We should not accept pictures with pixelated people's faces
- 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.
Across Wikipedia there are articles that display pictures that show people with pixelated faces in public places. I think we shouldn't accept such pictures for display in encyclopedic articles. It's anti-journalistic to pixelate people's faces in photos of public places. An encyclopedia shouldn't accept such pictures. I propose to find replacements for such pictures or remove them and make a policy to not accept any future such pictures. Mark Urzimo (talk) 17:30, 18 March 2016 (UTC)
- Assuming these are user contributed pictures (eg taken themselves), of people in clearly public places, and they are being used to demonstrate the public place or general activity shown (an educational use rather than one that is purposely aimed to defame a person involved), then yes, pixelation should not be done. There's no legal issues as there is no expected right of privacy in a clearly public, outdoor location. If there is an object meant to be the focus of the picture and not the people, efforts can be made to trim down to just that object but pixelation is not an option required. --MASEM (t) 17:43, 18 March 2016 (UTC)
- If one does not want a picture in an article than replace it with something better (or discuss it on the talk page) - it's as simple as that but no, it's CREEP to make a rule about it. Alanscottwalker (talk) 17:48, 18 March 2016 (UTC)
- Pixelation is not generally required, but no argument is present to explain why it should be universally banned. If a photographer wishes to protect the privacy of private individuals beyond the minimum standards required by law, I'm having trouble seeing the harm. If any image in Wikipedia can be replaced by an image of higher quality and educational value, of course we should do so—but whether or not faces are blurred or pixelated should not be the sole (or even most important) criterion. TenOfAllTrades(talk) 17:54, 18 March 2016 (UTC)
- However, this is an issue related to reuse , and similar in problem to watermarking a free image. When there are no issues with privacy rights (again, pictures of people in open public spaces), pixelating faces is only a matter of courtesy but is not required at all, just as watermarking is not required if you are donating images freely. We don't want massive post-photo editing to take place (outside of cropping and rotation), so that we do have the most reusable content possible. --MASEM (t) 17:58, 18 March 2016 (UTC)
- Well, if people want to reuse an image with a pixilated face, they will reuse an image with a pixillated face. So, there is no problem there. Alanscottwalker (talk) 18:24, 18 March 2016 (UTC)
- However, this is an issue related to reuse , and similar in problem to watermarking a free image. When there are no issues with privacy rights (again, pictures of people in open public spaces), pixelating faces is only a matter of courtesy but is not required at all, just as watermarking is not required if you are donating images freely. We don't want massive post-photo editing to take place (outside of cropping and rotation), so that we do have the most reusable content possible. --MASEM (t) 17:58, 18 March 2016 (UTC)
- On a related note, it's been awhile but I vaguely recall a recognizable child image discussion or rule. Alanscottwalker (talk) 18:42, 18 March 2016 (UTC)
NOTE: This talk page edit indicates that Mark Urzimo seems to be referring to the article Rapid transit. I can find no images in there with deliberate pixelation. What I did find were some images with motion blur. Lower quality images should of course be replaced with higher quality images. Articles such as Rapid transit with too many images should certainly have lower quality unneeded images trimmed away. Just be careful not to remove images depicting something significant. A somewhat blurry image, or an image that is otherwise less than ideal, should still be included if it's showing something relevant for the article and there is no better image available. Alsee (talk) 20:08, 18 March 2016 (UTC) P.S. I just saw that Mark has just joined us as a new editor (no article edits yet). I left a welcome template and image-specific editing advice on user_talk. Welcome to Wikipedia Mark! :) Alsee (talk) 20:51, 18 March 2016 (UTC)
- oppose It may not be required to pixilate or otherwise obscure the faces of people who are incidentally included in a picture of a public place, but if the photographer or uploader chooses to do so, I see no reason to object. If some other person wants to take a replacement photo and upload it under a free license, it could replafce the first if and only if it is judged to be of higher overall quality. I see no valid reason behind a policy or guideline barring such images, and i object to it. DES (talk) 00:00, 19 March 2016 (UTC)
- Oppose. No need for such a requirement. That said, responding to User:DESiegel's point, I would say that if we had both versions of the same photo, with the only difference being pixellation, the non-pixellated one is ipso facto almost always going to be "higher overall quality". Still, the uploader is not required to provide the photo at all, so if the only one he/she is willing to provide is the pixellated one, then I don't see why we shouldn't be able to say we prefer that to nothing at all. --Trovatore (talk) 00:13, 19 March 2016 (UTC)
- That might be, Trovatore, although some might argue that the courtesy of pixilation, while not required, is an improvement. But in practice an offered replacement will normally not be identical except for pixilation -- it will be different, perhaps of better quality, perhaps not as good except for the absence of pixilation. A rule that would force acceptance of a lower quality image just to avoid pixilation (as the above proposal seems to) is not on. DES (talk) 00:23, 19 March 2016 (UTC)
- Well, I would tend to consider pixellation to be a fairly significant intrinsic flaw in a photo. Certainly it's possible that it would be so much better in other ways than a non-pixellated one that on balance it would be considered preferable, but for me it would have to be noticeably better in other ways. Certainly editors can differ on this point and I don't see any need to make an encyclopedia-wide judgment on it at this time. --Trovatore (talk) 05:29, 19 March 2016 (UTC)
- That might be, Trovatore, although some might argue that the courtesy of pixilation, while not required, is an improvement. But in practice an offered replacement will normally not be identical except for pixilation -- it will be different, perhaps of better quality, perhaps not as good except for the absence of pixilation. A rule that would force acceptance of a lower quality image just to avoid pixilation (as the above proposal seems to) is not on. DES (talk) 00:23, 19 March 2016 (UTC)
- Oppose - I don't think I've ever seen a pixilated image on here..., Anyway If for instance a picture is taken of a BLP with a fan then the image gets cropped thus only showing the BLP, IMHO Images shouldn't
everbe pixilatedfull stop, It's like the idiots who blur car registrations at Commons ... utterly pointless .... Anyway that's way offtopic, Anyway no need for pixelating anything.–Davey2010Talk 05:51, 19 March 2016 (UTC)
-
- to be clear, Davey2010, you think images should not be pixelated / blured, but you also think we should not forbid any pixelated images (that is, we should replaced them, as possible)?
- Hi Nabla, Sorry I should've been clearer - but yep spot on - If there is a pixelated image then nope it shouldn't be deleted "just because it's pixelated" and yep it should be replaced but if there's nothing better available then the pixelated one should be left up, Thanks, –Davey2010Talk 15:30, 19 March 2016 (UTC)
- to be clear, Davey2010, you think images should not be pixelated / blured, but you also think we should not forbid any pixelated images (that is, we should replaced them, as possible)?
- Oppose. If the image is still informative, why delete? Surely, if we can get a better looking one (non pixelated image is certainly a improvement in that), then, by all means, replace it. - Nabla (talk) 12:03, 19 March 2016 (UTC)
- As per the above, pixellation should be considered a flaw in the image, but if that remains the best (or only) free image we have available, and even with the pixellation it represents the subject appropriately well, we should use it until a better one comes along. As soon as such a better free image does happen along, of course, we should then replace the pixellated image with the superior one. I think it should be generally discouraged and should be considered a serious image flaw, but not flat-out banned. Seraphimblade Talk to me 15:50, 19 March 2016 (UTC)
- Oppose So what? If the image is free to use it is free to use, don't like it - replace it. — xaosflux Talk 16:44, 19 March 2016 (UTC)
- Oppose Hamid Hassani (talk) 16:51, 20 March 2016 (UTC)
- Oppose the fact that faces are pixellated in a photo is irrelevant when those faces are not the intended subject of the photo. If a notable subject provides a photo of themself with their child sitting on their lap I see no problem at all with the child's face being obscured, in fact it is in line with our presumption of privacy rules. Similar obscuring of vehicle licence plates is also regularly done in in media. Roger (Dodger67) (talk) 18:10, 20 March 2016 (UTC)
- Oppose: The photos violate no policy, but censoring them off of WP would. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 07:00, 21 March 2016 (UTC)
- Oppose I don't see how pixelating is "anti-journalistic" when journalistic ethics require pixelation in many cases. It could also be preferred under our WP:BLP. Whether it is unencyclopaedic depends solely on the information content. Hawkeye7 (talk) 03:42, 22 March 2016 (UTC)
Move to CLOSE per SNOW. GenQuest "Talk to Me" 13:52, 22 March 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.
Suggested languages template
Would it be possible to provide an easy alternative mechanic for populating the 'Languages' field to the left of an article page? For example, I'd like to be able to post a template to the talk page where I can suggest a list of alternate language Wikipedia articles. Those who have an interest can then take the suggestions, verify them, and use the URLs to populate the Languages list for the article. (I personally have no interest in wrestling with that arcane system; I'd rather spend my time writing and editing articles.) Thank you. Praemonitus (talk) 21:53, 21 March 2016 (UTC)
-
- I believe that the old system still works, and that a bot (still?) comes around to transfer the results to Wikidata. That means that you can place an old-fashioned interlanguage link at the very end of the page to create the link you want. This uses the form
[[xx:Article title]]
, where "xx" is the language code (e.g., "de" for de.wikipedia.org, "bar" for bar.wikipedia.org, etc.) and "Article title" is the exact article title at the other Wikipedia (e.g., "Hauskatze" or "Hauskotz", for Cat). WhatamIdoing (talk) 18:56, 22 March 2016 (UTC)- Yes, old system still works (also the part about bots). --Edgars2007 (talk/contribs) 18:59, 22 March 2016 (UTC)
- Okay, I'll give that a try. Thank you both. Praemonitus (talk) 21:36, 22 March 2016 (UTC)
- Yes, old system still works (also the part about bots). --Edgars2007 (talk/contribs) 18:59, 22 March 2016 (UTC)
- I believe that the old system still works, and that a bot (still?) comes around to transfer the results to Wikidata. That means that you can place an old-fashioned interlanguage link at the very end of the page to create the link you want. This uses the form
Consensus Talk Index (CTI) idea
- NOTE: I moved this discussion over to Wikipedia:Village_pump_(idea_lab)#Consensus_Talk_Index_.28CTI.29_idea since WP:VPI is apparently the correct place to incubate new ideas. @Fritzmann2002: your comment was moved as well, just fyi. Koala Tea Of Mercy (KTOM's Articulations & Invigilations) 06:38, 24 March 2016 (UTC)
RFC: Corrections on Main Page?
The Main Page sometimes has factual errors (mainly on WP:DYK, also in other sections). At the moment, these get quietly corrected or removed, but no acknowledgment of this is being made. Similarly to what happens with e.g. newspapers (Correction (newspaper)), we could make a note of factual errors we featured on the Main Page in either the same spot (so a DYK error gets noted in the DYK section of the main page) or in a separate section on the Main Page. This should only be done for facts, not for grammatical errors, capitalization changes and the like. This was recently done a few times, but met with mixed reactions. How exactly this should be done is not really important, first we need to agree on whether this is wanted or not. Fram (talk) 10:42, 23 March 2016 (UTC)
(Note: this is not intended for ITN items which were correct at the time of posting but were outdated at some time: this is not an error but normal progression of events). Fram (talk) 10:46, 23 March 2016 (UTC)
Examples: A possible approach to such a correction, or this one (that one wasn't a Beatles recording, only Harrison was involved). (these were added after the first two comments below were made) Fram (talk) 14:09, 23 March 2016 (UTC)
- I think how we do things now is fine. Most of the items which come up for discussion at WP:ERRORS are ephemeral anyways, and most changes are minor differences of wording or updates of changing or fluid situations. --Jayron32 11:47, 23 March 2016 (UTC)
- The main problem with the main page currently is that the disclaimer is buried at the bottom in fine print. It should be made more prominent as it's our general position that that any of our content might be wrong. Publishing corrections should only be done when the error or issue is important as it is quite easy to nitpick details. For example, the blurb for yesterday's FA said, "The animals lived for at least 12 to 20 years..." This is erroneous because some of these creatures died young while at least one specimen was found to have reached age 27. But the exact range of lifespans of creatures that have been extinct for millions of years is not a big deal and argument about the best wording for our tentative knowledge of them is likely to be protracted. What might help is having WP:ERRORS turned into a noticeboard with the usual structure of topical sections, archives and the like. Currently WP:ERRORS is too emphemeral and this makes it quite poor at handling issues which would benefit from some continuity, history and discussion. Andrew D. (talk) 13:46, 23 March 2016 (UTC)
- One possible solution is that the error gets removed or corrected, but that a correction only gets posted at the next update (FA or DYK mainly) after a discussion at WP:ERROR. That could avoid corrections for every minor problem, or corrections to corrections, and so on. Fram (talk) 14:11, 23 March 2016 (UTC)
- Having the general disclaimer buried at the bottom in fine print doesn't mean that it doesn't get found. Just look at the amount of rubbish that gets posted to its talk page. Same thing happens with other links "buried at the bottom in fine print" like Wikipedia talk:About and Wikipedia talk:Contact us. --Redrose64 (talk) 21:23, 23 March 2016 (UTC)
- The general disclaimer page gets about 5000 hits per day. That's about the same as a mediocre DYK, which isn't much. Consider that this page appears not just at the foot of the main page but at the foot of every page. Hardly any of our readers are clicking on the link. One reason for that is that the link is blandly bureaucratic and boring. If, instead, every page said Wikipedia is not reliable!, it might get more attention. Andrew D. (talk) 21:54, 23 March 2016 (UTC)
- Having the general disclaimer buried at the bottom in fine print doesn't mean that it doesn't get found. Just look at the amount of rubbish that gets posted to its talk page. Same thing happens with other links "buried at the bottom in fine print" like Wikipedia talk:About and Wikipedia talk:Contact us. --Redrose64 (talk) 21:23, 23 March 2016 (UTC)
- One possible solution is that the error gets removed or corrected, but that a correction only gets posted at the next update (FA or DYK mainly) after a discussion at WP:ERROR. That could avoid corrections for every minor problem, or corrections to corrections, and so on. Fram (talk) 14:11, 23 March 2016 (UTC)
- Oppose We are a website, not a printed source. A newspaper cannot edit already sold papers. And we have five million articles where lots of errors are found and corrected. The main page gets a lot of views and hopefully has fewer errors than average articles but I still don't see good reason to single it out and point out already corrected errors unless they are directly harmful, and I don't recall cases of that on the main page. PrimeHunter (talk) 14:35, 23 March 2016 (UTC)
- The reason to single out the main page is that unlike other pages, it gets heavily scrutinized before anything is posted there and shouldn't contain any serious errors. It's not the part that anyone can edit, with all advantages and disadvantages that has, but the part that we (the community) choose explicitly to highlight, to showcase. That may of course not be enough for you to consider supporting this, and I don't intend to badger all opposes, but I just wanted to indicate why I do see good reasons to single it out. Fram (talk) 14:51, 23 March 2016 (UTC)
- Weak oppose, per PrimeHunter above. Rehman 14:46, 23 March 2016 (UTC)
- While I think reminding people that Wikipedia is full of errors is a good idea (there was something good about the time when the wiki was full of harmless vandalism of the "Kusma is gay! tell everyone!" variety, as that served as a reminder that Wikipedia is edited by random people and not always accurate), I don't like having extra policies for errors on the Main Page as opposed to errors in the content everywhere else. The main problem I see here is that it took more than two hours until the problem was corrected, which is embarrassingly long and probably something to point out whenever somebody opposes a good faith editor at WP:RFA. WP:ERRORS is one of the more urgent admin areas. —Kusma (t·c) 15:09, 23 March 2016 (UTC)
- Actually, more than 6 hours in that instance between reporting and correction. Getting errors off the main page (by correction or removal) is of course more important, and shouldn't wait until a correction has been written; it should be consecutive processes, with the error handling not dependent on the addition (or not) of a correction. Fram (talk) 15:14, 23 March 2016 (UTC)
- Oppose. Primarily because I don't see an actual point. Resolute 19:15, 23 March 2016 (UTC)
- Weak support I can see this helping the accuracy and transparency of Wikipedia. My main concern would be the implementation, but I'm open to a trial run to see whether there is any way of doing this. Jolly Ω Janner 19:49, 23 March 2016 (UTC)
- Oppose except where BLP issues are involved. For the most part, the readers who saw the error won't be likely to see the correction. עוד מישהו Od Mishehu 20:56, 23 March 2016 (UTC)
- Support A few years ago I would have agreed with the oppose arguments. However, it now seems to be standard practice on the web to indicate how a news story or other posting has been corrected, in the interest of fuller transparency. It is not a question of who might or might not see it, or what type of website we like to think we still are. It's a matter of principle; we may find ourselves behind the curve sooner than we think. Daniel Case (talk) 21:09, 23 March 2016 (UTC)
- Oppose it's not clear what errors qualify for main page "corrections". It's not clear how the demonstration of such errors fits into the main page design considering that errors can occur in every panel of the main page. There may be a case for a "Corrections" page which can be linked from the main page somewhere so we can confess our sins, but given today's little outburst, it's clear that "disclaimers" will be as erroneous as the errors they are attempting to disclaim. This is not path we need to tread, all articles in Wikipedia are subject to errors, after all. The Rambling Man (talk) 21:25, 23 March 2016 (UTC)
- Support I like this idea, and I agree with Daniel Case that this is a common practice that we should be adopting. Of course, my general opinion is that we put an enormous amount of volunteer effort into selecting and assembling content for main-page visitors who are mostly indifferent to it, and we'd be far better off coming up with alternative, more targeted processes of serving curated content to those likely to be interested in it. But given that we have what we have, I think we should be transparent about our errors and use the opportunity to highlight the wiki process. Opabinia regalis (talk) 21:55, 23 March 2016 (UTC)
- Oppose Errors can occur anywhere. We work on a basis of making corrections as we go. Hawkeye7 (talk) 22:03, 23 March 2016 (UTC)
- Oppose due to the nature of Wikipedia, errors are commonplace. We don't acknowledge previous errors on other articles, not even BLPs. The main page should not be an exception. SSTflyer 07:51, 24 March 2016 (UTC)
- Oppose - Once something is printed or published electronically by a reputable news organization, it isn't expected to change. Wikipedia articles on the other hand are fluid and change is an expectation.
By enshrining the errors within a certain version because it appeared prominently almostWe shouldn't give the impression that we are holding our articles to the publishing standards of organizations who employ correction (newspaper), which we cannot due to the nature of the project.Errors both big and small can exist, and unless we have a body of volunteer scrutinizers to check articles (which begs the question why not preemptively do it),We already reasonably scrutinize the text before it appears on the main page, so if there is an error it might not be discovered or brought to light until much later.In that case more than likely individuals won't check to see if it was present in the version that was linked on mage page (in the unlikely case they even know or remember it has been there) when it is corrected, and the "correction acknowledgment notice" would fail to have listed it(unless there was to be atime limit to catch errors?). Furthermore, consensus would be needed on which errors to report (along the lines of which items to include in the news section). Obviously errors like falsely stating someone was a suspect in a notable assassination attempt nature would be reportedif linked on the main page, but what about smaller factual errors. How long would an error within the text have to be live if it is corrected during the day to warrant a noticeit is linked on the main page?This proposal would probably increase the rate of complex non-factual information being purposely introduced to the pages slated to be displayed there (or planted long before that then nominated) by malevolent editors with the goal of "making the correction acknowledgment notice".Lastly, maintaining a "correction acknowledgment notice" along with the other processes I've described above adds more non-essential work for our volunteers, who could instead be improving encyclopedia articles. Interesting idea, I liked it before I thought to hard about it.—Godsy(TALKCONT) 08:38, 24 March 2016 (UTC)- The proposal is not for errors in the articles linked to from the main page, only for errors actually put on the main page (e.g. for DYK, only errors in the one-line hook would apply, not all errors elsewhere in these articles). All texts put on the main page are already vetted extensively by editors here (through the FA process or the DYK process), so your question about the preemptive vetting is besides the point. Fram (talk) 09:24, 24 March 2016 (UTC)
- Comment: many people compare the main page to other pages, where no corrections are indicated. There are of course a few major differences, including the lack of history on the main page (it is relatively easy to see when an article stated version X or version Y of the truth; it is much harder for most people to find when the main page said X or Y, as it exists of transcluded subpages with different names). Articles are pages "anyone can edit", with the inbuilt risk that they will contain errors. The Main Page is not a page anyone can edit, but a severely restricted and vetted one. This of course doesn't mean that one should support this proposal, but I don't think that only opposing this because we don't do this on articles, is really a sufficient argument ("we have references on all articles, we should have them on the main page as well" would be a comparable reasoning, which I think many of you would oppose). Fram (talk) 09:24, 24 March 2016 (UTC)
- Oppose, per WP:NOT#PAPER and WP:NOT#NEW. Newspapers publish retractions and paper book publishers include errate sheets because they can't correct the extant copies. That does not apply here; we simply issue a corrected "edition" instantly. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 11:18, 24 March 2016 (UTC)
- Comment it would be worth adding a "correction" notice to the talk page of DYKs, for instance, that have suffered major issues and still been on the main page, after all the "DYK" hook is usually added within a template to the article talkpage. It would be easily traceable to add a "correction" parameter to this, or simply add a "Correction" section to the talkpage. The Rambling Man (talk) 11:22, 24 March 2016 (UTC)
- Oppose. We already know where these errors are coming from, this will do nothing to address the underlying issues. Gamaliel (talk) 14:59, 24 March 2016 (UTC)
- Oppose. What concerns me mainly about this proposal is that it would essentially create what amounts to a "DYK shame file" on the front page which would give incentive to those users opposed to DYK to find fault with DYK hooks and/or the underlying articles in order to add hooks to the file. Disputes over content and processes occur all the time on Wikipedia, the front page is not the place for them. Gatoclass (talk) 16:38, 24 March 2016 (UTC)
- DYK is its own shame file sometimes already, this wouldn't change a lot about that. As has been said before, errors in the underlying articles have nothing to do with this proposal. This is about errors (not "finding faults with", but "finding factual errors in"). No idea why you add "disputes over processes", perhaps for the same reason you added "the underlying articles" to your oppose. Still, after your recent comments at WT:DYK, I'm not amazed about these inaccuracies, I just hope not to many uninvolved editors believe them. Fram (talk) 19:56, 24 March 2016 (UTC)
-
-
- So, you've never pulled a DYK hook because of issues with the article? It's hardly as if this were an unknown event, so yes, hooks and the underlying articles. With regard to "disputes over processes", what I'm saying is that the main page is not a place for pursuing them, which I fear is what would occur if this proposal were to be adopted. Gatoclass (talk) 08:43, 25 March 2016 (UTC)
- I can't recall pulling a DYK hook from the main page for issues with the article, no. But I may have done, if the article needed deletion as a hoax or if the hook segment in the article was a copyvio or some such problems. But it's a strawman argument anyway, as it doesn't address what I said or what this proposal is about. If a DYK would get pulled for copyvio problems, no correction would need to be put on the main page, and I didn't suggest this. And if a DYK would get pulled for being about a hoax article, the DYK hook would obviously be incorrect and a correction for such an egregious mistake wouldn't be a bad thing anyway. So no, feel free to repeat it as often as you like, but definitely not about the underlying articles. Fram (talk) 10:32, 25 March 2016 (UTC)
- Okay, have it your own way. But I still say the main page should not be used as a political football. And in any case, I think this proposal is completely impractical, would require a lot of discussion about procedure, would burden DYK with more bureaucracy, reducing the time spent on quality control itself and discouraging participation, and achieve very little, given that DYK hooks are only ever displayed for a few hours - removed hooks even fewer - and that most DYK errors are incredibly trivial, such as whether game controller x was first used in game y on platform z in 1999, or not. Gatoclass (talk) 11:05, 25 March 2016 (UTC)
- Funny, it is important enough to put on the Main Page that Game X was the first to require Controller Y, but when that information is incorrect, it is suddenly "incredibly trivial". Considering that the majority of DYK hooks is of comparable triviality, perhaps we should just get rid of it? That would free up time for quality control in all articles and remove lots of bureaucracy and problems. But I have the feeling that that is not what you had in mind when you wrote the above. Fram (talk) 11:36, 25 March 2016 (UTC)
- On the contrary, I have never denied that many DYK hooks deal with trivia, and I'm not bothered by it, because DYK is not about finding a bunch of portentous facts, but about demonstrating that Wikipedia is an ever-expanding knowledge base on the widest possible variety of topics. You, by contrast, like on the one hand to disparage DYK on the basis that it deals with trivia, but on the other apparently expect the community to have conniptions over the fact that a small percentage of the trivia featured might on occasion be erroneous. Gatoclass (talk) 12:34, 25 March 2016 (UTC)
- (on second thoughts, forget it. I'm done with replying to your wild accusations time and time again. People who follow DYK without seeing DYK as a goal in itself will know my real objections against it (which is not triviality), the amount of errors, and the amount of those I catch after they have been approved but before they hit the mainpage as well. Those things are more telling than whatever you may come up with next. Fram (talk) 13:12, 25 March 2016 (UTC) )
- On the contrary, I have never denied that many DYK hooks deal with trivia, and I'm not bothered by it, because DYK is not about finding a bunch of portentous facts, but about demonstrating that Wikipedia is an ever-expanding knowledge base on the widest possible variety of topics. You, by contrast, like on the one hand to disparage DYK on the basis that it deals with trivia, but on the other apparently expect the community to have conniptions over the fact that a small percentage of the trivia featured might on occasion be erroneous. Gatoclass (talk) 12:34, 25 March 2016 (UTC)
- Funny, it is important enough to put on the Main Page that Game X was the first to require Controller Y, but when that information is incorrect, it is suddenly "incredibly trivial". Considering that the majority of DYK hooks is of comparable triviality, perhaps we should just get rid of it? That would free up time for quality control in all articles and remove lots of bureaucracy and problems. But I have the feeling that that is not what you had in mind when you wrote the above. Fram (talk) 11:36, 25 March 2016 (UTC)
- Okay, have it your own way. But I still say the main page should not be used as a political football. And in any case, I think this proposal is completely impractical, would require a lot of discussion about procedure, would burden DYK with more bureaucracy, reducing the time spent on quality control itself and discouraging participation, and achieve very little, given that DYK hooks are only ever displayed for a few hours - removed hooks even fewer - and that most DYK errors are incredibly trivial, such as whether game controller x was first used in game y on platform z in 1999, or not. Gatoclass (talk) 11:05, 25 March 2016 (UTC)
- I can't recall pulling a DYK hook from the main page for issues with the article, no. But I may have done, if the article needed deletion as a hoax or if the hook segment in the article was a copyvio or some such problems. But it's a strawman argument anyway, as it doesn't address what I said or what this proposal is about. If a DYK would get pulled for copyvio problems, no correction would need to be put on the main page, and I didn't suggest this. And if a DYK would get pulled for being about a hoax article, the DYK hook would obviously be incorrect and a correction for such an egregious mistake wouldn't be a bad thing anyway. So no, feel free to repeat it as often as you like, but definitely not about the underlying articles. Fram (talk) 10:32, 25 March 2016 (UTC)
- So, you've never pulled a DYK hook because of issues with the article? It's hardly as if this were an unknown event, so yes, hooks and the underlying articles. With regard to "disputes over processes", what I'm saying is that the main page is not a place for pursuing them, which I fear is what would occur if this proposal were to be adopted. Gatoclass (talk) 08:43, 25 March 2016 (UTC)
-
- Oppose - Serves no purpose. We already have Wikipedia:Main Page/Errors. — Maile (talk) 18:32, 24 March 2016 (UTC)
- That page is for readers to contact us (editors) to correct a page. This proposal is for the reverse, to let the readers know that despite our vetting, we posted incorrect information on the main page. Which you are free to oppose, of course, but confusing things doesn't help. Fram (talk) 19:56, 24 March 2016 (UTC)
- Support assuming it's not ugly or intrusive. I think it'd be a service to readers to let them know when they have been accidentally misinformed. --Jakob (talk) aka Jakec 19:27, 24 March 2016 (UTC)
- Support; above all, Wikipedia is a source for information, and any incorrect information which is distributed by Wikipedia should be corrected. Because of the high traffic volume of the main page, a mistake there carries more weight than a mistake elsewhere, and should be treated thusly. Something along the lines of the first of Fram's two examples above appeals to me; a small notation under the day's DYK's is nonintrusive yet useful. Colonel Wilhelm Klink (Complaints|Mistakes) 21:41, 24 March 2016 (UTC)
- Support Noting that online editions of newspapers do include corrections. As the possible negative impact on living persons where incorrect contentious claims have been made are clearly significant, and as WP:BLP avers that we must avoid damage to living persons, any error which might improperly affect living persons should be corrected with the same visibility as was given the incorrect claim or information. For matters of "how old was the fossil" - such errata are of far less importance, but where specific living persons are concerned, I find the "but facts are of minor value" position to be wrong. Collect (talk) 23:25, 24 March 2016 (UTC)
- Oppose. My opinions on the main page's accuracy issues are fairly well known, and I'd seriously consider abolishing the MP altogether and replacing it with www.wikipedia.org given the amount of hassle it causes for dubious benefit. That said, I agree with every word of I still say the main page should not be used as a political football. And in any case, I think this proposal is completely impractical, would require a lot of discussion about procedure, would burden DYK with more bureaucracy, reducing the time spent on quality control itself and discouraging participation, and achieve very little, given that DYK hooks are only ever displayed for a few hours - removed hooks even fewer - and that most DYK errors are incredibly trivial, such as whether game controller x was first used in game y on platform z in 1999, or not above. ‑ Iridescent 11:29, 25 March 2016 (UTC)
- Then please see my reply above to that statement. The DYK errors are just as incredibly trivial as the DYK hooks, so arguing that the corrections should not be displayed is basically an argument that the hook should not have been displayed in the first place. Which goes back to your first argument of course (which has considerable merit), but is hardly a reason to oppose posting corrections as long as we are stuck with DYK. Fram (talk) 11:39, 25 March 2016 (UTC)
- You know my opinion of DYK, which I consider an embarrassment to Wikipedia, but in practice it's kept as a recruiting tool ("if you write an article, we'll showcase it on the main page") and virtually nobody actually reads the things. (The MP gets about 15-20 million hits per day, and the DYK project considers it noteworthy if a DYK gets over 5000 hits.) Publishing "errata slips" would be a time-consuming and open-ended undertaking for minimal benefit, since in practice nobody cares. The BLP issue is something of a strawman, given that while there certainly have been libellous statements about living people made it onto the MP, I could probably count the instance since the MP was instituted in 2004 on the fingers of one hand; the typical MP error is more along the lines of "you say the Sikorsky S-51 helicopter was built for civilian use but they were actually used primarily by the military"; a rolling log of this kind of correction would be of no interest to anyone, and just add to the already cluttered main page. In the unlikely event of a genuinely serious error, a retraction could be published on the MP if deemed appropriate, but that is already the case, and I don't see what's gained by just adding to the clutter to make statements like "On 10 March, we posted that the Devanahalli pomelo is the world's largest citrus fruit. However, this statement is not verifiable in the sources provided." other than as a stick with which to beat the repeat offenders at DYK. (It could also offer a perverse incentive to introduce errors, by those trying to boost pageviews, since published corrections would mean the item appearing on the main page for a second time.) ‑ Iridescent 12:18, 25 March 2016 (UTC)
- Okay! Fram (talk) 12:21, 25 March 2016 (UTC)
- What I certainly would support is a three-strikes system at DYK, where any nominator who has three substantive "this hook is not true" complaints against them upheld is banned from DYK. I don't think I'm giving away any great secret in saying that a couple of editors are responsible for a disproportionate amount of the fabrications and mis-citations that get into DYK,* but AGF discourages people from calling them out on it because of the inevitable backlash from the regulars closing ranks. ‑ Iridescent 15:27, 25 March 2016 (UTC)
*Once as an exercise, I went through one of the worst offenders's articles line-by-line annotating every untrue statement, claim not supported by the source, use of inappropriate sources, improper synthesis and even a citation to a novel as if it were fact. This was an extreme case, but not extreme enough as to be unique. ‑ Iridescent 15:27, 25 March 2016 (UTC)
- What I certainly would support is a three-strikes system at DYK, where any nominator who has three substantive "this hook is not true" complaints against them upheld is banned from DYK. I don't think I'm giving away any great secret in saying that a couple of editors are responsible for a disproportionate amount of the fabrications and mis-citations that get into DYK,* but AGF discourages people from calling them out on it because of the inevitable backlash from the regulars closing ranks. ‑ Iridescent 15:27, 25 March 2016 (UTC)
- Okay! Fram (talk) 12:21, 25 March 2016 (UTC)
- You know my opinion of DYK, which I consider an embarrassment to Wikipedia, but in practice it's kept as a recruiting tool ("if you write an article, we'll showcase it on the main page") and virtually nobody actually reads the things. (The MP gets about 15-20 million hits per day, and the DYK project considers it noteworthy if a DYK gets over 5000 hits.) Publishing "errata slips" would be a time-consuming and open-ended undertaking for minimal benefit, since in practice nobody cares. The BLP issue is something of a strawman, given that while there certainly have been libellous statements about living people made it onto the MP, I could probably count the instance since the MP was instituted in 2004 on the fingers of one hand; the typical MP error is more along the lines of "you say the Sikorsky S-51 helicopter was built for civilian use but they were actually used primarily by the military"; a rolling log of this kind of correction would be of no interest to anyone, and just add to the already cluttered main page. In the unlikely event of a genuinely serious error, a retraction could be published on the MP if deemed appropriate, but that is already the case, and I don't see what's gained by just adding to the clutter to make statements like "On 10 March, we posted that the Devanahalli pomelo is the world's largest citrus fruit. However, this statement is not verifiable in the sources provided." other than as a stick with which to beat the repeat offenders at DYK. (It could also offer a perverse incentive to introduce errors, by those trying to boost pageviews, since published corrections would mean the item appearing on the main page for a second time.) ‑ Iridescent 12:18, 25 March 2016 (UTC)
- Then please see my reply above to that statement. The DYK errors are just as incredibly trivial as the DYK hooks, so arguing that the corrections should not be displayed is basically an argument that the hook should not have been displayed in the first place. Which goes back to your first argument of course (which has considerable merit), but is hardly a reason to oppose posting corrections as long as we are stuck with DYK. Fram (talk) 11:39, 25 March 2016 (UTC)
- Oppose per Primehunter. Most DYK errors are not egregious enough and do not receive enough complaints from people to warrant special notice on the main page, especially since they are quickly corrected. If for some reason it does, a special case could be made, but I find that situation unlikely. I would instead suggest that stronger fact-checking is done during the nomination process to prevent this situation from occurring in the first place. ZettaComposer (talk) 14:11, 25 March 2016 (UTC)
- Oppose although I get where Fram is coming from. Not only is running a corrections column going to take extra editor work as well as valuable real estate on the Main Page, it really advertises shameful inaccuracies instead of being transparent with the reader. I agree with Andrew D that the disclaimer need to be far more prominent. Instead, why don't we hand out one-day blocks of editors responsible for these errors making it to the Main Page? Like Iridescent's three strikes concept, the editor is banned from those processes (DYK, ITN, etc.) where they've proven incompetent. Let's cure the disease (inaccuracy causing reader unhapiness) rather than treat the symptom (mollifying readers thru Mea culpa). Chris Troutman (talk) 15:35, 27 March 2016 (UTC)
- Support. I think that if a statement appears on the Main Page but is determined to be incorrect, it would be appropriate to post a correction on the Main Page, in hopes that the truth will reach as many people as the false statement did. Blocking the editors responsible for the incorrect information may be an appropriate punishment, but it doesn't by itself promulgate the correction. --Metropolitan90 (talk) 05:34, 28 March 2016 (UTC)
- Support If the Main Page is run like a newspaper, then why not have corrections as well? Obviously some people are reading the DYKs. If the facts are in error, then we should attempt to inform those readers of the error. I also would support either a three strike or block policy for those responsible. FuriouslySerene (talk) 14:09, 29 March 2016 (UTC)
Displaying pronunciatiin of a word in regional language
Hello Friends, I would like to suggest to Display pronunciation of the word searched by user in regional language, like in India, Regional language is Hindi or Marathi.
For Ex. consider a word Revoke so while displaying on wikipedia page as
Revoke ( रिवोक )
This will help reader to know the correct pronunciation of the word.— Preceding unsigned comment added by PGAwade (talk • contribs)
- There's too many languages to do that, and many local languages cannot accurately represent sounds in other languages. Many articles do feature the International Phonetic Alphabet pronunciation, which is meant to be language neutral (in other words, anyone who speaks any language who learns how to read the IPA can use it to pronounce any word). Ian.thomson (talk) 04:03, 24 March 2016 (UTC)
- Strongest possible oppose This is the ENGLISH Wikipedia. We should never, ever have text in languages other than English except for cases like the native names of proper nouns. Also, in your example, there's nothing at all that would make Hindi or Marathi special with regards to the term "revoke", so the only way we could fairly do that would be for every word to be accompanied by hundreds of languages' worth of pronunciations. Jackmcbarn (talk) 20:49, 28 March 2016 (UTC)
- User:PGAwade, may I suggest that this idea is far more appropriate for wiktionary? That said, I suggest that you learn IPA (IPA for English should help) and use those pronunciations where available. Oiyarbepsy (talk) 04:33, 29 March 2016 (UTC)
2 proposals
- A High lighter for app and signed in users for studying and to mark cool things.
- I was studying English authors and I came across these common errors (mostly for poets on the American Poets page):
- format of names and dates (varies)
- bibliography (sometimes the same word will refer to either the authors works or works on the author. This varies from article to article but the title only says "Bibliography")
- works font style (Eg.: Instead of, say, Don Quixote it's just Don Quixote)
- sometimes a large list of works are written in a different smaller and thinner font and the capital "I"s and "L"s can't be distinguished. https://en.wikipedia.org/wiki/Anne_Waldman#Works Lovis or Iovis?
So I propose:
a template, tutorial, maybe even clippy (or since it's wikipedia we can call it whippy), or "an-ask-someone-else-to-format-this-correctly" request feature (this can be put up on a separate page for requests or can have a special 'button'/ 'medal' image on top of the page to easily indicate to editors that the page requires special attention.
My idea: A mouse-over explains the meaning of the medal (for the information of the middle-man) with a link to a tutorial. Then, the middle-man (me) can select the right medal, say an expert knowledge medal or formatting medal, and input the location of this error. Then, a mouse-over of the medal (for the information of the editor) would say where the error is, what type of editing is required, time, IP and for how long the request has been unanswered.)
3. I also propose this medal feature, to help people like me, who spot the errors but can't correct it. (I'm studying so maybe when I know more and have more time I can correct it. If this feature were there I could have marked all the errors I spotted on their respective pages, instead of not spending the time to write in the edit page that the biographies are off. ) Medals: A compact, clean, quick way to say "Edit this" without editors having to always read the whole thing. 61.2.163.210 (talk) 13:19, 24 March 2016 (UTC)
- Regarding item 3, we already tried this with WP:AFT, which was removed from use here on en.Wikipedia. --Izno (talk) 15:47, 24 March 2016 (UTC)
- Regarding Item 4 after the "graphic rework" or whatever they called it I researched suitable sans-serif fonts for Linux, Windows and Mac which don't have this problem, and suggested them to the WMF. I got the usual Not Invented Here response I'm afraid. It might be worth trying again.
- All the best: Rich Farmbrough, 17:18, 24 March 2016 (UTC).
"Research help" proposal
- Backgound
A pilot project has added this template (or something similar):
to 10,633 articles with a "References" section - based solely on discussions at two WikiProjects, initiated by User: Astinson (WMF) (really the respected user User:Sadads).
It is intended to add these to all articles.
The purpose is to solve a problem or problems. The problem should be stated in Wikipedia:Research_help/Proposal#What_are_we_trying_to_solve?, but there is no clear statement of a problem or problems.
The template links to a page which needs to be read to understand the likley effect. Among other things it makes categorical statements about biases, editors and Wikipedia article which could be contentious, and embeds a not-strictly-accurate video.
A number of editors (including me) are not happy with having this text linked to form the bodies of of some 10,633 articles, many dealing with important topics, without a VP approval.
There are many issues here, including WMF-community relations, believing projects WP:OWN the articles in their scope and cross-namespace links.
I would like to focus on one proposal however:
Proposal
The existing 10,633 article "pilot" be suspended by blanking the template, and no further templates added. When a proper VP proposal for a pilot has been made and passed, which should include community review of the template wording, the help page wording and the purposes behind it, the pilot may continue. If the proposal is not made, or does not pass, within a month from today, the templates will be removed. Meanwhile editors are free to remove the templates in the normal course of editing using editorial discretion.
Pings |
---|
Those who commented on Wikipedia talk:Research help. Astinson (WMF) Dirk Beetstra Brigade Piron CFCF Dialectric Roger (Dodger67) Esquivalience Fram Green Hazard Hzh JFW Jytdog Help! Kendall-K1 Kerry KMJKWhite MichaelMaggs MilborneOne Moxy Navyvet2016 NiD.29 Ocaasi (WMF) Pgcudahy Rhododendrites Sadads Steelpillow WhatamIdoing Wugapodes Additional editors from TfD (possible duplicates) theWOLFchild Anotherclown BethNaught Bilorv CFCF clpo13 David Eppstein Dialectric Drmies Garion96 Geogene Hawkeye7 In actu (Guerillero) Izno Jytdog Kierzek KMJKWhite Tom (LT) Martynas Patasius MichaelMaggs Mitch Ames Navyvet2016 Necrothesp Nick Nyttend Ozzie10aaaa Peter (Southwood) RexxS Scolaire Teaktl17 Ed Yaush Yngvadottir Apols if anyone missed. |
All the best: Rich Farmbrough, 18:21, 24 March 2016 (UTC).
I dug up relevant pages I could find:
- WikiProject_Medicine discussion: Supported.
- WikiProject_Military_history discussion: Supported.
- Village Pump Technical: There was mention of a posting there, but I couldn't find it.
- Bot approval discussion:
- Approved. 10,000 pages maximum.
- any further scaling beyond that cap would require Community concensus (referring to Village pump)
- Template for discussion: Heated no consensus. Many 'keeps' were limited to a 1-month test.
- This project's Talk page: mostly complaints.
Alsee (talk) 13:06, 25 March 2016 (UTC)
Support (stop the "pilot" until consensus is reached)
- Not suitable placement, unclear motivation, target page needs work. Also breach of WMF-community protocol which needs reining in. All the best: Rich Farmbrough, 18:21, 24 March 2016 (UTC).
- Pause until we know what we have. GenQuest "Talk to Me" 03:22, 25 March 2016 (UTC)
- Pause at least and consider rolling back until there's been consensus considerably stronger than "well, I asked a few people and nobody actively disagreed". It's clear from Wikipedia:Research_help/Proposal#Who is affected? that the intent is to add this to every page on Wikipedia, but there's no obvious impact assessment I can see. On longer articles, it's likely to be lost in the general goop of navboxes, Commons links, portals and external links at the bottom of the page if not made even more obtrusive than it already is, but making it obtrusive enough to stand out to readers will make it an obnoxious and distracting presence on shorter stub articles. Even the actual proposal itself makes it clear that spamming this template isn't appropriate. I have no doubt of the good faith of those involved, but this looks like yet another case of someone at the WMF with a pet project assuming that everyone else is as enthusiastic for their idea as they are themselves, and before it goes any further it needs a discussion among the broader editor base as to whether the benefits of this outweigh the problems, and how to implement it if it does go ahead. ‑ Iridescent 11:06, 25 March 2016 (UTC)
- Pause and consider rolling back per Iridescent. In addition, I definitely don't support embedding this into content. Regardless of whether it's needed, this is not the right way to go about it. It should be presented as meta-content (it currently doesn't even use the
selfref
class or similar), it should be presented in the right place as meta-content relevant to the whole wiki (Main Page or sidebar spring to mind?), and I'd want confirmation before placing it in the references section, where I'd bet it's not read by the people who need it and annoying to the people that don't. {{Nihiltres |talk |edits}} 16:42, 25 March 2016 (UTC) - Stop the pilot and roll back. Self-referential meta-content should not appear in the text of articles and this wide-reaching change should have been brought forward for project-wide consensus rather than consulting just a few wiki-projects, who do not control the relevant articles. Also see my comment below about timelines. BethNaught (talk) 22:23, 25 March 2016 (UTC)
- Stop the pilot and roll back promptly. As per BethNaught, this kind of self-refereential content does not belong on article pages. The idea is clearly intended to help readers, but a better way must be found to do this. Do not wait another two weeks to roll this back, and certainly no longer. DES (talk) 09:32, 26 March 2016 (UTC)
- Strongly stop the pilot If I had known this had existed, I would have strongly objected. The fact that this project was done without the consensus of the community (WP:VP) undermines the project's ideals. Programming G E E K (mah page! // use words to communicate page) 11:37, 26 March 2016 (UTC)
- Support This and anything like it needs needs project wide consensus before implementation; and in this specific case, there needs to be wider discussion on the best method for implementation. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:58, 26 March 2016 (UTC)
- Strong support: Consensus represents both the concerns of editors as well as the wishes of the entire community. Although the WikiProjects asked were in no way small, they cannot speak for the entire community nor is the community devoid of objections to this project. Esquivalience t 02:35, 27 March 2016 (UTC)
- Support. Roll back until more widely discussed and piloted. JFW | T@lk 07:54, 27 March 2016 (UTC)
- Support. As I was saying in the discussion concerning the template, it is not just annoying, it is not just violating guidelines about self-references, it also links to the page that is misleading the readers (into thinking that Wikipedia is more reliable than it is) with various "Finally, Wikipedia's millions of readers catch and fix flaws when they find them." or "This works most of the time because many eyeballs make all bugs shallow," (still there in the current version - Special:Diff/711865882). Or, at least, it would be misleading them, if they were actually reading it, which isn't certain (hardly anyone has cited anything from that page in any of those discussions, and the ones who participate in them could be expected to be more motivated to read all that than an average reader) - but if no one reads that page, the template is still useless. And we already know much about this idea (most importantly - that it is not good), thus there isn't much to research, meaning that the further trial is unlikely to be useful. And if it is misleading, violating guidelines, annoying and useless, I'd say that the trial should be stopped. --Martynas Patasius (talk) 18:28, 27 March 2016 (UTC)
Oppose (allow the "pilot" to continue ad lib)
- Continue Does it really hurt anything for a 30-day test. Give me a break people. The real question is should they remove them all after the trial is up. Oiyarbepsy (talk) 03:24, 25 March 2016 (UTC)
- continue just give it a chance--Ozzie10aaaa (talk) 23:47, 25 March 2016 (UTC)
- Continue for the next 9 days trial will end on April 7 anyway. I support in general improving articles and the way we communicate article content; part of this involves trying new things. Trying things inherently carries a component of risk (on wikipedia at least: mainly to the proposer of a trial's mental health and wellbeing). This was a small trial with local consensus that has a defined endpoint in 9 days. What a storm in a teacup.--Tom (LT) (talk) 17:12, 27 March 2016 (UTC)
Neutral
- Neutral Were this a proposal, I would have opposed its implementation. I don't think this is the right way to go about solving the "problem" of helping people do research. But that's not what this discussion is, and I think we can cross that bridge when we get to it. This pilot has a hard stop on April 7th. After going 600 article over the pilot amount, the bot stopped adding them to pages. I don't particularly see a problem with leaving it on these pages for about 10 more days and then addressing whether we want to let it keep going. I don't want it to continue (which is why I'm not in oppose) but I see very little difference between the pause outcome and what's already occurring. By the time we develop consensus, it will likely be just a few days from the pause outcome and when it would have naturally ended anyway. I don't really feel comfortable in either support or oppose because of that, so here I stand. Wugapodes (talk) 18:59, 26 March 2016 (UTC)
- can I do the same? Can I? Can I?. I want to add a very nice test I thought of to a mere 10,000 of WP's pages for only one month. Can I? That is, although the intention looks good, it looks very bad. ANd no, Ignoring All Rules is not a good argument to add a poorly designed link to a disclaimer-like page. Anyway Wugapodes makes a good point. Why bother... Lets move on to discuss the big picture, and check if anyone says they will clean up after the deadline and then 'forget' to. - Nabla (talk) 21:26, 26 March 2016 (UTC)
Additional discussion
The Bot approval discussion should have bounced this to Village pump. It should have been foreseeable that controversy would arise over 10,000 "experimental" cross-namespace links (with an icon to boot) added to the Reference lists. The intentions are good, but this is way outside any commonly accepted norms. Any cross-namespace link in an article is typically revert-on-sight, and any content unrelated to the article it is in is also typically revert-on-sight.
It appears that this "pilot" is planned to end in a few days anyway, after which they planned to come to Village Pump anyway. It looks like this discussion is mostly moot, unless it gets a real fast Snow close. Even with a quick Snow close it would make little difference to the apparent end-date anyway. Alsee (talk) 13:31, 25 March 2016 (UTC)
- @Alsee: Could you point me to a specific end date? Also, I will say that pilots have a nasty habit of lingering longer than intended (cf Pending Changes trial) and that it could take an exceedingly long time for them to come here, given there are several steps in the given roadmap between the trial phase and the Village Pump phase. The roadmap is not at all clear. BethNaught (talk) 22:23, 25 March 2016 (UTC)
- Hi all. Thanks for bringing this up for discussion, we really appreciate the wide range of feedback we have been getting. We had been hoping to collect more data, so that we could reflect on a data-informed discussion (hence the pilot and limited discussion). We hadn't previously documented a specific removal date, because of the delays in the bot activity and variability in visibility created by the TFD (skewing both the feedback and pageviews). However, based on when the bot implemented, I plan to noinclude the template, on or before April 7 (or via concensus of course). I documented it with this edit. I will engage more in the discussion tomorrow. I look forward to any questions and discussion, Astinson (WMF) (talk) 01:44, 26 March 2016 (UTC)
- Thanx.
- Rich_Farmbrough, the noinclude on the template will blank the template as proposed, additions of the template have already hit the bot-approval cap, and the previously stated intent is a Village Pump proposal before proceeding any further. It seems the objectives of this proposal have been agreeably satisfied. How about withdrawing & boxing the unneeded support/oppose sections? We can leave this discussion section open. Alsee (talk) 04:09, 26 March 2016 (UTC)
- I think it's quite useful. I am also not very happy with the idea that this project has "snuck under the radar". I thought perhaps I was being a little cynical entertaining this idea, but I now see that the project was advised to come here back in November, by User: WhatamIdoing
- I think it's quite useful. I am also not very happy with the idea that this project has "snuck under the radar". I thought perhaps I was being a little cynical entertaining this idea, but I now see that the project was advised to come here back in November, by User: WhatamIdoing
- Hi all. Thanks for bringing this up for discussion, we really appreciate the wide range of feedback we have been getting. We had been hoping to collect more data, so that we could reflect on a data-informed discussion (hence the pilot and limited discussion). We hadn't previously documented a specific removal date, because of the delays in the bot activity and variability in visibility created by the TFD (skewing both the feedback and pageviews). However, based on when the bot implemented, I plan to noinclude the template, on or before April 7 (or via concensus of course). I documented it with this edit. I will engage more in the discussion tomorrow. I look forward to any questions and discussion, Astinson (WMF) (talk) 01:44, 26 March 2016 (UTC)
did you spam notices about this to the Village Pumps or anything like that? There was an objection last year (with a script that displayed the editors'/authors' names on the page) that was framed as being a procedural complaint about a LOCALCONSENSUS by a WikiProject. It would be desirable to have attention from non-participants, especially since WPMED doesn't OWN the articles
-
-
-
- to which User:Astinson (WMF) replied:
-
-
We were aware of that experience. We are operating under the assumption that this is not going to have many strong objections: every person we have shown this to has had no show-stopping objections (mostly positive tweaks, etc), we plan to do this a temporary pilot to see if there is evidence of its usefulness, and it will be a template that can be "noincluded" at a moments notice.
-
-
-
- There have been numerous objections, and the template has not been "noincluded" - except by me, and that was reverted.
- This is not a small thing, it is, arguably, damage to 10,633 articles.
- All the best: Rich Farmbrough, 05:41, 26 March 2016 (UTC).
- I was referring to the existing agreement "to noinclude the template, on or before April 7". I don't see what's really being added by piling on supports for what's going to happen anyway. I'm surprised there were no objections raised at MED or MILHIST and I think BOT-approval should have bumped this unusual edit to Pump, but I think we can take this as a good faith situation with an uncontested end to the pilot. Alsee (talk) 10:26, 26 March 2016 (UTC)
- If the pilot is going to end naturally, this poll is redundant and ought to be closed. Note that when it was started there was not a clear date, but now there is I agree with you. BethNaught (talk) 10:43, 26 March 2016 (UTC)
- I was referring to the existing agreement "to noinclude the template, on or before April 7". I don't see what's really being added by piling on supports for what's going to happen anyway. I'm surprised there were no objections raised at MED or MILHIST and I think BOT-approval should have bumped this unusual edit to Pump, but I think we can take this as a good faith situation with an uncontested end to the pilot. Alsee (talk) 10:26, 26 March 2016 (UTC)
-
-
Notice: RfC on Citation coding style
See WT:CITE#RFC: Is a change in citation markup method a change in citation style?. More views are wanted. DES (talk) 23:09, 26 March 2016 (UTC)
Banter
I don't know how many people feel like me but I've always wanted Wikipedia to be a fun kind of place. We get work done, but let it not feel like drudge. So, I propose we make a page for banter where we can get together and do some shiz. I don't know how will other people will feel about this but hey, atleast I've spoken my mind. --QEDK (T 📖 C) 16:53, 27 March 2016 (UTC)
- Maybe Wikipedia:Village pump (banter) ? All the best: Rich Farmbrough, 22:06, 27 March 2016 (UTC).
- We had that many years ago. It was called Wikipedia:Esperanza. It was killed with pitchforks and torches for upsetting the local villagers. --Jayron32 02:09, 28 March 2016 (UTC)
- It seems to have dissolved into some useless bureaucracy that caused it to be brought down. I went through it and why not just make a coffee lounge kind of place? (If enough people support this proposal, I'll frame some rules and make one) --QEDK (T 📖 C) 14:26, 28 March 2016 (UTC)
- I think it could be fun to have a relaxed kind of place on here where it wouldn't be all about AfD fights, vandalism and other unpleasant aspects of the encyclopedia. I would support it. White Arabian Filly Neigh 21:53, 29 March 2016 (UTC)
- It seems to have dissolved into some useless bureaucracy that caused it to be brought down. I went through it and why not just make a coffee lounge kind of place? (If enough people support this proposal, I'll frame some rules and make one) --QEDK (T 📖 C) 14:26, 28 March 2016 (UTC)