Community Wishlist Survey 2015

The Community Wishlist Survey 2020 is over...

Here are the Community Wishlist Survey 2020 results!

Total: 72 proposals, 423 contributors, 1749 support votes

Random proposal

Welcome to the 2015 Community Wishlist Survey! We're inviting contributors from all Wikimedia projects to submit proposals for what they would like the Community Tech team to work on for the purpose of improving or producing curation and moderation tools for active contributors. After two weeks of collecting proposals, we'll ask you to vote on the proposals that you're most interested in. The proposals with the highest votes will become the team's top priority backlog to investigate and address.

See the Community Wishlist Survey description for more information about the survey process.

Note: This is the proposals phase of the survey; we're looking for proposals and endorsements. Feel free to discuss and show approval, but the actual voting phase will be Nov 30–Dec 14.

Instructions for submitting a proposal

Proposals should be discrete, well-defined features and fixes that will directly benefit the core community, in line with the scope of the Community Tech team. Proposals that are outside of that scope may be referred to other development teams or declined. Feel free to suggest big changes or small, as long as it addresses a specific need.

Participants are encouraged to limit themselves to posting up to 3 proposals each. Proposals may be submitted in any language. Ideally your proposal should concisely address the following points:

• What is the problem you want to solve?
• Which users would benefit? (editors, admins, Commons users, Wikipedia users, etc.)
• How is this problem being handled now?
• What are the proposed solutions? (if there are any ideas)

Endorsements: Proposals must be endorsed by at least one other user in order to be eligible for the voting phase, using the {{endorsement}} template. Similar proposals may be combined to reduce duplication, in which case each duplicate should count as an endorsement. Multiple endorsements aren't necessary and won't affect the proposal's eligibility, but feel free to add comments on the proposals as we go along.

Participation requirements: In order to submit a proposal or endorse an existing proposal, a user must have at least 100 edits on any project or be an active Tool Labs developer. Anyone can participate in discussions, including anonymous IP users. Cross-wiki edit counts can be verified at Special:CentralAuth.

Language: We would like to include people from as many projects as we can, in many languages. This will require a lot of translation help. If you can help to translate proposals into English, we really appreciate it. Also, if we haven't posted an invitation to the survey on a village pump or wiki discussion page in your language, we'd like to! See the invitation page to help with translation. Thank you!

Submit your proposal

Submit an idea

Article display

Make quality/reliability of an article more clear to the reader

Currently, outside stub and user-added-templates, there is no way to make quality/reliability of an article clear to the casual reader. This is a problem, given the increasing spam-penetration and such (see en:User:Doc_James/Paid_editing). A solution would be to 1) enable en:Wikipedia:Metadata gadget for all readers by default, 2) develop a complementary script, which would also display (perhaps upon request, accessible from a toolbar or heading) information about number of watchers, major contributors, and perhaps one of the numerous trust-values that are discussed in several academic papers and 3) add an article checklist for common problems - see my proposal below). --Piotrus (talk) 05:21, 10 November 2015 (UTC)

 Endorsed Also, @Gamaliel: is going to be proposing this as a default Gadget on English soon. Sadads (talk) 15:09, 12 November 2015 (UTC)

The Metadata Gadget doesn't makes clear the quality of the articles, because no normal reader can guess what the colors represents. And there are too many colors, why use different colors for ongoing events, disambiguations, etc? Just leave the title black!--MisterSanderson (talk) 04:03, 18 November 2015 (UTC)

 Endorsed Ottawahitech (talk) 15:38, 19 November 2015 (UTC)

Mobile-friendly framework for multi-column portal and project pages

On many portals and WikiProjects, front pages are designed with a multi-column arrangement of boxes. This allows a neat and compact distribution of related and/or unrelated contents on large desktop displays. However, these designs unfortunately rely on wikitables as structural elements in the majority of cases and for this reason they are intrinsically incompatible with small devices. This is an experience from de-wiki, but I think the situation is not much better on other wikis (arbitrary portal examples with poor performance on mobile: [1] [2] [3] [4] [5] [6]; to test their mobile behavior, open these links in your webbrowser and resize the window width to smartphone dimensions).

There are many reasons for these poor results. Besides the fact that many portals have been established in a pre-mobile time, we still suffer from the unavailability of a frameset of easily comprehensive technical solutions to build mobile-friendly portal/project pages out-of-the-box without the need of complex CSS hacks. I would therefore propose to develop a framework, consisting mainly of CSS classes on a suitable site in Mediawiki namespace and therefore available for common usage, with the following properties:

• a flexible set of CSS classes, separated for style and positioning of content boxes; users can add classes to portal elements and define style and positioning by doing so
• boxes can be encapsulated by the usage of templates with parameters, which I think are better known to wiki users than plain HTML
• once compiled to a portal/project page, the box arrangement intrinsically adapts to display size, regardless of whether standard frontend, mobile frontend, or a Wikimedia app is used
• a detailed documentation including use cases will complement this frameset; an average wiki user shall be able to create a mobile- & desktop-friendly portal page
• bonus task: enable modern CSS techniques in portal namespace, like for instance media queries and whatever is useful; technically skilled users can enhance mobile and desktop experience by using this feature

—MisterSynergy (talk) 20:01, 11 November 2015 (UTC)

 Endorsed LeoRomero (talk)

I'm not convinced this is somewhat useful at all... I never use portals and mobile phones, and on Portuguese Wikipedia the portals are all abandoned. Why create such mechanism, if there is noone interested in implementing it on the pages?--MisterSanderson (talk) 04:08, 18 November 2015 (UTC)

Reading List

Tracked in Phabricator:
Task T3492

Sometimes readers (but not ususally editors) stumble upon an interesting article and would like to read it later, maybe because they don't have enough time at that moment. That would be great if they could add it to their Reading List so that they wouldn't forget it! I know there are lots of ways to bookmark webpages (both by browser and online service providers) but this idea is worth considering. 4nn1l2 (talk) 10:28, 10 November 2015 (UTC)

•  Oppose. There's nothing here that cannot be accomplished by the bookmark functionality in your browser, it does not improve wiki content in any way whatsoever, does not make life easier for the core community and is better suited to WMF's Reading team. MER-C (talk) 14:54, 10 November 2015 (UTC)

Hey, and if the reader isn't on his home computer? Say he is on a relative's computer, public computer, cyber coffee computer, school computer? How to add on browser's bookmarks in these situations? In contrast, how to access the home bookmarks from these computers? Note: Facebook has a internal bookmark (saving) function for these cases.--MisterSanderson (talk) 04:32, 18 November 2015 (UTC)

•  Endorsed I have thought to this functionality now and again. This can be useful if we can associate remarks, reminders or "to do" to a "bookmark", which can't ( or can't easily) be done with regular bookmarks. This should be private of course. --Jean-Christophe BENOIST (talk) 17:23, 10 November 2015 (UTC)
  • About reminders/to-do things you can take a look here. --Edgars2007 (talk) 17:43, 10 November 2015 (UTC)

That can be accomplished by having multiple watchlists. Helder 17:44, 10 November 2015 (UTC)

He7d3r, having multiple watchlist would be great!

•  Endorsed --Shizhao (talk) 02:26, 11 November 2015 (UTC)
• Comment May be implemented with browser cookies to prevent server load. --Usien6 (talk) 02:46, 11 November 2015 (UTC)

This could be considered a variant on the previous proposal for additional watchlist functionality. A properly generalized watchlist could also be used as a personal reading list. Cscott (talk) 18:59, 11 November 2015 (UTC)

•  Endorsed but would also like to add specific revisions or diffs to the reading list so I can come back to them later. This could be implemented relatively easily by having a "private" (only readable by the user and admins) wiki-page plus scripts that add or subtract things from this page. Davidwr/talk 05:37, 16 November 2015 (UTC)

• Comment In fact this is something (or exactly) like mw:Extension:Gather (which I find nice and useful). With this, anybody can create reading lists (aka "Collections"), private of public: en:Special:Gather/by/Geraki. They can even be used as multiple watchlists (en:Special:GatherEditFeed). The bad thing is that is still in beta, and currently you can add pages only through the beta mobile interface (but you can still check them in the desktop interface). So, I endorse to continue developing this extension and enable it to the main interface for all wikipedias. -Geraki ^T_L 12:40, 16 November 2015 (UTC)

•  Endorsed While my PC's browser is quite capable of bookmarking pages, this does me absolutely no good when I head on over to my local library with the intent of doing a bit of fact-checking or citation gathering. When I first came to this page it was my intent to make a suggestion similar to this, so I'll endorse this one instead! I think that ideas related to a reading list, expanded functionality of a watchlist, and a to-do list can be combined to make an especially useful tool. Etamni (talk) 07:58, 17 November 2015 (UTC)

Subpages: suppress links to ancestor pages

Wikibooks uses Subpages in order to structure a book in chapters. Wikiversity does the same for a course and lessons. Each subpage shows links to ancestor pages automatically. Nevertheless the authors offer to navigate between chapters and the content page using navigational templates. In these cases, you see the link to the ancestor page as well as the navigation bar -- e.g. b:en:Geometry for Elementary School/Introduction. I'ld prefer to suppress the automatically created link if a navigation bar is shown. Double information may disturb users.

Users: Wikibooks, Wikiversity and other projects that use subpages. Current situation: Links to ancestor pages can't be suppressed. Solution: Add a behavior switch __NOANCESTORLINK__ or something like that. -- Juetho (talk) 10:45, 18 November 2015 (UTC)

•  Endorsed --Klaus Eifert (talk) 13:30, 18 November 2015 (UTC)

Bots and gadgets

Improve the "copy and paste detection" bot

Currently we have a bot that analysis "all" new edits to en WP for copyright concerns. The output is here. And there is the potential for it to work in a number of other languages.

Problems is that it is not up as reliably as it should be. Also presentation of the concerns could be improved. Would love to see the output turned into an extension and formatted similar to the en:wp:Special:NewPagesFeed

Currently the output is sort-able by WikiProject. It would be nice to create WikiProject specific modules to go on individual project pages.

Doc James (talk · contribs · email) 03:45, 4 November 2015 (UTC)

•  Endorsed --Tobias1984 (talk) 19:12, 7 November 2015 (UTC)
•  Oppose -- not all site have copyright, some have GNU, also some edit include specific "quotations" which may be a valid use. Yosri (talk) 02:29, 10 November 2015 (UTC)
•  Endorsed would love to see this bot on other Wikipedia projects, including RTL wikis, but not as an extension. 4nn1l2 (talk) 09:04, 10 November 2015 (UTC)
•  Oppose as Wikipedia specific. Yes, copyvio is a serious problem, but MediaWiki has painful shortcomings that should be a higher priority. Improving blocking tools will also reduce the copyvio problem -- when a big chunk of copyvios come from India, we need to be able to effectively block repeated copyvio editors from that part of the world. We can't. MER-C (talk) 14:47, 10 November 2015 (UTC)

Article assessor gadget/extension

Tracked in Phabricator:
Task T116092

Create an easy to use interface for adding WikiProject assessment templates to articles. Would probably require some sort of JSON config page for listing the available templates. Would work similar to the WikiLove extension (which adds barnstars to talk pages). Kaldari (talk) 17:30, 19 May 2015 (UTC)

Gadget for en.wiki proposed here: en:Wikipedia:Gadget/proposals#AssessmentHelper. Kaldari (talk) 17:58, 7 July 2015 (UTC)

See also: Grants:IEG/Revision scoring as a service/Renewal#Scope. Helder 13:42, 9 July 2015 (UTC)

See also #Make quality/reliability of an article more clear to the reader I proposed above. --Piotrus (talk) 04:33, 12 November 2015 (UTC)

Comment: This is usually done with a bot that checks if all articles in a category contain a certain template and adds it if necessary (and in some cases the bot can prefill certain arguments of the template). That is far more efficient than using something similar to WikiLove. The Quixotic Potato (talk) 14:41, 12 November 2015 (UTC)

 Endorsed I use en:User:Kephir/gadgets/rater.js regularly, and it makes a world of difference for Assessment. I think having something like this baked in as a default gadget on WikiProjects would make a world of difference for maintaining Assessment. Sadads (talk) 15:05, 12 November 2015 (UTC)

 Oppose. Wikipedia specific and well within the capability of volunteer editors. There is no need for this to be an extension, the gadgets above should be sufficient. This proposal would also be made even more unnecessary by having a global repository of gadgets. MER-C (talk) 16:22, 14 November 2015 (UTC)

Migrate dead links to Wayback Machine

See also: mw:Archived Pages.

Most external links have am average lifespan of about 7 years before they go dead. As Wikipedia ages, the dead external links problem grows exponentially. Internet Archive has partnered with Wikipedia to ensure all new external links have a Wayback cache. However there has been no formal process of adding the Wayback links to Wikipedia (via the cite web |archiveurl=.. feature for example). There have been attempts to automate with various bots (see en:WP:Link rot) but the coding is non-trivial and multiple volunteer efforts have stalled. Likely what will be required is a team of programmers working full-time, something that is beyond the scope of a few volunteers working spare time. It's the sort of coding work that MediaWiki could sponsor and make a big difference in the quality of content, impacting every article. -- Green Cardamom (talk) 19:27, 7 November 2015 (UTC)

 Endorsed Much needed and certainly very important for smaller Wikipedias as well. Jopparn (talk) 09:12, 8 November 2015 (UTC)

 Endorsed We have made significant progress with en:User:Cyberbot II adding links to archiveurls, but there needs to be a good technical way to store. Talked with @Jdforrester (WMF): about building it into citoid at WikiCon USA. Internet archive was there, and expressed an interest in pushing their API's to the limit, to fix the 404 and other errors on Wikipedia, Sadads (talk) 10:11, 8 November 2015 (UTC)

 Endorsed Agree that this is very much needed. ONUnicorn (talk) 13:47, 8 November 2015 (UTC)

 Endorsed Much globally needed, volunteer efforts shouldn't be the only way for an important feature like this. --AlessioMela (talk) 21:06, 8 November 2015 (UTC)

• Great idea and User:Cyberpower678 already built it here from what I understand. I guess the question is what more needs doing. Doc James (talk · contribs · email) 03:32, 9 November 2015 (UTC)

• FYI, only 1 endorsement is needed for this phase of the survey. The voting phase will happen later. Ryan Kaldari (WMF) (talk) 17:07, 9 November 2015 (UTC)

 Endorsed and also migrate to WebCite--Shizhao (talk) 01:57, 10 November 2015 (UTC)

 Endorsed Useful. --Piotrus (talk) 04:58, 10 November 2015 (UTC)

 Endorsed Useful. Aphaia (talk) 05:05, 10 November 2015 (UTC)

 Endorsed Very good idea, it could be very useful! Restu²⁰ 07:33, 10 November 2015 (UTC)

 Endorsed Esquilo (talk) 08:07, 10 November 2015 (UTC)

 Endorsed For all Wikipedias including RTL wikis. 4nn1l2 (talk) 09:09, 10 November 2015 (UTC)

 Endorsed Danmichaelo (talk) 21:26, 10 November 2015 (UTC)

 Endorsed Kropotkine 113 (talk) 21:32, 10 November 2015 (UTC)

 Endorsed I do this all the time by hand, it would be great if there was an automated procedure to take care of it. --Waldir (talk) 13:40, 14 November 2015 (UTC)

 Endorsed Useful. Afernand74 (talk) 17:28, 14 November 2015 (UTC)

 Endorsed particularly with newly-added links. If there is an API-equivalent to the "save page now" button at https://archive.org/web/ , it should be useful for this task. Davidwr/talk 05:41, 16 November 2015 (UTC)

Automatic bot

Recommend to create automatic bot for those small wiki which may not have local expertise. They can submit a template and data file and a bot expert will create and run the bot (with permissions of local admin.). Yosri (talk) 02:34, 10 November 2015 (UTC)

@Yosri: I'm not sure I understand this proposal. What function would the bot be performing? Ryan Kaldari (WMF) (talk) 03:01, 13 November 2015 (UTC)

Comment: I believe the request is general, presumably functions comparable (or identical) to various existing bots. Alsee (talk) 14:43, 14 November 2015 (UTC)

@Ryan Kaldari (WMF):Ditto, but without the need for the said user to have bot expertise. More like the local user only prepare a template and the data file. A standard bot will pick it up and generate the pages. That means, wiki in other languages need only to translate the template to generate complete pages in local languages, instead of manually translating those pages one by one. Yosri (talk) 16:00, 18 November 2015 (UTC)

@Yosri: OK, I think I understand better, but could still use some clarification. What types of bots did you have in mind? Are you thinking of bots that generate database reports (en:Wikipedia:Database reports)? Bots that edit articles? Bots that build reports for WikiProjects? Which ones would be your highest priority? Any specific examples would help. Ryan Kaldari (WMF) (talk) 23:30, 18 November 2015 (UTC)

@Ryan Kaldari (WMF): A bot that create article, very much like mail merge. User supply template and data file, the bot run on batch (after local admin given green light.) If other language Wiki want to use the same data file, they just copy both to local Wiki & translate the template and some field in the data file (I imagine) and their local admin give green light / flag bot on for that template and off it go. After all, not all user is technical savvy enough to operate a bot, but can still manage mail merge like concept. Yosri (talk) 14:30, 19 November 2015 (UTC)

Machine-learning tool to reduce toxic talk page interactions

Proposal

Build an AI tool to identify occurrences of apparent talk page abuse in the English Wikipedia in real time, building on existing en:WP functions such as tags and edit filters.

Envisaged benefits

1. An edit filter could warn users before posting that their comment may need to be refactored to be considered appropriate:
   1. Cutting down on the number of abusive talk page messages actually posted.
2. Editors could check recent changes for tagged edits:
   1. Bringing much-needed third eyes to talk pages where an editor may be facing sexual harassment or other types of abuse.
   2. Improving response times and relieving victims of the burden of having to ask an admin for help.
3. Prevention of talk page escalation.
4. Improvement of talk page culture.
5. Enhanced editor retention.

Some prior discussion of this idea can be found at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)#Proposed:_Tag_.2F_edit_filter_for_talk_page_abuse

As User:Denny pointed out on the Wikimedia-l mailing list yesterday, a similar project has reportedly been run in the League of Legends online gaming community to improve the quality of social interactions, with considerable success: occurrences of verbal abuse in that community are reported to have dropped by more than 40 percent.

Another interesting finding from that project was: 87 percent of online toxicity came from the neutral and positive citizens just having a bad day here or there. [...] We had to change how people thought about online society and change their expectations of what was acceptable. That is something that seems to apply to Wikipedia as well.

The game designers and scientists working on this project started out by compiling a large dataset of interactions community members deemed counterproductive (toxic behaviour, harassment, abuse) and then applied machine learning to this dataset to be able to provide near real-time feedback to participants on the quality of their interaction. (They're also looking at identifying positive, collaborative behaviours.)

I would love to see the Foundation explore if this approach could be adapted to address the very similar problems in the Wikipedia community. The totality of revision-deleted and oversighted talk page posts in the English Wikipedia could provide an initial dataset, for example; like the League of Legends community, the Foundation could invite outside labs and academic institutes to help analyse this dataset.

There are considerable difficulties involved in building a system sophisticated enough to avoid unacceptable numbers of false positives, but this is a challenge familiar from ClueBot programming, and one the League of Legends team seems to have mastered: Just classifying words was easy, but what about more advanced linguistics such as whether something was sarcastic or passive-aggressive? What about more positive concepts, like phrases that supported conflict resolution? To tackle the more challenging problems, we wanted to collaborate with world-class labs. We offered the chance to work on these datasets and solve these problems with us. Scientists leapt at the chance to make a difference and the breakthroughs followed. We began to better understand collaboration between strangers, how language evolves over time and the relationship between age and toxicity; surprisingly, there was no link between age and toxicity in online societies.

A successful project of this type could subsequently be offered to other Wikimedia projects as well. It would address a long-standing and much-discussed problem in the English Wikipedia, and put the Foundation at the leading edge of internet culture. Andreas JN466 20:03, 14 November 2015 (UTC)

• Neither an endorsement nor a rejection at this point (I could see this being workable and helpful. I could also see it going down in flames. It would all depend on the implementation, legalities, and subsequent use of the tool), but here are some initial and somewhat rambling thoughts that might help you expand on this, Jayen466:
  • The dataset of "revdeleted and oversighted edits" contains within it a large quantity of personally identifying information about editors, article subjects, etc (as well as things like allegations of criminal wrongdoing). Even within the WMF, I don't think the majority of staff are under an NDA that covers this type of personal information (and appropriately so - that kind of stuff needs to be as compartmentalized and protected as possible), and certainly the majority of community edit filter managers have not been vetted by the community for handling this type of information. A tool running on the OS dataset would thus need some kind of...is "backstopping" the right word? It would need to be either developed and tested only by people who are under an NDA covering this type of information, or the dataset would need to be pre-sanitized of that kind of information (replacing it with placeholder text along the lines of "[home address removed]"? or something?) before being turned over to whoever will develop the tool. That's a lot of work and a lot of person-hours from NDA'd folk; would this machine learning work be valuable enough to prioritize over other tasks?
  • A tool of this type could only ever catch the lowest-hanging fruit. Like, certainly it could catch "you're an asshole" or "[username] is a shit editor", but the kind of machine learning that would catch, say, "as for my esteemed opponent, I do question whether he is entirely qualified to make such judgments, given his affinity for barnyard animals"...afaik that doesn't exist and maybe never will. That's not to say a tool that only catches the low-hanging fruit is a tool that's useless, either, though - the League of Legends data you cite about the bulk of the abuse coming from non-repeat-offenders makes me think that the bulk of the abuse was probably not of the exquisitely-phrased-to-evade-censors type, either. If a filter could catch even 25% of the abuse that flies, particularly from the people who are acting in the heat of the moment and could benefit from a tap on the shoulder and a "hey, think about that", I think I'd consider it a success.
  • You're not wrong to call the revdel + OS dataset a corpus of "unacceptable speech", but I think we need to keep something in mind about that data compared to LoL's crowdsourced voting: the vast, vast majority of OS/revdel decisions-to-hide-text were made by a single person on the basis of a) a much more general policy bullet point and b) that person's own judgment about whether that edit fit within that policy point. For things like the "big" racial slurs, that's probably a judgment that can be generalized to the community at large, but for a lot of things, it's more debatable than that, both because people's personal opinions vary and because the culture's understanding of what is and isn't grievously unacceptable changes over time (for the former, think of something like the British-American divide on the c-word; for the latter, think of how internet culture would have reacted to someone saying "that's so gay" or the gay-slur f-word ten years ago compared to today). When the eventual tool is developed to filter/flag these unacceptable-on-wikimedia utterances, whose standard will we use? A possible solution that occurs to me would be to merge LoL-style voting with machine learning and use an iterative stragegy: develop machine learning tool, run on test data to generate a set of potential flags, and then have the community vote/RfC on the machine learning tool's flags' accuracy (in the sense of "yes this thing that was identified is indeed a problem we would handle as humans if we saw it"). That's another huge time investment, both for developers and community, though. Fluffernutter (talk) 16:26, 15 November 2015 (UTC)
    • Thank you for your salient comments, Fluffernutter. Andreas JN466 00:58, 19 November 2015 (UTC)

See also Research:Revision scoring as a service and ORES. Helder 20:22, 15 November 2015 (UTC)

 Endorsed This is a good idea. While there are always challenges in anything this complex, I suspect that toxic interactions are a major contributor to burnout of editors. Reducing the potential for such interactions will have long-term benefits that greatly outweigh the short-term costs of development of this tool. Etamni (talk) 17:19, 16 November 2015 (UTC)

 Support Also a good tools to fight vandals. Yosri (talk) 14:53, 19 November 2015 (UTC)

JS scripts without import

It would be nice to have special area where JS scripts can be placed. That could be a namespace like script: and only users with assigned rights can edit them. This scripts will be executed by every visitor of that page.

In a more relaxed scenario these script pages might be embedded into common wikipages like templates similar to LUA.

The advantage over imported commons:COM:User Scripts is that it requires no obscure technical methods before the scripted features can be used.

An example might be to realize advanced search bars, special upload tools, diffrent kind of calculators, template filling forms with wikitext generator or in my case a replacement of commons:com:SVG Check and maybe other tools that currently require specific wmf tool server.

--Menner (talk) 18:40, 24 August 2015 (UTC)

The Gadget namespace was added recently, as part of Gadgets 2.0 (phab:T31272). Helder 15:23, 27 August 2015 (UTC)

Categories

Making categories more friendly: enable HotCat by all, but with pending revisions

New editors often, in my experience, remark how difficult it is to tag (categorize) things on Wikipedia compared to Facebook and other modern sites. We have a useful tool, en:Wikipedia:HotCat, but there is no consensus from the community to enable it by default, as people are afraid of newbies messing up categories. The best solution I have, therefore, is to try to use some form of pending revisions with HotCat: enable it by default, but with pending revisions for new editors/anons. --Piotrus (talk) 05:11, 10 November 2015 (UTC)

Seems impossible to me to get community consensus for anything related to pending revisions really.. As much as I would like to see it. —TheDJ (talk • contribs) 07:39, 10 November 2015 (UTC)

A somewhat related request is to have such a thing in VisualEditor (phab:T52239). Orlodrim (talk) 22:07, 13 November 2015 (UTC)

 Endorsed Anything that would make categories less mysterious. Ottawahitech (talk) 15:45, 19 November 2015 (UTC)

Add checklist/filter functionality to articles/categories

Consider a category, for example en:Category:United States company stubs, plagued with spammy articles. Currently there is no way to collaboratively (or for oneself) mark which articles have been reviewed for, let's say, notability or such. It would be much easier to do clean up drives and such if we would have a way to quickly toggle on and off some filters. For example, each article could have a checklist of "has been checked for notability/neutrality/etc." (the community should be able to create such assessment categories, probably tied to common cleanup issues). An editor with some flag/permission (or just an autoconfirmed editor, perhaps) could check the article after a review. This could be made visible to article's readers, increasing their trust in it (see my proposal above), and would be very useful for cleanup drives, as I could try to filter the category for not-reviewed articles. It would be in essence a non-invasive pending changes feature, but more nuanced. --Piotrus (talk) 05:34, 10 November 2015 (UTC)

 Endorsed --Edgars2007 (talk) 05:52, 10 November 2015 (UTC)

 Endorsed I can see this being very useful in backlog-clearing and maintenance categories. Fluffernutter (talk) 17:25, 11 November 2015 (UTC)

Contains this text but not in this category or its (n-level) descendants

I'd love to have a way to search for file pages (and category pages) that contain a particular piece of text but are not in a particular category or its n-level descendants. These would, of course, be likely candidates to add to that category or one of its subcategories. It would be especially nice if it would somehow feed into VFC; for that purpose, if it can't be worked out from the VFC end, it would be possible to add a temporary maintenance category to the pages found in such a search, and then VFC could be triggered off of that category.

This would benefit people trying to categorize poorly categorized photos. Right now, you typically have to look through an awful lot of correctly categorized photos in the course of doing work like this. - Jmabel (talk) 23:03, 9 November 2015 (UTC)

•  Endorsed I do quite a bit of categorisation and would welcome this. WereSpielChequers (talk) 19:36, 10 November 2015 (UTC)
• Comment: very recently we got „Deepcat“, developed by Wikimedia Deutschland, at de-wiki (details at de:Hilfe:Suche/Deepcat). It’s still in beta status AFAIK, and somewhat limited to max 70 sub-categories and n_max=15 (levels) for performance reasons. Can be prefixed with “-” to invert. I don’t know whether it is or will be available on other wikis as well, but it looks as if it might already serve the functionality you ask for. —MisterSynergy (talk) 20:57, 10 November 2015 (UTC)

Create a tool to auto-populate categories through Wikidata/other wiki comparison

Currently, when a new category is created, even if it is linked to Wikidata and other language categories, there is no easy way to generate a list of articles that exist on a given wiki that should be populated with it. And even when someone has a list of such articles, they have to manually tag them. I'd like to see a tool that generates such lists, and allows populating categories with as much ease as Commons commons:Help:Gadget-Cat-a-lot. See also a related discussion at w:Wikipedia:Village_pump_(technical)/Archive_141#Is_there_a_way_to_auto-populate_categories_through_Wikidata.2Fother_wiki_comparison.3F. --Piotrus (talk) 05:15, 10 November 2015 (UTC)

If we add articles to categories based on wikidata properties then we have the job of continuing to synchronise wikidata and the category and what do we do with manual changes to the category. Better to go to dynamic lists (i.e. generated on-the-fly each time) based on wikidata queries instead. This allows much more complicated cross domain lists than we would ever want to do with a category. Filceolaire (talk) 06:15, 10 November 2015 (UTC)

I do not know of any tool that could create such a list, but if somebody wants to move articles from one category to another, this person could use the Category Master. At the moment the tool only has a user interface as input channel, but it could surely be made to work on lists of articles. There are screenshots, showing its usage here. Borislav and V111P can help with the technical details. --Lord Bumbury (talk) 10:53, 10 November 2015 (UTC)

Different Wikipedia languages have very different needs for categories, and not just based on size of Wikipedia. English language wikipedia has categories for churches in particular English counties, Wikimedia Commons has individual categories for thousands of English churches. Xhosa language Wikipedia might not even need a category for churches in England. WereSpielChequers (talk) 19:05, 10 November 2015 (UTC)

And then comes the category depth... Xhosa language Wikipedia could probably create category "Churches in United Kingdom" and take enwiki category with depth=10, lets say. --Edgars2007 (talk) 19:32, 10 November 2015 (UTC)

•  Endorsed The key to this, I think, is the use of a property such as d:Property:P360 to describe in Wikidata terms what a category contains, similar to the way that if the wikidata item for a list article has a description coded in this way, then Magnus's Reasonator viewer for Wikidata can automatically show a list of corresponding Wikidata items -- see eg Reasonator's presentation of item Q15832361 (List of female engineers). There are a couple of wrinkles that would need to be added for a Wikipedia category version: firstly, only include items for which there are actually articles in that language. So the category for English churches in Xhosa wiki might not be very long. Secondly, exclude any items that match the criteria for subcategories that exist on that wiki. So for an English county on en-wiki there might be sub-categories for churches in each of the major towns in that county -- the top level category would exclude churches in any of those towns. On a different wiki, with fewer English churches, there would probably be fewer subcategories; so the tool would therefore be putting more of the articles which did exist into the county-level category. All this would follow solely from what subcategories were defined for a particular wiki, and the wikidata description of the inclusion criteria for those categories.

The tool should probably be human-assisting, rather than fully automatic. I could see it highlighting a list of possible additions to the category, but giving the user to check or uncheck any of them before finalising the process. A second mode could suggest possible removals from the category, for any of the items that matched subcategory criteria. This would give a powerful tool for splitting categories, assisting the user to appropriately populate newly created subcategories. All of which I think could be very useful on Wikipedia right now; and the same system in future might be even more useful on Commons, once the structured-data machine-interpretable description of the topics depicted in images starts to become possible. Jheald (talk) 01:09, 11 November 2015 (UTC)

If this is being worked on it'll need a thorough product-level discussion about how to do this and how it interacts with other efforts like structured data for Commons. --Lydia Pintscher (WMDE) (talk) 14:20, 13 November 2015 (UTC)

• Comment There is a bot, namely User:Rezabot, in Persian Wikipedia that does the same task based on categories on English Wikipedia. It's an old bot and seems to be stable right now. I ping the operator User:Yamaha5 himself to explain more. 4nn1l2 (talk) 15:39, 18 November 2015 (UTC)

UI to display category members by timestamp

fr.wikipedia.org has hundreds of pages that contain lists of recent articles by portal (all these pages, plus some updated by other bots). This is the main way new articles can be reviewed by users interested in a specific domain.

Each portal has a tracking category, so this is certainly something that MediaWiki could support in a generic way. Ideally, there would be a special page to list the last n members of a category that can be included into others (like Special:PrefixIndex).

Note: MediaWiki already tracks these timestamps and makes them available through the API, but this request is not as simple as providing a UI for this. Based on the feedback received for bots, two additional constraints are that:

• changing the defaultsort should not reset the timestamp ;
• a quickly reverted removal of the category should not reset the timestamp.

Orlodrim (talk) 18:45, 10 November 2015 (UTC)

NB: Lists maintained by bots are used in different ways. Some users read the wikiproject page from time to time, while others the lists to there watchlist. Thus, a complementary feature request is #Add a Category watchlist, but both features are needed to replace bot-maintained lists of recent articles (for very large portals, not all users would want to watch a category with tens of new articles every day). Orlodrim (talk) 19:30, 10 November 2015 (UTC)

•  Endorsed Toto Azéro ^{follow the guide !} 17:53, 11 November 2015 (UTC)
•  Endorsed and see below. Jheald (talk) 12:49, 13 November 2015 (UTC)

Options to show categories sorted in further different ways

Developing from the above, it would more generally be good to be able to show categories ordered in ways other than their default sort-ordering. As well as sort by "last modification" date suggested above, on Commons it would be nice to be able to sort by date of upload, or date of underlying media creation, or date depicted in media, or by an extensible mechanism to be able to specify per-category that media in that category might have a particular sort key or keys (eg original page number), different from the original sort order. Jheald (talk) 12:49, 13 November 2015 (UTC)

Tools for dealing with citations of withdrawn academic journal articles

Please see this thread and this archived discussion.

I was thinking of a tool that would let users input a variety of ways of referring to the retracted articles, such as DOI numbers (Peaceray is an expert in these). The tool would accept multiple inputs simultaneously, such as all 64 articles that were retracted in a batch. The tool would return to the user a list of all articles in which those references are used as citations, and highlight the paragraphs of the article where the citations are used. This would, I hope, greatly improve the efficiency of the workflow for dealing with retracted journal articles. Hopefully the tool could work across multiple wikis and languages. --Pine^✉ 05:23, 16 November 2015 (UTC)

•  Endorsed This wouldn't affect many articles but it would greatly improve the quality of the project of retracted articles could be easily identified and flagged so readers know they are no longer reliable. Davidwr/talk 05:44, 16 November 2015 (UTC)

Category suggestions based on filename, description and location

For many users and especially for beginners it is hard to quickly find appropriate categories for files. To support the user i suggest to develop an algorithm that is suggesting such categories by checking the filename, the description and location of the file against already available files, categories and galleries in Commons. Even Wikidata and Wikipedia could be included. Having such an algorithm the UploadWizard could be enhanced to suggest categories for uploaded files. Furthermore, we could generate a maintenance list or even a game to enrich already uploaded but uncategorized files. --Aschroet (talk) 18:56, 16 November 2015 (UTC)

Numerical sorting

Names containing numerals (or with numeric sort-keys) are presently sorted in alphabetical/ASCII order, apparently being treated like any other character: for example “100” comes before “17” but after “10”. This makes a mess of categories for things with serial numbers, like asteroids and street addresses, unless they’re given sort-keys with zero-padded numbers—very tedious. Would it be possible to parse names for sorting by reading any consecutive numerals as digits of a decimal number, instead of just character-by-character, so as to sort by numeric value instead? Even my antique Mac’s Finder does something like this with file and directory names, so it can’t be that hard! ;) Odysseus1479 (talk) 05:12, 18 November 2015 (UTC)

•  Endorsed --Klaus Eifert (talk) 13:34, 18 November 2015 (UTC)
•  Endorsed -- Juetho (talk) 13:25, 19 November 2015 (UTC)

Show additions or removals of items from categories on watchlists

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Duplicate of #Add_a_Category_watchlist. Jheald (talk) 13:10, 13 November 2015 (UTC)

---

It would be good if there was an option to have additions to watchlisted categories, or removals from it, appear as watchlist notifications for a watched category. Jheald (talk) 12:38, 13 November 2015 (UTC)

---

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Commons

3D models on Wikimedia Commons

Tracked in Phabricator:
Task T3790

It would be nice if Wikimedia develop its infrastructures to host free 3d works, just like what Github and even thepiratebay! did while ago. Image thumbnails of 3D models can be used for content articles use, just like PDF files and video clips. Wikimedia foundation should keep itself relevant on new ways of FOSS communities contributions. Fortunately it is currently filed as a bug, phab:T3790 but not progressed much. --ebrahim^talk 22:51, 9 November 2015 (UTC)

•  Endorsed Possible use - 3D models of architecture on WLM --Ilya (talk) 23:27, 9 November 2015 (UTC)
•  Endorsed--Shizhao (talk) 02:02, 10 November 2015 (UTC)
•  Endorsed And note there is a general support for this at commons:Commons:Requests_for_comment/Hosting_files_for_3D_models. --Piotrus (talk) 05:02, 10 November 2015 (UTC)
•  Endorsed could be very useful for GLAM especially if we can also get the functionality to create 3d models from multiple images such as we already have - that would open a lot of doors for us in the GLAM world! WereSpielChequers (talk) 19:34, 10 November 2015 (UTC)
•  Endorsed While volunteering for the chapter, I encountered many ideas about 360 photographs of objects (i.e. from all sides) with rotation capability and other 3D or 3D-like capabilities. MW should definitely move in that direction. —Ynhockey (talk) 12:25, 11 November 2015 (UTC)
•  Endorsed Recently I was asked by somebody from a university paleontological museum what formats Commons preferred for 3d files from MRI scans of their collection, suitable for 3d printing. It was sad to have to reply "none". Jheald (talk) 12:54, 13 November 2015 (UTC)
•  Endorsed only if it is integrated into MediaWiki -- no extensions or gadgets. MER-C (talk) 16:25, 14 November 2015 (UTC)

Allow categories in Commons in all languages

Categories in Wikimedia Commons must be only in english, but Commons is a multilingual project and it should allow other languages.

This change would benefit Commons users that doesn't know english or with a poor level, I know many users of wikipedias that have a lot of problems with that, and that problem makes that many users don't use Commons. I think that the problem exists in a lot of wikipedias. Bye, --Elisardojm (talk) 11:32, 10 November 2015 (UTC)

•  Endorsed --Yann (talk) 16:27, 10 November 2015 (UTC)
•  Endorsed This has been for a long time on the wish list of Commons contributors. See for example c:User:Multichill/Next generation categories --Jarekt (talk) 19:32, 10 November 2015 (UTC)
• Can't we just do this by allowing more category redirects? That way we could still have one category but with redirects to it from multiple languages WereSpielChequers (talk) 19:59, 10 November 2015 (UTC)

@Elisardojm: One potential problem with having localized category names is that different languages may organize topics differently. (See previous discussion at phabricator:T87686.) Any thoughts about how these ontological differences would be resolved? Would we need to set up different category trees for different languages or just base the category scope on the English name and include detailed clarification in the non-English names when necessary? Ryan Kaldari (WMF) (talk) 22:47, 10 November 2015 (UTC)

Ryan I assume that we are only talking about i18n service. So all the translated category names would show up in user's language. They could be added using user's language, using HatCat and other automatic tools. When adding them to the wikitext description page, non-english category names would be automatically changed to English ones while saving. However the category tree would remain the same in all the languages. Another approach would be to use default translations pulled from wikidata when possible. For example c:category:Warsaw would show up as "Kategoria:Warszawa" to polish users where word "Warszawa" is copied from d:Q270. --Jarekt (talk) 03:55, 11 November 2015 (UTC)

•  Endorsed strongly. I heard this problem from many Japanese users.--aokomoriuta (talk) 14:51, 11 November 2015 (UTC)
•  Endorsed strongly, too. It's also a pain to feel forced to use media names translated into English or other dominating languages. --Jfblanc (talk) 09:19, 12 November 2015 (UTC)

  I don't know how tecnically it could be done, but I think that as same as now we have tools to translate pages, we could have a tool to translate the name of categories from english to the other languages. And translations could be transparent to the user, like it's done with templates and pages... Bye, Elisardojm (talk)

  See the proposal below. Filceolaire (talk) 06:56, 13 November 2015 (UTC)

  Yes this is a major part of bringing Wikidata support to Commons. --Lydia Pintscher (WMDE) (talk) 14:03, 13 November 2015 (UTC)

• Comment I think that every Commons category should be bounded in a 1:1 relationship to Wikidata concepts. This is consonant with the Multichill's proposal of category orthogonalization. --Usien6 (talk) 15:58, 13 November 2015 (UTC)

  Comment It would also make possible to implement the following feature: to notify an user that a certain article he is watching has a new photo available. --Usien6 (talk) 23:18, 18 November 2015 (UTC)

•  Endorsed of a 1-to-1 translation of commons categories, anything else, such as allowing uncontrolled use of non-English category names (other than when used as an alias of an English category name) is asking for trouble. Davidwr/talk 05:49, 16 November 2015 (UTC)

Structured metadata for Commons

Tracked in Phabricator:
Task T68108

We should resume the Structured metadata for Commons project. A lot of the problems Commons currently faces come from the fact that MediaWiki is not a very suitable content management system for media files. With structured metadata it does become a much more flexible and scalable content management system. All user groups would benefit from a better functioning Wikimedia Commons: It's easier to find suitable images, easier to classify images, more accessible, etc. Multichill (talk) 18:48, 10 November 2015 (UTC)

Also it would mean Commons (and the names of Commons Categories) could be localised in lots of languages. Filceolaire (talk) 16:54, 12 November 2015 (UTC)

•  Endorsed Jarekt (talk) 19:45, 10 November 2015 (UTC)
•  Endorsed Gbeckmann (talk) 20:35, 10 November 2015 (UTC)
•  Endorsed MisterSynergy (talk) 21:08, 10 November 2015 (UTC)
•  Endorsed Danmichaelo (talk) 21:24, 10 November 2015 (UTC)
•  Endorsed PierreSelim (talk) 22:11, 10 November 2015 (UTC)
•  Endorsed Thibaut120094 (talk) 23:34, 10 November 2015 (UTC)
•  Endorsed Spinster (talk) 00:29, 11 November 2015 (UTC)
•  Endorsed Shizhao (talk) 02:31, 11 November 2015 (UTC)
•  Endorsed Siebrand (talk) 06:29, 11 November 2015 (UTC)
•  Endorsed Amir (talk) 10:13, 11 November 2015 (UTC)
•  Endorsed Jean-Fred (talk) 13:41, 11 November 2015 (UTC)
•  Endorsed Sadads (talk) 15:03, 12 November 2015 (UTC)
•  Endorsed Filceolaire (talk) 06:55, 13 November 2015 (UTC)
• Groundwork for this is on-going in the Wikidata team and we will continue working on it. --Lydia Pintscher (WMDE) (talk) 14:04, 13 November 2015 (UTC)
• Comment This is related to a comment I made in another topic in this page. In verbis: I think that every Commons category should be bounded in a 1:1 relationship to Wikidata concepts. This is consonant with the Multichill's proposal of category orthogonalization. --Usien6 (talk) 16:02, 13 November 2015 (UTC)
•  Endorsed Long overdue. Waldir (talk) 13:43, 14 November 2015 (UTC)
•  Endorsed Can help with content discovery for both readers and editors (i.e. finding media to put into articles). harej (talk) 07:34, 15 November 2015 (UTC)
•  Endorsed --El Grafo (talk) 12:00, 16 November 2015 (UTC)
•  Endorsed --Aschroet (talk) 18:27, 16 November 2015 (UTC)
•  Endorsed --Jane023 (talk) 13:02, 19 November 2015 (UTC)

Support KML files in Commons

Tracked in Phabricator:
Task T28059

KML files are used in en.wikipedia to display route maps (eg roads, train lines, and other linear features) via w:en:Template:Attached KML (see d:Q6690822 for the equivilent on other wikis). Currently this is achieved by storing the KML files as text in subpages of the template (transclusion count for en.wikipedia), which is sub-optimal for multiple reasons:

1. There is no associated {{information}} template, for description, author, date, licence, information source, etc.
2. The licence is restricted to the standard licence for a wikitext page, rather than being able to choose a different licence such as CC0 or CC-BY
3. Categorisation is difficult, as including [[Category: ]] links at the end of the page breaks the KML file.
4. The KML files serve only one wiki – they cannot be shared with other wikis, nor associated with the relevant Wikidata item.

Being able to upload KML files to Commons would fix these issues; Commons has previously been suggested as the better place for the files (see w:en:Template talk:Attached KML). See also technical discussion at phab:T28059 "Add support for KML/KMZ filetype". - Evad37 (talk) 16:05, 7 June 2015 (UTC)

I wonder whether mw:Extension:Graph/Demo has the same problem with only being available on each wiki individually. Whatamidoing (WMF) (talk) 06:20, 10 June 2015 (UTC)

Very interesting thought. I search in phab:tag/graph/ and mw:Requests_for_comment/Graph but could not find any mention to Graph + Commons. Should be create a task to start the discussion?--Qgil-WMF (talk) 07:59, 10 June 2015 (UTC)

Yurik talked about it briefly during his tech talk (in the form of interwiki transclusion). Interwiki transclusion is kind of a big thing. Allowing vega json files to be uploaded to commons would be a simpler approach but has its own pros/cons. Bawolff (talk) 00:55, 13 June 2015 (UTC)

The "Attached KML" scheme as it stands presents puzzles to unlucky readers of articles offering them. If the "KML file" option is clicked on, no actual .kml file results, instead a file index.php is presented for download. Such a file type is simply ignored by Google Earth, unless it is renamed to index.kml for example. Via Firefox's interface, there is no option to rename this file before downloading. Further, windows systems are often set to not show the file's "type" (and installation policy choices may prevent a user changing that setting), so users of IE8 (which does offer a file rename if the file is to be saved) may still be stuck. As .kmz files are much more compact, the same convenience would apply. Some browser/server exchanges can agree to engage in file compression, but having the source file definitely compressed would be more direct. NickyMcLean (talk) 10:38, 17 June 2015 (UTC)

To add some numbers, the Attched KML templates across the various language versions of wikipedia have over 9800 transclusions combined, the largest of which are en.wikipedia (8341 transclusions, and template-protected as a high-risk template) and cs.wikipedia (1062 transclusions). - Evad37 (talk) 05:45, 25 July 2015 (UTC)

Tracked in Phabricator:
Task T57549

See also phab:T57549 for a possible alternative approach using wikidata - Evad37 (talk) 10:05, 17 August 2015 (UTC)

•  Endorsed although we might not be able to display them online. --Jarekt (talk) 16:58, 11 November 2015 (UTC)
•  Endorsed I think we need much more robust handling of .kml exports, expecially in Commons. The main tool, kmlexport, is regularly down and poorly-maintained. This is a longstanding issue which has yet to be addressed. Rodhullandemu (talk) 21:23, 11 November 2015 (UTC)

Tracked in Phabricator:
Task T92963

•  Endorsed this is way overdue. Imzadi 1979 → 03:50, 12 November 2015 (UTC)
•  Endorsed--Shizhao (talk) 07:57, 12 November 2015 (UTC)
•  Endorsed Yes. Jheald (talk) 12:56, 13 November 2015 (UTC)
•  Endorsed --El Grafo (talk) 12:03, 16 November 2015 (UTC)

Copyvio tools for Commons

Copyright on Commons is a topic that is at times, subject to abuse. Some images are left for long periods of time because people are afraid to tag them, and other times images are subject to the copyright whims of admins. It would be helpful if there were tools to both help detect possible violations (there are perhaps databases we can match things up against?) and a better method for screening images once detected.

I wondering if using google image search at the time of upload would be useful for creating an autodetection method? We would also need to build a whitelist to reduce false positives. Doc James (talk · contribs · email) 04:09, 22 May 2015 (UTC)

 Endorsed I agree. I think a good first step would be use perceptual hashing to see if a similar image was previously deleted. I imagine lots of copyvios are uploaded again and again. Bawolff (talk) 04:20, 10 June 2015 (UTC)

I could not find a Phabricator task for this request. I think it would be useful to have one, if someone wants to create it (#Possible-Tech-Projects?).--Qgil-WMF (talk) 07:51, 10 June 2015 (UTC)

•  Endorsed We could add new filters to c:Special:NewFiles tool so Commons users can browse for new uploads that are:

• from new users (we already have newbie-upload tool),
• from users with a lot of recent deletions,
• do not have EXIF data,
• are small,
• known to google image search,
• were deleted before
• do or do not claim {{own}} ("own work")
• do or do not use c:template:Custom license

etc. All those factors increase a chance that an image is a Copyvio and it would be mice if we could add and remove those filters in any combination. --Jarekt (talk) 17:29, 11 November 2015 (UTC)

•  Endorsed Most but not all previously deleted files probably need to be deleted when people try to reload them. WereSpielChequers (talk) 21:27, 11 November 2015 (UTC)
•  Endorsed--Shizhao (talk) 08:03, 12 November 2015 (UTC)
•  Endorsed We should have something like this since long. --Yann (talk) 13:55, 17 November 2015 (UTC)
•  Endorsed 4nn1l2 (talk) 22:12, 18 November 2015 (UTC)

Dark archive

Everyday thousands of pictures get deleted from Commons because they are not public domain yet (any picture of recent architecture in France, for instance). Most of these pictures are probably lost forever, as the contributors are unlikely to store them safely and try again 30 years later.

Instead of deleting them, these pictures should be put in a "dark archive" with a reconsideration date. Picture of the dark archive can not be seen by anyone (except probably a few trusted Wikimedia employees), only metadata can be seen (description, categories, copyright status, reconsideration date, file size), some of this metadata can be edited. In some cases a low-quality thumbnail might be legal. Syced (talk) 07:50, 11 November 2015 (UTC)

To my knowledge, all images that are deleted are recoverable by administrator, including the description page that are previously there. Kenrick95 (talk) 09:18, 11 November 2015 (UTC)

That is true, however, there is no way of searching deleted images. I suppose that is the problem that is wanting to be solved here. This, that and the other (talk) 08:52, 15 November 2015 (UTC)

What admins can delete, they can undelete, see e.g. c:Category:Undelete in 2016. There's nothing that needs to be done here. MER-C (talk) 15:19, 11 November 2015 (UTC)

•  Endorsed There is a user-based system, see for example commons:Category:Licensing-related deletion requests. But it has unclear structure, and is not always implemented. The point is to categorize all Commons deletion templates, with an automated restore function, ex. this image should be automatically restored on 1st January 2024, etc. --Piotrus (talk) 04:32, 12 November 2015 (UTC)
•  Endorsed. Sound idea. --Jfblanc (talk) 09:20, 12 November 2015 (UTC)
•  Endorsed Bright idea! Lots of files are capable to be undeleted after a reasonable amount of time e.g. 10 years from now on. I'm sure Wikipedia will still be alive 10 years later! 4nn1l2 (talk) 22:17, 18 November 2015 (UTC)

Allow tabular datasets on Commons (or some similar central repository)

It would be good to have somewhere central that tabular datasets could be uploaded to -- eg the data to be plotted by the graphs extension.

The data should be uploadable and exportable in a variety of standard formats -- eg CSV, TSV, JSON, XML -- and stored in a format-neutral way.

Wikidata is great for single values, or values to be scattered across multiple items, but it's not so good for data in a systematic 1-dimensional or 2-dimensional form. Jheald (talk) 13:24, 13 November 2015 (UTC)

•  Endorsed Would this be in the main namespace or in a dedicated Data namespace? There's already a specialized commons:Special:PrefixIndex/GWToolset: with lots of JSON files. -- SPage (WMF) (talk) 08:54, 16 November 2015 (UTC)
•  Endorsed This would be incredibly useful for data-heavy graphs, while streamlining their encoding where deployed. Swpb (talk) 19:34, 17 November 2015 (UTC)

Community

Opt out of Thanks feature

Some people (for example me) would like to opt out of the Thanks feature. Disabling and enabling this feature should be logged in the Thanks log. The Quixotic Potato (talk) 14:06, 12 November 2015 (UTC)

If you simply just don't want to get the notification, that somebody has thanked you, you can opt-out in your preferences. --Edgars2007 (talk) 15:42, 12 November 2015 (UTC)

I know, that is not what I want. The Thanks-feature reduces meaningful interaction between humans and replaces it with a Facebook-style Like button. The Quixotic Potato (talk) 16:05, 12 November 2015 (UTC)

@The Quixotic Potato: If I read you right, your problem with Thanks is that it's impersonal. So how about we make Thanks more personal? Are you okay with that? - Thanks; LeoRomero (talk) 20:09, 12 November 2015 (UTC)

Making Thanks "more personal" is a messier idea than it may seem. The existing Thank system has already been abused for harassment, the Thanks log would need to be subject to Oversighting, and there were reasons the Thanks log was deliberately designed to be impossible to connect to the specific edit being Thanked. Alsee (talk) 15:22, 14 November 2015 (UTC)

@Alsee: How would you make Thanks more personal? How is Thanks abused to harass? How to prevent the abuse you cited? - Thanks; LeoRomero (talk) 17:35, 14 November 2015 (UTC)

@LeoRomero: Of course I am OK with that, but my problem with Thanks is a bit more complex. Explaining it in detail is offtopic here so I'll use the Collapse template:

Extended content
I believe that an imperfect Wikipedia article triggers something similar to a fight-or-flight response. You can chose to stay and improve it, or you can simply close the tab and move on with your life. For example, if I see an article about Israel/Palestine that is not neutral I will flee, and if I see a typo on a random article I will probably fight it. Of course there is a grey area in the middle. When I read stuff like this or that or that then I will usually remove it but sometimes I ignore it. Facilitating laziness has downsides. For example, it is much easier for me to tag an article than it is to remove the POV and try to find neutral sources to create a more balanced article. I understand that tagging has its benefits, but I am a lazy person so I end up tagging certain problems instead of actually fixing that problem. If I didn't have the option to tag problems then I would've fixed many of those problems. Before the Thanks-feature the people who wished to extend their gratitude to someone who did something useful would write a personal handwritten thank you note on their talk page. One of the reasons why they did that is because there was no other way; this was the laziest method available. The WikiLove extension is a good idea, it makes it easier for people to leave adorable kittens or lovely snacks on other peoples talkpages, and most users of this extension still write a short message explaining why they think that that person deserves it. Those short thank-you notes have multiple benefits, they make people happy, people are proud of a talkpage full of thank you messages (don't underestimate the importance of this, they see them frequently and they know others see these messages too), and often people end up having a pleasant conversation with the person who wrote the thank you message which may result in a collaboration. These messages are the only thing they get in return for their volunteerwork. They encourage people to keep up the good work. The Thanks feature makes it a lot easier to thank people (which reduces the value, this is called inflation). But instead of a personal handwritten message you get an impersonal +1 (or Facebook Like). It is hidden away in some sort of log (how impersonal can you get?) and other people are unable to see it (no more bragging rights). No one looks at the Thanks log, not even their own. Looking at my own Thanks log makes me sad. If you are a gnome fixing typos then you can fix thousands of typos without any human contact whatsoever. All you get is a logbook like this. If the Thanks feature didn't exist then at least a handful of the people who have used it to thank me would've written a real, personal, message which would actually have value, both to the writer and the recipient. Of course you still get messages telling you you did something wrong... People are worried about editor retention and the lack of female contributors but they don't seem to realize it that stuff like the Thanks feature is a part of that problem, not the solution. @The Quixotic Potato: Solid analysis, thanks. And lolz on Of course you still get messages telling you you did something wrong... Agree that tagging pages rather than old-school improvement has made it super easy to be lazy, and is in other ways counterproductive (f.e demoralizing to contributors who gave heart & soul to the page). Also agree that we ought to give thoughtful thanks, not just Thanks. Also also agree that Thanks ought to be visible on User Talk. Not clear to me how Thanks hurts retention and inclusion, but it doesn't have to be clear to me: I get your key points. I think Thanks is a good idea that can be made better. I'll give this more thought, and maybe post a relevant suggestion of my own. Anything else I ought to think about? - Thanks again; LeoRomero (talk) 00:48, 14 November 2015 (UTC) @LeoRomero: You haven't explained why you believe Thanks is "a good idea that can be made better". I just explained that it is terrible. The Thanks feature hurts retention and inclusion because people who were in a bad wikimood used to look at their talkpage full of handwritten thank you messages, which would improve their wikimood. Nowadays many talkpages are lists of complaints and people give and receive fewer barnstars and wikilove because using the Thanks feature is much easier for lazy people. That has been replaced by a log full of meaningless Facebook Likes. Many people who are here today are here because someone left them a personal thank you message on their talkpage after they made their first couple of edits. Of course you can believe that improving Wikipedia should be enough of an reward in itself, but in reality things don't work that way. Positive interaction between Wikipedians and new Wikipedians is extremely important. If you believe in kindness, then endorse this proposal, I mean, it is kind to allow people to opt out of functionality they dislike, right? The Quixotic Potato (talk) 11:47, 14 November 2015 (UTC) @The Quixotic Potato: [PS: Does ping work here? I haven't been getting your pings.] (I've never written a PREscript before, might want to make that a thing). You're right - I do believe that improving Wikipedia is its own reward. My motivations tend to be intrinsic; I haven't ever looked at my Thanks log (didn't even know it existed). But (I'm almost embarrassed to say) I do get the warm & fuzzies when I see Thanks in my inbox, so totly get your wikimood points. I think Thanks is a good idea, because it's a good idea to say thanks. You and I agree on that. We also agree that humans have evolved to conserve energy (t.i we're lazy). Most people can't be bothered to craft the little thank you notes that you and I write. Astonishing that they can even manage the two clicks it takes to send Thanks. it's good to give the lazies an easy way to express gratitude; better than not practicing gratitude at all. Thanks was part of the Kindness Initiative (is that still a thing?), and as you noted, kindness is a big deal to me. I believe that it's essential that we move beyond Civility and develop a Culture of Kindness (my initial thoughts and research on that is here). I think Thanks needs improvement, because of the unintended consequences that you noted (which hadn't even occurred to me, so Thank You) it ought to enable more than superficial engagements among community members - at least explain in less than 140 characters why you're sending Thanks it ought to appear prominently on User Talk, f.e a bot-made new section/topic entry that says something like "You just got thanked by [[ ]]! Wikipedia thanks you too." Did I miss anything? You mentioned the WikiLove extension - can that be activated when someone clicks on Thank? Having said aaaallll that (this may be the longest user note I'd ever written), I do agree that "it is kind to allow people to opt out of functionality they dislike". So despite all my misgivings, I endorse. With deepest thanks, LeoRomero (talk) 17:35, 14 November 2015 (UTC) Yes, WikiLove can be activated when someone clicks on Thank, it would be very very easy for a programmer to do that. You wrote: "it's good to give the lazies an easy way to express gratitude; better than not practicing gratitude at all" but in reality the people who weren't too lazy are now using this lazy method and the people who weren't expressing gratitude still aren't. The problem is not just that you are unable to express WHY you are sending Thanks, but also that you are unable to respond to being Thanked. This is a great conversation starter that can lead to friendship and collaborations. I don't know why pinging doesn't work. I think the solution is as follows: Remove the Thanks feature. Remove the Thanks log. Replace it with a WikiLove feature. So instead of a Thanks link you get a WikiLove link. When clicking on the WikiLove link you can give a barnstar, a kitten or a snack and you are encouraged to leave a personal message (just like the WikiLove extension is doing currently). The result shouldnt be hidden away in some log somewhere, it should be displayed prominently on the user's talkpage. The Quixotic Potato (talk) 23:27, 14 November 2015 (UTC) @The Quixotic Potato: WikiLove it! I'm superbusy right now, but as soon as I can, I'll "remix" (pinch) your ideas, and make a wish of my own. Unless you can get to it first, so I don't mess up your work (and so I get to endorse you again). Snack included with this thanks; LeoRomero (talk) 01:58, 16 November 2015 (UTC) @The Quixotic Potato: As the author of both the WikiLove and Thanks extensions, I guess I should comment here. The two extensions were designed to compliment each other. WikiLove made it easier to send personalized public thanks, while the Thanks extension enabled quick thanks without interrupting an editor's workflow. While it's a legitimate concern that letting people give "lazy" thanks reduces personalized messages of thanks, the existing data does not support such a conclusion. If you look at the chart below, you can see a history of the usage of WikiLove on the English Wikipedia. In about the middle of the chart is a red line showing when the Thanks extension was enabled (end of May, 2013). If your hypothesis was correct, we would expect to see a decline in WikiLove usage around that point. While there is a very gradual decline from June 2012 to today (and an unexplained steep decline between April 2012 and June 2012), usage does not seem to have been significantly affected by the introduction of Thanks. Ryan Kaldari (WMF) (talk) 05:30, 17 November 2015 (UTC) Chart showing history of WikiLove usage on English Wikipedia. Red line indicates the introduction of the Thanks feature. @Ryan Kaldari (WMF): Hi Ryan! Nice graph. Unfortunately that is a straw man. I didn't claim that the Thanks feature reduced the amount of WikiLove messages (AFAIK). I was saying that the Thanks feature reduced the amount of personal handwritten thank you messages. But gathering data for that is a bit more difficult... The Quixotic Potato (talk) 05:59, 17 November 2015 (UTC) Yeah, I'm kind of extrapolating :) I have no idea how I would get any useful data on personal handwritten thank you messages. Ryan Kaldari (WMF) (talk) 06:17, 17 November 2015 (UTC) Would you be willing to test the theory for (for example) a month or so, by simply popping up the WikiLove dialog when someone clicks on the Thanks link. I think people will use it less frequently, but I also think that both the sender and the recipient value those messages way more than a Thank. You can't measure that kinda stuff. The Quixotic Potato (talk) 06:07, 17 November 2015 (UTC) @The Quixotic Potato: It's an interesting proposal, but how would you judge the success or failure of the experiment? Ryan Kaldari (WMF) (talk) 06:17, 17 November 2015 (UTC) @Ryan Kaldari (WMF): Not with hard data. We both like numbers, but sometimes it is (almost) impossible to get meaningful statistics, especially when we are talking about human emotions. I think this is one of those cases. But you can ask around a bit, many people here proudly display the barnstars they've received and they remember who gave them and why. Receiving an adorable kitten or a snack makes them happy, and after they've received them they still regularly see them on their talkpage. But I don't think many people have fond memories of the time someone clicked the Thank link and they received something that I would compare to a Facebook Like. If you ask some oldtimers here, who have experience with receiving WikiLove and Thanks, then I think they will prefer WikiLove, but maybe that isn't quantifiable. But of course there were also no statistics about the usage of Thanks when it was introduced. The WikiLove extension is an excellent idea, and the idea to stick a link on the diff compare screen to thank people is also good, but it should lead to the WikiLove popup (or something similar). And if you totally disagree with me and refuse to do an experiment, would you be so kind to allow people to opt out? If people don't see a Thank link near my name then they'll be forced to thank me manually. The edits I make are usually incredibly boring. For example, I've made hundreds of edits like this one or this one or this one, so it is important to stay motivated. It is very difficult to explain why, maybe I am crazy, but I've spent a beautiful sunny day inside, manually fixing problems caused by a bot a long time ago. Someone noticed, and I received a barnstar with a kind message attached. If I had to chose between that barnstar and 61 Thanks then I would prefer to keep the barnstar. The Quixotic Potato (talk) 10:59, 17 November 2015 (UTC) I think where we disagree is that I don't believe that Thanks has a significantly negative effect on sending barnstars and other personalized messages. If a lot of people support your proposal, however, we'll be happy to consider it. Ryan Kaldari (WMF) (talk) 16:59, 17 November 2015 (UTC) @The Quixotic Potato: @Ryan Kaldari (WMF): Thanks for all the thoughts and data (I heart charts). How about this Suggestion: Tweak Revision History to (undo | thank | love)? LeoRomero (talk) 20:17, 19 November 2015 (UTC) PS Ryan, I didn't know until now that you did both Thanks and WikiLove. WOW what an honor to meet you.

Just undeploy this extension and be done with it. MER-C (talk) 15:47, 14 November 2015 (UTC)

@MER-C: Do you have anything to add to TQP's analysis? - Thanks; LeoRomero (talk) 17:35, 14 November 2015 (UTC)

•  Endorsed LeoRomero (talk) 17:35, 14 November 2015 (UTC)
•  Oppose The Thanks feature obviously doesn't replace manual thanks. So you won't get more manual thanks if you get out of this. Yann (talk) 14:21, 17 November 2015 (UTC)
•  Oppose If the proposal is to do away with the Thank feature, rather than just to allow people to opt out, I'm strongly against it. I think Thank is one of the best recent additions. It serves a different purpose from kittens or handcrafted thank-you messages, as a quick acknowledgement which can be both sent and received with minimal interruption of the work-flow. If I reply to a "helpme", a "Thank" tells me the answer was useful, and I do not need to check back on the page; it also gives me a small warm glow, which is enough. I have no interest in having my talk page full of thank-you messages or WikiLoves. If Thank were removed, some people might acknowledge small kindnesses with written messages instead, but I think more would not bother, and on balance we would lose. JohnCD (talk) 22:38, 17 November 2015 (UTC)

Modify "Thank you" so we can thank anonymous editors

Tracked in Phabricator:
Task T63022

I often want to thank an anonymous editor for a great edit. This should be possible. (Yes, I know that IP addresses are generally not static.) Thanks, --Gnom (talk) 10:16, 12 November 2015 (UTC)

 Endorsed Unanonymous thanks for this, although an anonymous editor might not care to be thanked - LeoRomero (talk)

 Oppose The Thanks feature has a very negative effect on Wikipedia. I have explained why in the section above. Why don't you write a personal message, or use the WikiLove extension? Thanking anonymous editors with the Thanks feature is technically impossible, because IP's aren't static. It would be weird if I use Wikipedia on my phone and I suddenly end up with a long Thanks log for edits I haven't made. Very confusing for new people. The Quixotic Potato (talk) 01:27, 13 November 2015 (UTC)

 Endorsed I've wanted to do this several times. In addition, I think the thanks should be displayed in the page history, not tucked away at the thanks log. Waldir (talk) 13:47, 14 November 2015 (UTC)

@Waldir: Page history??? Do you mean user talk page? The Quixotic Potato (talk) 14:00, 14 November 2015 (UTC)

No, I mean in the page history of the diff that was thanked. Next to the undo links, for example. After all, aren't thanks meant to be public? I never understood how this intent was considered materialized, when they're only visible to the thanked user and in an obscure log few people would ever visit deliberately.

 Oppose per above. This extension should not even exist. If you want to thank someone, go to their user talk page and thank them. MER-C (talk) 15:46, 14 November 2015 (UTC)

 Endorsed positive feedback is superior to negative feedback; if you delete thanks extension, also delete all the automated warning templates for the same reason. Slowking4 (talk) 04:40, 15 November 2015 (UTC)

@Slowking4: ??? Did you read the section above, especially the stuff inside the collapse template? The Quixotic Potato (talk) 04:57, 15 November 2015 (UTC)

yes i did. the same logic that deprecates thanks also can be used against template talk warnings. blow them all up. all of the newbies i talk to like thanks; are you then elevating your cynicism above their naivite ? Slowking4 (talk) 05:04, 15 November 2015 (UTC)

@Slowking4: I do not understand what you mean, and it seems that you do not understand what I mean. The logic I used against the Thanks feature cannot be applied to template talk warnings. I am not claiming that you shouldn't be allowed to Thank newbies, the preferred outcome is that the Thank feature is replaced by WikiLove. This means that you will be able to send cute kittens and lovely snacks and even barnstars to IP editors. The Quixotic Potato (talk) 05:28, 15 November 2015 (UTC)

 Endorsed I have also wanted to do this on multiple occasions. I suspect in most cases, it'll disappear into "the Void", never to be seen by the person of interest behind the IP, but still... And, who knows? Maybe the next person editing from that IP will be greeted by an unexpected "Thanks", and become intrigued by the project!! IJBall (talk) 03:30, 17 November 2015 (UTC)

Identify the most burdened Wikimedians

Tracked in Phabricator:
Task T105943

This is a Community Tech team task. Perhaps contributors could comment here or at the Phabricator page with suggestions for the most burdened classes of Wikimedians. What technical tools would be helpful? Rogol Domedonfors (talk) 06:35, 26 July 2015 (UTC)

Make Ping independent of signature

Currently Ping needs a signature to work. If someone forgets to sign while pinging, ping won't work. I've seen lots of users who forget to sign at the first step, but will sign a few moments later and still expect to send their ping, while it is not sent! I think the MediaWiki software should be able to identify the ping operator, independent of signature. 4nn1l2 (talk) 23:03, 18 November 2015 (UTC)

Editing

Improved diff compare screen

Don't you just love diffs like this one. It must be possible to improve this diffcompare-view. For inspiration you can look at the wikEdDiff gadget. http://i.imgur.com/R9ZfCA1.jpg The Quixotic Potato (talk) 06:41, 29 September 2015 (UTC)

@The Quixotic Potato: or cleanDiff, which is more like Wikimedia edit diff. Screenshot. --Edgars2007 (talk) 03:17, 3 November 2015 (UTC)

 Endorsed Related: phab:T108664 ("Provide an interactive edit conflict resolution tool"), phab:T26617 ("Implement diff on sentence level"). cscott (talk) 18:30, 11 November 2015 (UTC)

 Endorsed Very important. WikEdDiff already exists and the only thing that needs to be done is to make it work with the button "Show changes" while editing, right now this only works if the whole WikEd is enabled (then there is a separate button for WikEdDiff). --V111P (talk) 23:22, 12 November 2015 (UTC)

@V111P: Not true. You can enable WikEdDiff separately: w:en:User:Cacycle/wikEdDiff. --Edgars2007 (talk) 06:48, 14 November 2015 (UTC)

@Edgars2007: I know, but it doesn't work when editing, with the WikEdDiff gadget you can't see what changes you made before saving, so it's not a full replacement for WikEd. We use scripts for formatting and need to be able to look at the changes before saving. I already asked Cacycle on WikEdDiff's talk page about that, but don't know if and when I'll get a response. --V111P (talk) 09:30, 14 November 2015 (UTC)

OK, thanks. Didn't notice that. --Edgars2007 (talk) 09:58, 14 November 2015 (UTC)

 Endorsed improvements to diff. My pet peeve is when diff gets confused and lists unchanged paragraphs as both - and + text. It would also be nice if diff were smart enough to avoid cutting two <tags> in half (start and endpoints of diff-text inside tags) when it would be much cleaner to align on the tag boundary. I'm sure there's a lot that could be improved if diffs were targeted as a project. Alsee (talk) 20:22, 14 November 2015 (UTC)

 Endorsed. This sounds like a good idea, since I think it would be a very useful improvement. Would this include improving the diff when removing empty lines, or when moving sections, as in the suggestion below? That would not the least be a useful feature, to the extent that it is possible to achieve. Flinga (talk) 16:43, 17 November 2015 (UTC)

 Endorsed 4nn1l2 (talk) 23:24, 18 November 2015 (UTC)

Improve diff to show when a user moves a whole paragraph and then edits it

When someone moves a paragraph and then edits it, this edit is not shown separately by the "Difference between revisions" functionality. This problem also occurs when someone inserts a blank line above a paragraph and then edits it. Thanks, --Gnom (talk) 10:12, 12 November 2015 (UTC)

@Gnom: answer to your problem is w:en:User:Cacycle/wikEdDiff. --Edgars2007 (talk) 06:50, 14 November 2015 (UTC)

Hi, Edgars2007, there are also other user scripts that address this problem. I would like to see one of these solutions integrated into MediaWiki. --Gnom (talk) 09:36, 14 November 2015 (UTC)

 Endorsed Wouldn't that be included in the improved diff-suggestion above? Otherwise, I definitely endorse this. Flinga (talk) 16:47, 17 November 2015 (UTC)

Semiautomatic generation of "references"

Today one of the most frequent omission in new aticles is the need to enter "references" when there exist "ref"s in the text. It ought to be posbile to "propose" to the edistoir these in the right place.Yger (talk) 10:49, 11 November 2015 (UTC)

Halve edit conflicts

Tracked in Phabricator:
Task T72163

We all get edit conflicts, those of us who have stayed on wikipedia are largely those who have learned to resolve them, or to do lots of little edits in order to minimise the time lost when we get an edit conflict. There have been many proposals on bugzilla and elsewhere to reduce edit conflicts, but they haven't had resource as keeping new editors didn't use to be a priority. But this is one of the things that new editors find most bitey about wikipedia, and usually it is the newbie who loses the edit conflict because they are taking minutes on their edit and the categoriser or templater only seconds. (V/e of course makes this worse by getting rid of section editing and slowing editors down.

Currently we don't even have public statistics on number of editors lost through edit conflicts. Simply measuring them and the number of times they predict an editor leaves would either confirm this was one of the biggest causes of good new editors leaving, but actually fixing some of the things that cause edit conflicts would likely take as little resource.

Getting rid of all edit conflicts would require a revolutionary change in the user interface, but halving edit conflicts would take a fairly minor investment.

Specific ways to reduce edit conflicts include:

1. Treat the addition of a template at the top of an article or a category at the end as not conflicting with the alteration of the contents in between.
2. Pre populate all newly created articles with sections such as ===References=== and ===See also=== or equivalents in other languages
3. Treat # the same as a section heading so two replies in two different threads of the same section would not be treated as a conflict. WereSpielChequers (talk) 20:54, 10 November 2015 (UTC)

• Obvious  Endorsed. MER-C (talk) 21:36, 10 November 2015 (UTC)
•  Endorsed Great idea! ONUnicorn (talk) 23:09, 10 November 2015 (UTC)
• Related: phab:T108664 ("Interactive edit conflict resolution tool") Cscott (talk) 19:33, 11 November 2015 (UTC)
• Proposal (1) sounds simple enough. (2) is probably not a good idea. (3) should be obviated by Flow. Swpb (talk) 19:42, 17 November 2015 (UTC)
•  Endorsed Huge wall for newcomers, and for others too. Three-way diff on conflict could help experienced editors there. — Arkanosis ^✉ 16:30, 18 November 2015 (UTC)
•  Endorsed 4nn1l2 (talk) 23:28, 18 November 2015 (UTC)

Color-coded WikiText editing

Tracked in Phabricator:
Task T101246

Tracked in Phabricator:
Task T104479

There have been some experiments around color-coded WikiText editing (including an English Wikipedia gadget and a working implementation in the Android app). This could be made into a real feature of the WikiEditor extension.

Is it like mw:Extension:CodeMirror? --Pastakhov (talk) 17:40, 20 May 2015 (UTC)

Yes I low the color coding of text that WikEd gives and miss it when I edit other languages. Sometimes I even work on text from other languages on En Wikipedia because we have better tools. We need a set of tools that the WMF will install on all Wikis that wish to opt in. Doc James (talk · contribs · email) 10:31, 21 May 2015 (UTC)

@Doc James: actually you can install for yourself set of tools to be loaded globally. See mw:Help:Extension:GlobalCssJs. If you need some help, you can use my talk page here or @enwiki. --Edgars2007 (talk) 11:47, 12 November 2015 (UTC)

 Endorsed +1 --AS (talk) 16:29, 27 May 2015 (UTC)

This could be considered part of the "modern wikitext editor" project. Cscott (talk) 18:21, 11 November 2015 (UTC)

Yes, the VisualEditor team is definitely planning on doing this as part of the modern wikitext editor project. However, it's not being actively worked on yet and probably won't be for another quarter or two. I leave it up to the Community Tech team whether to include it in their survey, but I don't think they want to take on things that other teams have fairly concrete plans to do :)—Neil P. Quinn-WMF (talk) 20:16, 11 November 2015 (UTC)

Actually, let me clarify a couple of things. The project is to build a new wikitext editor with all these features (to avoid suddenly breaking users' workflows and gadgets). This wouldn't help people who strongly want to stick with the existing editor. In addition, syntax highlighting (within the context of a VE-like wikitext editor) is apparently more complex than it seems, and may have a negative impact on performance. So the new wikitext editor will probably include syntax highlighting, but it's not 100% certain, and it may be an opt-in preference rather than the default.—Neil P. Quinn-WMF (talk) 20:43, 11 November 2015 (UTC)

I think it's actually *very* useful to include things in the community wishlist which are already on WMF roadmaps. As Neil notes, it's not a near-term project for the Visual Editor team. The community wishlist is an opportunity to rank all these different *community wishes* against each other. If this proposal ends up ranked high on the wishlist, the VE team perhaps should reprioritize their work. Conversely if it is low, they should perhaps continue to defer this. We need these feedback mechanisms to allow the community to weigh in on the priorities of WMF teams. Cscott (talk) 21:57, 18 November 2015 (UTC)

 Endorsed--Shizhao (talk) 07:59, 12 November 2015 (UTC)

 Endorsed --Edgars2007 (talk) 11:47, 12 November 2015 (UTC)

 Endorsed WikiText editor one of features most used by editors is not improved at all. Syntax highlighting is feature from the 1980's, but still missing in MediaWiki in the 2010's, 30 years after --Ilya (talk) 20:06, 15 November 2015 (UTC)

Turn RefToolbar into a MediaWiki extension (or add it into the WikiEditor extension)

Right now Reftoolbar is only available on English Wikipedia (although there is a very limited version on Malayalam Wikipedia). It has frequently been requested that it be turned into an extension so that other Wikipedias can also use it.

 Endorsed +1 Yes we need to make adding references as easy as possible. Doc James (talk · contribs · email) 11:37, 27 May 2015 (UTC)

Isn't mw:Citoid the extension that aims to cover Reftoolbar's feature set?--Qgil-WMF (talk) 08:13, 2 June 2015 (UTC)

I don't believe so. Citoid is for automatic reference creation. RefToolbar is for (mostly) manual reference creation. Kaldari (talk) 17:13, 16 July 2015 (UTC)

It looks like there isn't any chance of this happening, since the editing team is building a new WikiText editor that will have the VE citation-building interface. See bug T104479[7] (links from mw m w). Kaldari (talk) 18:41, 29 September 2015 (UTC)

Citoid does the automatic reference creation part, but the 'Manual' tab in the cite inspector lets you choose Book/Website/Journal/... templates and uses TemplateData to make completing those easy on any wiki (not just English). As you can now seamlessly switch between VisualEditor and WikiEditor it wouldn't be sensible to invest any more time in RefToolbar, when we already have a superior feature in VE. ESanders (WMF) (talk) 04:46, 12 November 2015 (UTC)

 Endorsed--Shizhao (talk) 07:58, 12 November 2015 (UTC)

Wikitext paste conversion tool interferes with table pasting from MS Word for one user(?)

Tracked in Phabricator:
Task T117859

Till last week Whenever I was coping table form ms word and pasting that in visual editor, than that table was converted in wikitable format. you can see here... https://sa.wikipedia.org/w/index.php?title=%E0%A4%95%E0%A4%B0%E0%A5%8D%E0%A4%AE%E0%A4%A3%E0%A5%8D%E0%A4%AF%E0%A5%87%E0%A4%B5%E0%A4%BE%E0%A4%A7%E0%A4%BF%E0%A4%95%E0%A4%BE%E0%A4%B0%E0%A4%B8%E0%A5%8D%E0%A4%A4%E0%A5%87...&action=edit&section=4

But In this week some other process is called "Converting Wikitext". In that process my table is not being as wikitable and it pasted like this...

अन्वयः विवरणम् यदा अव्ययम् ते युष्मद्-ज. सर्वे.ष.एक. श्रुतिविप्रतिपन्ना आ.स्त्री.प्र.एक. बुद्धिः इ.स्त्री.प्र.एक. समाधौ इ.पुं.स.एक. निश्चला आ.स्त्री.प्र.एक. अचला आ.स्त्री.प्र.एक. स्थास्यति √ष्ठा गतिनिवृत्तौ-पर.कर्तरि, लृट्.प्रपु.एक. तदा अव्ययम् योगम् अ.पुं.द्वि.एक. अवाप्स्यसि अव+‍√आप्लृ व्याप्तौ-पर.कर्तरि, लृट्,प्रपु,एक.

केशव अ.पुं.स्मबो.एक. समाधिस्थस्य अ.पुं.ष.एक. स्थितप्रज्ञस्य अ.पुं.ष.एक. का किम्-म.सर्व.स्त्री.प्र.एक. भाषा आ.स्त्री.प्र.एक. स्थितधीः ई.पुं.प्र.एक. किम् किम्-म.सर्व.नपुं.प्र.एक. प्रभाषेत प्र+√भाष् व्यक्तायां वाचि-आत्म.वि.लिङ्.प्रपु.एक. किम् किम्-म.सर्व.नपुं.प्र.एक. आसीत √आस् उपवेशने-आत्म.वि.लिङ्.प्रपु.एक. किम् किम्-म.सर्व.नपुं.प्र.एक. व्रजेत √व्रज् गतौ-आत्म.वि.लिङ्.प्रपु.एक.

And this is the big problem. Any one can understand that before I was doing only copy and past. Now I will have to make a wikitable every time. So I have put this wish into https://phabricator.wikimedia.org/T117859 here. But this bug has "Low" Priority. I have seen history of phabricator and bugzilla. There are numbers of bugs which have "Low" priority and they filed before 4 year and 5 year ago. I thing this problem will harm sa.wikipedia and slow sa.wikipedia's speed. Moreover "for one user(?)" this portion signs that it bug will never solved. I personally have 700+ tables to paste in sa.wikipedia. So my wish to solve this bug as soon as possible. We are small community and this is the biggest problem fort of us. This is not for only one user but all sa.wikipedia. We wish to solve it. NehalDaveND (talk) 07:08, 11 November 2015 (UTC)

• Obvious  Endorsed. Sbgujarat (talk) 07:18, 11 November 2015 (UTC)
• Obvious  Endorsed. RAMKRISHNA RAVAL (talk) 07:20, 11 November 2015 (UTC)
• Obvious  Endorsed. Jshastri2000 (talk) 07:21, 11 November 2015 (UTC)
• Obvious  Endorsed. Sshihora (talk) 07:24, 11 November 2015 (UTC)
• Obvious  Endorsed. Yograj (talk) 07:25, 11 November 2015 (UTC)
• More information is necessary to reproduce this. As far as I know there haven't been any copy/paste changes in the past few weeks. Cscott (talk) 19:40, 11 November 2015 (UTC)

Add Citoid support to RefToolbar

Tracked in Phabricator:
Task T114156

RefToolbar is a default gadget on the English Wikipedia. It adds a "cite" button to the WikiText editing toolbar for quick and easy addition of commonly used citation templates. It is probably the most common way that citations are added into Wikipedia. It also has an auto-fill feature that lets you create a full citation by just entering the ISBN, DOI, or PMID number. There is a new Citoid service that is being developed for the VisualEditor that will allow the same auto-fill capability based on raw URLs. Since Citoid is an API service, there is no reason it can't be added to the WikiText editor as well through RefToolbar.

Adding Citoid support to the wikitext editor is already planned. Whatamidoing (WMF) (talk) 00:18, 12 May 2015 (UTC)

@Whatamidoing (WMF): Do you know what team is going to be working on that? Collaboration? Kaldari (talk) 17:23, 12 May 2015 (UTC)

I believe it's the VisualEditor team, per mw:Editing#VisualEditor team and phab:T94223. Quiddity (WMF) (talk) 17:33, 12 May 2015 (UTC)

Looks like the bug is currently unclaimed, but is being considered as a possible GSOC project for August. Specifically, the bug is about adding Citoid + TemplateData support to WikiEditor (unclear if this would include a citation template editing interface), which sounds like a larger project. My idea above is a quick hack just to add a Citoid lookup to the existing URL field in RefToolbar. RefToolbar already does API look-ups and has mappings for all the en.wiki citation templates, so this would be a smaller, short-term project. Kaldari (talk) 18:44, 12 May 2015 (UTC)

Pre-re-organization, it was definitely the Editing team, whose main project was VisualEditor, but whose scope also included the wikitext editor and Cite.php.

If you just want a quick hack, then User:Salix alba had one a while ago (I don't know its status). Whatamidoing (WMF) (talk) 17:58, 14 May 2015 (UTC)

You can find it at en:User:Salix alba/Citoid. I updated a few days ago. The data produced by citoid has been known to change format which can sometimes break the gadget. I'm trying to keep it upto date.--Salix alba (talk) 15:44, 7 June 2015 (UTC)

The VisualEditor team is definitely planning on doing this as part of the modern wikitext editor project. However, it's not being actively worked on yet and probably won't be for another quarter or two. I leave it up to the Community Tech team whether to include it in their survey, but I don't think they want to take on things that other teams have fairly concrete plans to do :)—Neil P. Quinn-WMF (talk) 20:16, 11 November 2015 (UTC)

Just to clarify, the project is to build a new wikitext editor with all these features (to avoid suddenly breaking users' workflows and gadgets). This wouldn't help people who strongly want to stick with the existing editor.—Neil P. Quinn-WMF (talk) 20:40, 11 November 2015 (UTC)

You can now switch from WikiEditor to VisualEditor mid-edit so Citoid is only a click away if you are using WikiEditor. ESanders (WMF) (talk) 17:58, 12 November 2015 (UTC)

Automatic non-breaking spaces

The functionality for automatic non-breaking spaces should be improved. As far as I know, this already exists for "%" and "« »", but there are other places where it would be needed, such as "§". Also, VisualEditor does not support non-breaking spaces yet. Thanks, --Gnom (talk) 10:04, 12 November 2015 (UTC)

My understanding is that spaces before most punctuation marks are automatically converted into non-breaking spaces. § isn't really used as punctuation though (at least not in English), but to designate a section or paragraph in a work. I'm assuming that you would want the space after the § to be converted into a non-breaking space, correct? Are there any other specific examples of cases that would benefit from automatic conversion? Ryan Kaldari (WMF) (talk) 18:01, 12 November 2015 (UTC)

Please take a look at the use of "§" and "& nbsp;" in §_175, a law-related featured article on German Wikipedia. It currently contains 249(!) instances of "& nbsp;". I don't think I can come up with any good English examples, but maybe "Mr._Smith" is one. Thanks, --Gnom (talk) 21:26, 12 November 2015 (UTC)

• Comment Note that there are different rules which kind of space     and so on should be used. See (de) Anwendungsbeispiele or (en) Width variation. I'm not sure: is it better to put   by default or nothing? -- Juetho (talk) 14:21, 18 November 2015 (UTC)

Make it easier to cite different pages from a book as one reference

When I cite different pages from a book within an article, I have to cite the book separately multiple times. We have a "reuse citation" functionality that also works very well in VisualEditor but not for different pages from the same book. See Phabricator tasks T100645 and T15127. Thanks, --Gnom (talk) 10:07, 12 November 2015 (UTC)

• Comment I think the English Wikipedia already does this with en:Template:Rp. Davidwr/talk 05:54, 16 November 2015 (UTC)

•  Endorsed I don't recall ever seeing this template used (although I'm sure I could find out how many transclusions there are), but I think most editors are unaware of it, and usage seems more complicated than should be necessary. The ability to name a reference, and then within the subsequent citations, to simply add "page=27" or whatnot would simplify this and help reduce reference clutter on articles that cite multiple pages from the same source. Etamni (talk) 06:14, 17 November 2015 (UTC)

•  Endorsed I've used en:Template:Rp, and I agree that it would be simpler to be able to write <ref name=blah page=42/>. And simplicity equals adoption. Swpb (talk) 19:47, 17 November 2015 (UTC)

Merge the content translation and the visual editor to one tool

The concept of the content translation is very good. The largest editions of wikipedia (especially the english) are main source for articles in other languages. But in the current form of the Content Translation, you can only translate an article, but cannot add information from other sources, add local tamplates, or even change/add media files, until you publish the article. My suggestion is to merge the content translation and the visual editor into one tool, in which translating would be an option. בנימין (talk) 15:16, 10 November 2015 (UTC)

 Endorsed Do you think you could make a quick mock-up of what a unified UI would look like? I'm all for bringing the tools closer together: it would be nice for all wikis to be able to easily look at the article in a related language as they edit, for instance. Cscott (talk) 19:28, 11 November 2015 (UTC)

Nested tag support

Some extensions (e.g. mw:extension:Cite) establish tags (<ref> in this case) which are parsed on a "one-off" assumption. I.e. structures like Primary text<ref>Outer footnote<ref>Inner footnote</ref> continuation of outer footnote</ref> continuation of primary text simply will not currently parse, resulting in the dreaded and rather unfriendly

error. Surely it is past time to address such a fundamental issue? AuFCL (talk) 00:32, 13 November 2015 (UTC)

Just to extend the generality of the above I have also seen users attempt to nest <poem> tags within <poem> tags to similar levels of frustration (at least there is not a big red cryptic error in this instance but it still does not work.) AuFCL (talk) 05:25, 13 November 2015 (UTC)

•  Endorsed. If there are technical reasons for not being able to nest these tags, at least clean up the message and be more specific where the problem is. Etamni (talk) 06:17, 17 November 2015 (UTC)

Generate automatic summary /* blah */ when I manually add a section heading when editing

Tracked in Phabricator:
Task T22307

See the Phabricator request (linked in the right margin). This would be particularly helpful on talk pages. Seems like a relatively easy task. Maybe after sitting on the wishlist for six years someone can be assigned to it. Thanks, Wbm1058 (talk) 14:53, 16 November 2015 (UTC)

•  Endorsed Having the wrong section indicated is worse than having no section indicated at all. Swpb (talk) 19:50, 17 November 2015 (UTC)

Article sweeper / examine list for later checking

Problem

We have no way to do article quality checking, in series.

Benifit

All users / all projects.

Curently addressed

Using hovercards over articles in categories, in Wikipedia (very limited).

Solution

By a tool that navigates an article list (on the left) and previews articles (on the right) using keyboard (left/right changes article, up/down (and mouse) scroll article). The list can be fed in a number of ways, i.e with a category and by selecting the level of deepening inside it.

• An article with a poor lead section or table of contents is often a poor article.
• Using hovercards is not enough and article message templates are not visible.
• Sweeping an article category (+selectable depth) with preview is extreme help for thematic quality checking.
• Scrolling the article preview helps examining the full article.
• Putting articles to a personal examine list by using spacebar toogling (and similar button to watch list 's star click) helps later checking.
• Make simple to directly put article message templates while previewing.

--ManosHacker (talk) 10:01, 16 November 2015 (UTC)

Simple math in tables

It is my understanding that the developers are working very hard on making it easier to create tables in visual editor. We are not quite there yet, and I have seen a recent setback, but we are close to being able to copy and paste an existing table from a spreadsheet directly into an editing window. At present, this allows cell by cell transfer of data, but does not allow one to do traditional spreadsheet functions such as simple math (e.g. sum of entries in a column, ratio of two cells). While full functionality of a spreadsheet is well beyond the scope of what ought to be available in media wiki, I see tremendous value in allowing some simple concepts such as sums and ratios. (I would also like the ability to have hidden columns, which I suspect are technically possible but may be nontrivial. I'll be happy to explain if the need for this isn't obvious).

Editors who do not follow sports closely may be unaware that we have many hundreds if not thousands of articles with tables of historical results for teams coaches and individual players. As an example, see John Thurston.

In a nutshell, the challenge is that, while it is not hard to add a single year to a template, or update the template when the team wins, the subtotals by coach, by conference versus non-conference, aggregate cumulative results and winning percentages are not automatically updated, but have to be edited separately.

The setup creates two problems:

1. Harder than it should be—Updating a single game is not easy — instead of editing one field, the editor may need to edit eight fields. Or maybe six, or maybe four, it depends
2. Errors persist—If any editor ever makes an error, the subtotals and totals will now be wrong, and a subsequent edit which makes all of the right increments will not correct the problem but preserve the error. (Plus, if some editor notes the subtotals are wrong and corrects them, they may have been wrong because some individual entry was wrong and now the subtotals are right but the individual entry is wrong. When the software does not do the totals, the individual entries and the totals can get out of sync)

To illustrate,

• Existing approach when a game is won:

1. Increment season win count
2. If a conference game, increment season win count
3. If winning percentage template in place, increment win count
4. Increment coach win count
5. If a conference game, increment season conference win count for the coach
6. If winning percentage template in place, increment win count for the coach totals
7. Increment all time win count
8. If winning percentage template in place, increment win count for all time totals

• Proposed approach when a game is won:

1. Increment win count in the conference field, if a conference game, or in the non-conference field if non-conference (the software then calculates all subtotals and ratios).

I've presented this in the context of sports tables, but there are many tables within Wikipedia which require occasional updates. In cases where these tables have subtotals and totals the same problems can persist — that the entries in the subtotals get out of sync. Editors should modify individual entries, and let a computer do the math.

I don't know whether this will fall within the types of things considered in scope. If it is in scope, I'll note that my brief discussion above is far short of adequate, and I'll volunteer to write more fully developed use cases and take a stab at specifications.--Sphilbrick (talk) 17:23, 16 November 2015 (UTC)

It may be possible to already do this via Lua Modules. I don't have much experience with writing Lua Modules myself, but maybe someone like Mr. Stradivarius would have a better idea. Ryan Kaldari (WMF) (talk) 03:03, 17 November 2015 (UTC)

What Sphilbrick describes isn't quite possible in Scribunto. For someone to be able to edit certain rows of a table with VisualEditor and have other rows of that table updated by Lua modules, you would need to have one module invocation for each cell that you want updated. To do this, you would need to grab the latest wikitext revision of the page and then attempt to parse it to determine the module output. However, there are two problems with this: a) parsing wikitext reliably is really hard (for those who have never seen it, take a look at Parser.php), and b) the module output won't be updated on page preview, as it only uses the latest saved revision of the page. To do this properly in Lua you would need to replace the entire table with a template invocation. However, then you wouldn't be able to edit it with VisualEditor (at least not directly). — Mr. Stradivarius ^{♪ talk ♪} 07:43, 17 November 2015 (UTC)

@Sphilbrick:. "we are close to being able to copy and paste an existing table from a spreadsheet directly into an editing window." Can you link to any info on this? I wrote up a roundabout way to do this: Commons:Convert tables and charts to wiki code or image files. See section titled "Web to LibreOffice Calc to tab2wiki". I guess you can do something similar to solve some of the simple math stuff you are trying to do. Paste the wiki table into LibreOffice Calc, or into a tool at the Wikimedia Tool Labs. Then do the math there. Get the new table back in wikitext format directly, or by pasting the revised Calc spreadsheet into tab2wiki. --Timeshifter (talk) 14:31, 17 November 2015 (UTC)

•  Endorsed obvious need. Etamni (talk) 06:21, 17 November 2015 (UTC)
•  Endorsed Might have to use an intermediate tool at Wikimedia Tool Labs. --Timeshifter (talk) 14:35, 17 November 2015 (UTC)

Table editing

Many people want row numbering, drag and drop rows and columns, etc.. There are various Phabricator threads, but no overall plan. --Timeshifter (talk) 00:17, 17 November 2015 (UTC)

Improved editor

• Provide an editor that provides concurrent wikitext / WYSIWYG views. (Obviously there would be some unspecified view for construct in progress. e.g. If the user opens [[ to start a wikilink we wouldn't want to render that as an error.
• Auto-completion similar to what the Eclipse IDE provides for writing Java. For example, user starts a template {{web cite| ... provide dropdown /autocomplete with available parameters.
• Ability to provide url to commonly used sources and parse out common references field. e.g page title, author, date. NE Ent (talk) 01:27, 17 November 2015 (UTC)

Page contributors

Before the switch to tool labs (am I using the right jargon?) we had a nifty little tool on the English wikipedia that was much superior to what we have now under Top 50 contributors.

By a simple click of a button one could check out ALL editors who ever edited a page sorted 8 different ways. It came in real handy for someone like me who only very occasionally participates on a talkpage, but when they do want to have some background on the potential audience before making a total fool out of themselves.

The tool displayed the list of editors who had participated on the page. There were 4 columns, each of which could be sorted front-to-back and vice verse:

• user ID
• number of edits to the page
• date of first edit
• date of last edit

It was quick and rarely (if ever) failed, while the tool we have now lists only the top 50 editors, cannot be sorted, and is broken a lot.

Thanks for considering this proposal. Ottawahitech (talk) 19:18, 18 November 2015 (UTC)

Increase edit summary and log reason length

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Withdrawn -- this is currently a database operations task. MER-C (talk) 12:01, 11 November 2015 (UTC)

---

Tracked in Phabricator:
Task T6714

Tracked in Phabricator:
Task T6715

Edit summaries are currently limited to 255 bytes. This is a pain for non-English editors, where one UTF-8 character consumes at least two bytes. MER-C (talk) 06:29, 3 July 2015 (UTC)

For what is worth: phab:T102611.--Qgil-WMF (talk) 11:17, 3 July 2015 (UTC)

---

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Moderation/admin tools

Improve MediaWiki's blocking tools

Our blocking tools suck. It is a trivial matter to defeat blocks, and any vandal worth his salt can do it in his sleep. (User:Philippe). Anyone who works a sockpuppet investigation page or is a victim of repeated on-wiki harassment can attest to this. Block evasion doesn't have to be deliberate -- in some parts of the world, users can be assigned a different IP address by their ISP for every edit they make. We effectively have no measures against these users.

The aim here is threefold -- to make it more difficult to evade blocks, make it easier for us to identify and deal with potential sockpuppets as soon as possible-- ideally before they start editing -- and keep collateral damage at a minimum. This proposal has multiple facets:

• Look at other forum/blog/wiki software (e.g. Wordpress, vBulletin) and determine which blocking tools can be feasibly integrated into MediaWiki (not as an extension) subject to the constraints in our privacy policy. Implement them.
• Implement the existing tickets:

• Sets a blocked user cookie
• Block by user agent only, don't block the underlying IP
• Throttle account creation by user agent
• When the account creation throttle is hit, flag all accounts that were created by that user (limit to Checkuser if necessary)
• Recursive checkuser
• Checkuser watchlist feature

• Block by device ID (needs check with WMF Legal first)
• Any other suggestions from the community that will help tackle this problem.

Improved blocking tools may be assigned to the Checkuser group initially to get a feel for how much collateral damage they cause. This will ideally reduce the burden of cleaning up after spammers, vandals and long term abusers, reduce the amount of on-wiki harassment of the type referred to in the diff above and will benefit all good faith editors of any MediaWiki installation. MER-C (talk) 12:06, 8 November 2015 (UTC)

•  Endorsed I've always wondered why blocking didn't set a cookie. ONUnicorn (talk) 14:02, 8 November 2015 (UTC)
•  Endorsed Oh yeah...expedite and roll out to remaining admins after brief trial with Checkusers.
  ⋙–Berean–Hunter—► ((⊕)) 23:51, 9 November 2015 (UTC)
•  Endorsed Recommend to eliminate need for check user. If 2 sock puppet or more is block within same week from a same IP, the IP is block for 1 week without the need to checkuser. Genuine contributor can always register from the same IP address. Yosri (talk) 02:26, 10 November 2015 (UTC)
•  Endorsed --Yann (talk) 16:06, 10 November 2015 (UTC)
•  Endorsed Amir (talk) 10:06, 11 November 2015 (UTC)
•  Endorsed Finer-grained block tools are desperately needed on many projects. UA blocking is something I've been wishing especially hard for. Fluffernutter (talk) 17:21, 11 November 2015 (UTC)
•  Oppose. fewer tools; more leadership. it is unclear that more tools will decrease vandalism / socking and no study of unintended consequences. Slowking4 (talk) 00:11, 13 November 2015 (UTC)
•  Endorsed This won't stop the expert evaders but it will make it easier to stop the majority, freeing up people to do other things. Davidwr/talk 05:24, 16 November 2015 (UTC)
•  Endorsed Better tools to improve the anonymous grief folks can impose on positive volunteers is a must. Ckoerner (talk) 20:53, 16 November 2015 (UTC)
•  Endorsed Swpb (talk) 19:54, 17 November 2015 (UTC)
•  Endorsed This discussion [[8]] suggests this is a serious problem and a malicious individual with fairly basic hacking skills could seriously disrupt Wikipedia unless there are better tools for automatic detection and blocking of IP-hopping vandals. Msubotin (talk) 20:40, 18 November 2015 (UTC)
•  Endorsed As a former admin on fawiki who has had to deal with many trolls, I think improvement in MediaWiki's blocking system is vitally important to reduce the amount of work needed to deal with some vandals and with harassment in general. Dalba 08:28, 19 November 2015 (UTC)

Suggesting AbuseFilter by machine learning

Recently we should manually write down Extension:AbuseFilter's pattern (string match, regex, etc). It is a very hard for non-technical user (just a admin of a wiki) and consumes technical user's time.

I propose a machine suggestion for AbuseFiliter's pattern to reduce such difficulties and cost. For example, when I put marks on some revisions or users, I can get the suggested pattern generated by machine learning which extracts points in common among the specified revisions or user's contributions.

I don't have any concrete methods or implementations because I'm specialized in neither the machine learning or natural language processing. But I heard it's not impossible.--aokomoriuta (talk) 23:56, 9 November 2015 (UTC)

 Endorsed See also Research:Revision scoring as a service and Objective Revision Evaluation Service. Helder 11:30, 10 November 2015 (UTC)

 Endorsed -- とある白い猫 ^chi? 11:42, 14 November 2015 (UTC)

I hesitate to endorse this. It's interesting to do and I support it, but I'm not sure its feasible. MER-C (talk) 22:06, 18 November 2015 (UTC)

OTRS permissions checker

Tracked in Phabricator:
Task T88620

For a normal user is impossible to know if an OTRS permission is true or false. For example this template suggests to contact an OTRS volunteers. This is a very fragile system. I propose to expose a special page (or anything you want) where you can add a ticket number and get as response a boolean value. The system should also be easily machine readable, in order to have an automatic report of false/wrong/vandalised ticket. --AlessioMela (talk) 10:12, 10 November 2015 (UTC)

 Endorsed it could be very useful when there is no OTRS volunteers available. Restu²⁰ 10:16, 10 November 2015 (UTC)

 Endorsed even if OTRS volunteers are available it is infeasible to check a large number of tickets. --Incola (talk) 10:32, 10 November 2015 (UTC)

•  Endorsed --Yann (talk) 16:27, 10 November 2015 (UTC)
•  Endorsed provided this was setup to handle queries such as "does OTRS ticket 9999 relate to user:ZZZZ" more detail and you start to breach privacy, less detail and all you know is that this is a valid OTRS ticket though it may be unconnected to the person who is using it. WereSpielChequers (talk) 19:08, 10 November 2015 (UTC)
•  Endorsed Yes some automatic tool to even check if the ticket even exists or if it is valid( any images approved to use it), or what other images use this ticket number, or to check what is ticket number if only "ticketID" or ticket URL is known (like here File:002 Dafna Kaplan Taliya Finkel 5x5.jpg). There is a lot we could check without need to access the actual ticket details. --Jarekt (talk) 19:43, 10 November 2015 (UTC)
•  Endorsed --Shizhao (talk) 02:26, 11 November 2015 (UTC)
•  Endorsed - certainly useful to lessen OTRS workload, and give non-OTRS members a direct access to some basic non-private status information. Such a feature should give at least some basic status info like "ticket does not exist", "ticket request received", "ticket is still in process", "ticket reviewed and OK", "ticket reviewed and rejected". None of these anonymous general infos breaches privacy (imo). GermanJoe (talk) 16:40, 11 November 2015 (UTC)
• Using OTRS for permissions is backwards and a compromise on our overarching goal of growing the free knowledge ecosystem. OTRS must be discouraged more and more in favour of public solutions such as self-marking. See also commons:Commons:OTRS#When contacting OTRS is unnecessary. Either way, all the requests above are plainly impossible with OTRS and would require a new ticket system. Nemo 09:44, 13 November 2015 (UTC)

RFC tools

Tracked in Phabricator:
Task T31923

Perhaps there is a better way to capture ideas from the community for things like this document and RFCs. They tend to be very "Meta-Wiki" community focused outcomes, and become a bit complicated at times for less tech-savvy people (which sometimes may defeat the purpose). Perhaps there are tools that can increase language and cross-wiki participation. There might also be lessons from the IdeaLab project that could be applied.

 Endorsed This is really an area, where I agree we could truly use 'community' tech. Delection discussion/Voting/RFC'ing is a core element of our community workflows, that is sorely unsupported by tools. —TheDJ (talk • contribs) 18:17, 19 May 2015 (UTC)

Work queues

Using the extensive collection of en:WP:TC (cleanup templates) we have in articles, I would like to see each Wikiproject have a dedicated page to show what tasks (and how many) can be done to articles within a WikiProject scope. (I would also like to see such a page for the entirety of each language Wikipedia.) I describe a version of this idea at Grants:IEG/Automated inventory pages for all WikiProjects. My inspiration for this idea is from http://www.wikihow.com/Special:CommunityDashboard Thank you. Biosthmors (talk) 19:56, 19 May 2015 (UTC)

We need work queues. A system, that shows articles that are in a certain group, for a certain reason and that need to be '(pre)processed' in a certain way. The person who can crack the task of solving this in a generic enough and expandable enough way, usable for multiple wiki types, in a way that editors can build new queues themselves, will be my ULTIMATE hero. Inspiration: WikiGrok + NewPagePatrol + WikiHow dashboards, Wikipedia:Huggle and Wikipedia:STiki, etc. I consider this the key to our long term survival. —TheDJ (talk • contribs) 18:29, 19 May 2015 (UTC)

 Endorsed And I saw this comment after I posted mine below about "Inventory pages". Agreed. Biosthmors (talk) 19:57, 19 May 2015 (UTC)

 Endorsed +1 --AS (talk) 16:45, 27 May 2015 (UTC)

The Parsoid team would like something like this as well for wiki linting (finding and correcting wikitext errors or deprecated usage). Cscott (talk) 18:23, 11 November 2015 (UTC)

•  Endorsed--Shizhao (talk) 08:04, 12 November 2015 (UTC)
•  Endorsed Helder 12:02, 12 November 2015 (UTC)

Enhanced per-user, per-article protection / blocking

Tracked in Phabricator:
Task T2674

There are currently two mechanisms to stop a user editing an article on Wikipedia - protect the article so nobody can edit it, or block the user so they can't edit anything. That's it.

I really feel quite strongly that we need something in between those two extremes - the ability to protect or block a specific user from a specific article. It would allow topic bans to be enforced technically, and prevent editors from going towards a specific area of disruption while still accomodating them as much as possible elsewhere. We need editors, and sometimes we just have to take what editors we're given, and manage the disruptive elements.

Take a look at ANI on the English Wikipedia or read any discussions that involve a block and see how much drama that is - anything that can reduce that is welcome in my view. I've hacked a local installation of MediaWiki I maintain to allow "automatic G7" ie: any user (not just admins) can delete any page that they created, so I'm sure it's technically doable. Ritchie333 (talk) 13:02, 29 May 2015 (UTC)

Occasionally one both needs to both protect the article and than continually block new socks as they are created :-) It is to easy to get around this. You just keep creating socks. Getting them auto confirmed and editing around the semi protection. We have a few people who do this. Not sure what the solution is. Doc James (talk · contribs · email) 13:20, 29 May 2015 (UTC)

 Endorsed +1. We are currently using AbuseFilter for personal restrictions, but native solution would be better --AS (talk) 13:50, 9 June 2015 (UTC)

•  Endorsed This would be a useful tool in the administrator's arsenal, and be fairer to involved participants who want to edit other pages and uninvolved ones who want to edit the page in dispute. Fluffernutter (talk) 17:15, 11 November 2015 (UTC)
•  Endorsed This would give a much less bitey way to deal with edit warrers WereSpielChequers (talk) 21:20, 11 November 2015 (UTC)
•  Endorsed--Shizhao (talk) 07:55, 12 November 2015 (UTC)
•  Endorsed - This should definitely be coded. Whether it is turned on for a given Wiki should be a local decision. Davidwr/talk 05:56, 16 November 2015 (UTC)
•  Endorsed Yes, this is long overdue... IJBall (talk) 03:36, 17 November 2015 (UTC)
•  Endorsed 4nn1l2 (talk) 23:51, 18 November 2015 (UTC)

Paragraph blaming tool

Sometimes vandals insert a piece non-sensical information in the middle of a big article which stays covert for years. This is specially true in the Portuguese Wikipedia, which doesn't have enough task force for a immediate vandalism response. It would be great if there was a tool to "blame" a paragraph, like there is in GitHub. I mean, a tool that, given a paragraph (or a set of paragraphs), points out the last edition (or, perhaps, all the editions) in which this paragraph showed up in the differential. Sometimes it wouldn't work due to merges and displacements, but probably would for the 99%. --Usien6 (talk) 03:06, 11 November 2015 (UTC)

• We have the same problem in English. Currently some edits are looked at by dozens of people and others are looked at by none. The solution is to introduce flagged revisions such as they have on DE wiki, that way you know which are the unchecked edits by newbies, volunteer time is wasted less and every newbie edit is looked at at least once. WereSpielChequers (talk) 06:58, 11 November 2015 (UTC)
  • Dear @WereSpielChequers: Actually the Portuguese Wikipedia does implement revision flagging, but it doesn't seem to be 100% effective... --Usien6 (talk) 13:22, 13 November 2015 (UTC)
    • No system is going to be 100%, be glad you have a better system than we have on English. WereSpielChequers (talk) 08:11, 17 November 2015 (UTC)
• At dewiki we have de:Benutzer:Schnark/js/artikel-statistik.js (to be activated on user-level in common.js), which pretty much has this functionality. There are also other tools available, try for instance X!’s Article-Blamer (on Tool Labs) and WikiBlame. —MisterSynergy (talk) 07:15, 11 November 2015 (UTC)
  • Dear @MisterSynergy: I wasn't aware of these two tools, thank you! But, still, it would be nice if it was a native MediaWiki feature. The wikiblame.php tool doesn't seem to work. The artikel-statistik.js works, but have a poor user interface, though, and runs pretty slowly in article with high revision count. --Usien6 (talk) 13:22, 13 November 2015 (UTC)
    • If there is a high revision count to process, then it’s always very difficult to blame particular words or sentences to their authors. I would be surprised if a native Mediawiki extension would be significantly faster than the JS solution artikel-statistik.js. Anyway, I now endorsed your proposal :-) —MisterSynergy (talk) 14:08, 13 November 2015 (UTC)
•  Endorsed Related: phab:T26617 ("Implement diff on sentence level (instead of per paragraph block)"). cscott (talk) 19:33, 11 November 2015 (UTC)
  • Notice where I said "line" I actually meant "paragraph" --Usien6 (talk) 13:22, 13 November 2015 (UTC)
    • Usien6: Do you mean that you'd like to change "Line blaming tool" to "Paragraph blaming tool"? You can feel free to change it, if that's more accurate. -- DannyH (WMF) (talk) 15:30, 16 November 2015 (UTC)
      • @DannyH (WMF): Done ! --Usien6 (talk) 16:02, 17 November 2015 (UTC)
•  Endorsed —MisterSynergy (talk) 14:08, 13 November 2015 (UTC)
•  Endorsed --Pine^✉ 05:17, 16 November 2015 (UTC)

Special:NewPagesFeed in every language

Tracked in Phabricator:
Task T50552

Hello. I wish the following page Special:NewPagesFeed in the english Wikipedia to be available in all wikipedias in every language (and especially in my language, the french language). It is a very useful page for every contributor and for the reviewing of new articles. Thank you ! --Consulnico (talk) 14:25, 10 November 2015 (UTC)

 Endorsed בנימין (talk) 15:04, 10 November 2015 (UTC)

To enable page curation, this should be fixed. --Edgars2007 (talk) 16:20, 10 November 2015 (UTC)

 Endorsed --Superjuju10 ^{[Aubline available to you]}, 22:24, 10 November 2015 (UTC)

 Endorsed Thibaut120094 (talk) 23:29, 10 November 2015 (UTC)

 Endorsed--Shizhao (talk) 02:29, 11 November 2015 (UTC)

 Endorsed Amir (talk) 10:12, 11 November 2015 (UTC)

Flag SPA and new user accounts

I think it would be useful if Single Purpose Accounts and new user edits were flagged somehow in page histories and reports such as Recent Changes. These are often sources of problematic edits, so it would help in identifying such edits. Additionally this information is useful in deciding how to respond to problems and it would thus save having to check user contributions. Would have to decide how to define such accounts. Maybe a SPA is one with more than 80% or mainspace edits on one page, and new users are those with less than 20 mainspace edits, but maybe there are stats available that might give a better understanding of how to set this criteria. Derek Andrews (talk) 00:08, 9 November 2015 (UTC)

As regards new users, I believe this can be done by setting edit filters to tag edits by users with few edits. No comment with regard to SPAs. BethNaught (talk) 18:21, 9 November 2015 (UTC)

 Oppose adding a scarlet letter so that people assume bad faith is a terrible idea. Beeblebrox (talk) 00:36, 10 November 2015 (UTC)

 Oppose they're already filter tagging new edits this way, but where is the new editor curation and coaching? fixing problems is a particularly bad idea, try system improvement. Slowking4 (talk) 04:03, 14 November 2015 (UTC)

Comment I am sensitive to the "scarlet letter" issue. Perhaps a better idea would be to have proven-sock account's edits made after a certain date [e.g. the date the original puppetmaster was blocked] retroactively tagged. Retractive tag changes would likely require a change to the MediaWiki software. Davidwr/talk 06:02, 16 November 2015 (UTC)

 Oppose Not all SPA accounts are bad, nor are all -- or even a majority -- of new user accounts problematic. In my opinion, it is better to miss one sock puppet than to falsely accuse a new user of sock puppetry. Likewise, it is better to miss a problematic edit than bite a potentially productive future editor by failing to assume good faith. Etamni (talk) 06:42, 17 November 2015 (UTC)

Improve date range searches on Special:Contributions

There is no good way to search a window of time in Special:Contributions. Currently, you can set a date but then you get from that date AND ALL earlier contribs which can be too many to sift through. It would be good to refine the date searches from Point A in time to Point B in time. As an example, we should be able to search the last three months and ONLY the last three months. Every editor and admin that hunts socks, spammers, paid editors, long term abusers, etc. would benefit from this as it allows them to refine their searches for relevance. At the present, very few editors are manipulating the search strings in the URLs to force time windows but it is very cumbersome. You add a string that matches this pattern: " ?ucstart=yyyymmddhhmmss&ucend=yyyymmddhhmmss " Please see this example of URL string manipulation and the tail end of this thread to see that folks have been looking for this. Please modify the queries and front end of this interface to have start and end dates so that we may search time windows.
⋙–Berean–Hunter—► ((⊕)) 23:26, 9 November 2015 (UTC)

 Endorsed This would be nice. This, that and the other (talk) 01:06, 10 November 2015 (UTC)

 Endorsed This would be very useful at RFA and might even focus people's attention on the recent edits of the candidate rather than dragging in ancient stuff that no longer applies. WereSpielChequers (talk) 19:38, 10 November 2015 (UTC)

 Endorsed. This is an annoyance with core software that can be easily addressed. MER-C (talk) 21:52, 10 November 2015 (UTC)

 Endorsed Fluffernutter (talk) 17:24, 11 November 2015 (UTC)

 Endorsed Heck, yeah! In addition, they need to change the search functionality on Special:Contributions so you can at least search BY DAY (if not by hour!) and not "by month" (which is ridiculous!) IJBall (talk) 03:40, 17 November 2015 (UTC)

I agree that it is good to have this improved granularity in time range control. I should point out that anyone evaluating IP ranges for blocks would likely be interested in searching through only the last three months to understand the potential for collateral damage. These changes would allow for filtering out all of those edits from previous years.
⋙–Berean–Hunter—► ((⊕)) 16:34, 17 November 2015 (UTC)

Comment These improvements are scalable to all page histories (articles, talk pages, etc.) as they are currently constrained in the same way (example). I hadn't thought of that when I first posted but adding time window searching to those would also be an improvement and anywhere that form of query may be found.
⋙–Berean–Hunter—► ((⊕)) 17:26, 17 November 2015 (UTC)

Better history pages

History pages are a key tool for article maintenance! Some possible improvements:

• More reliable layout; clearer divide between rows, and/or better wraparound behaviour
• Better separation of data from actions. "Data" includes revision links, timestamp, user info, edit summary, tags, et cetera. Actions include rollback, undo, thank, et cetera.
• Fewer mildly-cryptic things that might be confusing to newbies. For example: "cur" and "prev" links aren't self-explanatory as "diff with current revision" and "diff with previous revision", respectively.
• Visual representations of data. For example, graphical links between net-null revisions (usually between a revert edit and the revision to which it reverted). The key idea here is "information on history pages that doesn't require reading words or numbers", so that it's easier to understand a page's history at a glance.

I've played around with some of this already using JavaScript; interested parties can paste importScript("User:Nihiltres/nothingthree.js"); and then nothingthree.customRevs.testRun(); into the console of an English Wikipedia history page to see how my experiments ended up. For example, I make the byte-difference more self-explanatory by changing "(65,176 bytes) (+1,234)" into "+1,234 → 65,176 bytes".

I stopped messing around a) because it was tiring and b) because this is something that should be implemented in MediaWiki proper, rather than reimplementing the whole damn history page in JavaScript. Maybe something the Community Tech team would like to take a run at? {{Nihiltres|talk|edits}} 20:25, 17 July 2015 (UTC)

I've wanted for a long time some visual representation of the history inspired by the lines on the left of e.g. git histories. That would be something very interesting to have. Helder 12:23, 10 November 2015 (UTC)

•  Support for voting. This, that and the other (talk) 08:28, 17 November 2015 (UTC)

IPv6 rangeblocks

In a very short time, it's become clear to me that many admins need help dealing with IPv6 rangeblocks. See this and [this for example. Can the WMF come up with better tools, scripts, or at least more understandable documentation to help out? I looked at the MW docs and there are no practical examples admins can follow. --NeilN (talk) 18:19, 11 June 2015 (UTC)

The closest I could find in Phabricator is T37542 Provide general means to map IP address spaces (IPv4 to IPv6 and back).--Qgil-WMF (talk) 19:21, 11 June 2015 (UTC)

NativeForeigner made a nice little range-block caluculator at http://nativeforeigner.com/calc/ that can deal with both IPv4 and IPv6 addresses, but it's not advertised very well. — Mr. Stradivarius ^{♪ talk ♪} 05:04, 17 July 2015 (UTC)

Shared variables for AbuseFilter

for example, to store regex with bad words, and such variable could be used in many filters --AS (talk) 22:20, 15 June 2015 (UTC)

phab:T57472?--Qgil-WMF (talk) 10:53, 16 June 2015 (UTC)

I'm not sure what global filters are, but I think I mean different thing: be able to declare a variable, which would be available in each filter. --AS (talk) 10:13, 18 June 2015 (UTC)

See also:

• phab:T20067: Decision tree for AbuseFilters
• phab:T68032: AbuseFilter should allow storing regex matches into variables
• phab:T49512: Switch AbuseFilter to using Lua

Helder 13:52, 9 July 2015 (UTC)

 Endorsed MER-C (talk) 10:18, 16 November 2015 (UTC)

Machine learning to identify sockpuppets

Tracked in Phabricator:
Task T107600

Use machine learning and text mining to detect potential sockpuppet accounts. See Sockpuppet evidence from automated writing style analysis. MER-C (talk) 22:31, 18 November 2015 (UTC)

Tools for import

mw:Extension:Duplicator or mw:Extension:Multiplicator would be very useful and much easier that the importupload with xml-files. Kind regards, --Brackenheim (talk) 21:15, 19 November 2015 (UTC)

Multimedia/Files

suggested multimedia for article

A tool similar to FIST, but a one that works well, and integrated. Matanya (talk) 22:45, 19 May 2015 (UTC)

+1. Relatedly, I wrote a tool to suggest images based on other wikis; much less ambitious than FIST, but it seems stable: GLAMify. Ijon (talk) 17:11, 21 May 2015 (UTC)

Improve SVG rendering

What is the problem it would solve?

de:Kraft: Third pic has bug described by task T7792

SVG is an important file format for graphics on Wikipedia and is used in thousands of science articles. And this also the underlying software libRSVG has many problems with rendering SVG even the article about force in german (de:Kraft) is affected.

The issue arises since libRSVG was programmed by the Gnome Project to render scalabe icons for their desktop environment. Graphics that contain text was not a goal and activities around libRSVG are limited to maintenance today. Because of that important features required for usage inside Wikipedia are buggy or missing. Some bug reports and feature requests by our community are undone since nearly ten years. A test of my own showed that fixing an issue often takes only few days (see task T7792).

SVG is important to Wikipedia but without our intervention the underlying software stays error prone.

Another big example...

File:GTAW broken.svg: Buggy since ten years!!!

The file on the right is used by en:Gas tungsten arc welding and in many more languages and even translated. It provoked bug described by task T97758. Due to its long endurance on Wikipidia it has been shown to our readers many million times. (A workaround has been applied to render it correctly recently.)

Further...

To get an overview about the importance of a file format some statistic is useful. Based on database dump dewiki-20150302-pages-articles.xml.bz2 of german language Wikipedia the following estimation can be done. (Only short evaluation about systematic errors has been done.)

• SVG: 56k
• PNG: 92k (similar scope as SVG)
• JPG: 1104k (mostly pictures)
• GIF: 10k (similar scope as SVG)

Results have been gained with Linux tool en:grep. To change to another file format adapt the following command line call.

date && grep -o -E "(gif|GIF)\|(thumb|mini)" ./dewiki-latest-pages-articles.xml | wc -w && date

(Only counts images that are embedded as thumb preview and not e. g. all the small flags in sport statistics.)

Which users would benefit?

Everybody who is researching scientific or technical information on Wikipedia of any language will benefit. SVG is the preferred file format for high quality science graphics.

It will increase participation because less errors in SVG rendering removes pitfalls for authors without experience in the limitations of libRSVG. As consequence less distraction is created and new authors keep contributing.

This also increases quality because less errors in SVG renderer switches focus from workarounds to content. SVG simplifies re-usage and translation of content and high quality graphics can be share across languages. Thus improving and promoting SVG pushes quality.

How is this problem being handled now?

The SVG renderer libRSVG is part of the Gnome Project. Although it is not in the focus of the Gnome community. The Maintainer of libRSVG is Federico Mena Quintero. He maintains libRSVG in his spare time.

And some examples...
The following discussion has been closed. Please do not modify it.
Bug task T65703 patch needs update task T7792 patch needs update task T65236 Patch needs review task T55899 Patch needs review task T43426 Bad File:Fluoxetine 2.svg TODO Empty sheet Good With workaround Rendered with Inkscape Rendered with Inkscape TODO With workaround With workaround

What are the proposed solutions?

Fix around eight to ten bugs that are especially important for usage of SVG on Wikipedia. Fixing only a few simple bugs would reduce the pain greatly. I expect this to require four weeks of work for fixing bugs, test them and manage software release.

-- Menner (talk) 20:04, 9 November 2015 (UTC) I'll support selecting bugs, mastering libRSVG code and software release, too.

Opinions

•  Endorsed Now almost every SVG is rendered with bugs. --Ilya (talk) 23:32, 9 November 2015 (UTC)
•  Endorsed --Yann (talk) 16:16, 10 November 2015 (UTC)
•  Endorsed It's outrageous that this has languished so long. SVG is supposed to be our gold standard for image quality, adaptability, and reuse. Yet we cripple our own implementation of it. Some of these bugs have been highlighted for getting on for ten years, and nobody has lifted a finger. Jheald (talk) 00:32, 11 November 2015 (UTC)
•  Endorsed again ↔ User: Perhelion 22:27, 11 November 2015 (UTC)
•  Endorsed --El Grafo (talk) 12:19, 16 November 2015 (UTC)
•  Endorsed Masur (talk) 10:06, 19 November 2015 (UTC)
•  Endorsed Dalba 10:18, 19 November 2015 (UTC)

Discussion

• What are the GNOME Bugzilla tickets for the problems you want fixed e.g. [9][10][11]? It shouldn't take too long to update the patches and turn them into pull requests to the Github repository.
• @Ryan Kaldari (WMF): What version of librsvg is used by Wikimedia? MER-C (talk) 20:29, 9 November 2015 (UTC)

@MER-C:I haven't completed with my wishlist yet. Here is a list of bugs. Half of them is not a libRSVG problem some are corner cases. Most of the bug reports contain a link to a Gnome Bugs.

Yes it shouldn't take long to update patches. Creating patches also doesn't take long. I've made five easy patches in five days but thoroughly releasing also takes time... and on the long term it is WMFs responsability to maintain libRSVG.

In task T112421 it says libRSVG 2.40.2 is in use. libRSVG 2.40.11 is released currently but I don't know if its still compatibly with Ubuntu 12.10 LTE used by WMF.

--Menner (talk) 21:03, 9 November 2015 (UTC)

Here's a bunch of tickets that will be closed when updating to the latest version. Community Tech can't help with system operations, unfortunately, and I don't think the WMF should be the maintainers of this software. See if you can ask for commit access -- I fear patches submitted by Community Tech will be swallowed by Bugzilla. MER-C (talk) 21:31, 9 November 2015 (UTC)

Federico is quite open to our interests although he's short on time. I haven't talked to him recently and he is difficult to grasp. He accepted two of my patches but then omitted the next three without comment. I don't have enough time to push them currently and I see WMF in the responsebility to go on. -- Menner (talk) 22:00, 9 November 2015 (UTC)

The table with examples is going off the side of the page (at least on my screen). This makes scrolling up and down the page awkward. Is it possible to move that to another page, and link to it? DannyH (WMF) (talk) 22:31, 9 November 2015 (UTC)

@Menner: These are probably not bugs that the Community Tech team could address directly. However, if it is identified as a high priority by the community, we could help investigate the problems and flag them to other teams (or outside developers). As MER-C mentioned, the Ops team is responsible for our SVG rendering on the production wikis, but maybe there are some solutions that haven't been considered yet. For example, perhaps the WMF could hire a contractor from the GNOME community to work on librsvg for Ops. (Also, I'm afraid you can't endorse your own proposal. Sorry if that's confusing.) Ryan Kaldari (WMF) (talk) 22:36, 9 November 2015 (UTC)

@Ryan Kaldari (WMF): Sorry, I have little time this week. I won't reply until saturday. Just for short I'm aware of your annotations and I'll explain later. -- Menner (talk) 07:33, 10 November 2015 (UTC)

@MER-C: GNOME does not accept pull requests via GitHub, as far as I know patches go into GNOME Bugzilla. --Malyacko (talk) 16:07, 10 November 2015 (UTC)

@Ryan Kaldari (WMF): How exactly the Tech Team will address this problem will be arbitrated after the vote. I'm a developer and already created some patches for libRSVG. The most important thing by the Tech Team would be to manage the existing patches being applied. I've already tried to fix some issues. This had limited success since two busy spare time developers living each on the other side of the earth won't team well.

Further I expect the vote to be a signal for WMF to keep an eye on libRSVG and feedback and reason for me to keep on.

-- Menner (talk) 18:59, 13 November 2015 (UTC)

@Menner: Sure, we would be happy to help however we can. Pushing on existing patches is certainly doable, and perhaps something we could help with regardless of the vote. Ryan Kaldari (WMF) (talk) 05:49, 17 November 2015 (UTC)

Use of pictures in wikipedia

Sorry, my english is very poor, so I write in german:

Jeder Uploader von Bildern kann über die Dateiliste seine hochgeladenen Bilder ansehen. Bei jedem einzelnen Bild ist die Verwendung in den einzelnen Sprachversionen angegeben.

Im Laufe der Jahre habe ich viel über Bildbearbeitung gelernt und kann meine Bilder entsprechend verbessern. Es ist sehr zeitaufwändig, deshalb wünsche ich mir eine Erweiterung der Dateiliste um eingebunden (nur einen Hinweis, nicht wo das Foto eingebunden ist).

Gruss --Nightflyer (talk) 22:50, 9 November 2015 (UTC)

Translation: Uploaders of pictures can examine their uploads using Special:Listfiles. On each of the file description pages, its inclusion is recorded for each of the individual projects. During many years, I've learned a lot about image editing, allowing me to improve my pictures. This is quite time consuming, hence I would like to have an extension of Special:Listfiles that marks included images (just a hint, not the complete list where the photograph is used). --AFBorchert (talk) 07:29, 10 November 2015 (UTC)

•  Endorsed As far as Google Translate said, he is talking about providing of number of imagelinks for each uploaded image. Sounds pretty easy and quite useful. --Edgars2007 (talk) 05:23, 10 November 2015 (UTC)
•  Endorsed Sounds reasonable. But do you know about GLAMorous, i.e. did you try this? --AFBorchert (talk) 07:29, 10 November 2015 (UTC)
  • Thanks AFBorchert for the link :) --Edgars2007 (talk) 07:56, 10 November 2015 (UTC)

Enhance image uploading process

What is the problem you want to solve?

• Normal way of uploading files using Special:Upload lacks of machine-readable metadata field. (i.e. Template:Information must be manually added and most of user are unaware of this template)
• Users are confused on choosing the licenses and hence numerous images are wrongly licensed (e.g. fairuse image tagged as GFDL). This is mostly due to the confusing and text-heavy UI when choosing the licenses.

Which users would benefit? (editors, admins, Commons users, Wikipedia users, etc.)

Those who care about having correct machine-readable metadata in the images.

How is this problem being handled now?

• Many wikis have their file uploading feature disabled and were redirected to Commons instead.

  But similar to the case on local wikis, by redirecting uploading process to Commons, I observed that the users still upload fair-use image to Commons since they are not aware about file licensing stuffs and their purpose is merely to upload image, i.e. they will choose whatever license options available to enable them upload their image for usage in the article.

• In en.wiki, "FileUploadWizard" has been created to insert Template:Information to the image and hence there are machine-readable metadata.

  But to the other wikis where JS developers are lacking, nothing can be done since the localization has been hard-coded in the JS codes. Moreover, the UI has not improved since it is heavily text-based (and as a result, looks like a Terms & Conditions page)

• I'm not aware about other wikis, but in id.wiki, localization effort of "FileUploadWizard" has been started but stalled due to the large effort needed in improving the UI.

What are the proposed solutions? (if there are any ideas)

• Enable commons:Special:UploadWizard in local wikis, enhancing its features to adapt with local wiki rules, including the fair-use licenses.

  Indonesian Wikipedia community has proposed this, but nothing has been done yet since this Phabricator task was not supported by the developers there.

Kenrick95 (talk) 11:47, 10 November 2015 (UTC)

 EndorsedYes! Make UploadWizard compatible with local copyright tags.  Ę-oиė  >>>  ™ 14:49, 10 November 2015 (UTC)

In addition to above, there are other issues:

1. UploadWizard on Commons is broken, and needs to be fixed (most urgent task);
2. Easy transfer of images between Wikipedias and Commons, and back (right now one needs to be admin locally to moved a file from Commons);
3. Easier chunked uploads for large files (can be included if #1 above is fixed);

•  Endorsed --Yann (talk) 16:37, 10 November 2015 (UTC)

Automatic numbering of pictures

What is the problem you want to solve?

Sometimes pictures (tabulars, equations, etc.) are not described properly in the text. (=cannot directly be refered to, therefore...)

It is sometimes hard to figure out which picture is meant.

Which users would benefit?

Reader of Wikipedia would benefit, because the picture which is described is named unambiguously.

Editors of Wikipedia will have an easy to use tool to address a certain picture in the text.

How is this problem being addressed now?

Sometimes the pictures are numbered by the editors.

This is inconvenient, when there are a lot of pictures in one article, and more pictures are added somewhere in the middle of the article.

What are the proposed solutions?

Each picture, which should get a number, is marked with a label-tag.

One can now address the picture by addressing to the label-tag.

This is similar to the references numbering in wikipedia and the picture numbering in latex.

--Boehm (talk) 23:39, 9 November 2015 (UTC)

 Endorsed See also phab:T7600. Helder 11:30, 10 November 2015 (UTC)

 Endorsed --Debenben (talk) 22:27, 10 November 2015 (UTC)

This is interesting. phab:T112991 is a 2016 Wikimedia Developer Summit proposal about refreshing our media styling support; this might also fit within that scope. Cscott (talk) 18:52, 11 November 2015 (UTC)

•  Endorsed Would hopefully cut down on the references to images being "to the left" or "on the right", which are useless for mobile and impaired users. All professional documents use numbering; why don't we? Swpb (talk) 20:01, 17 November 2015 (UTC)

New audio player with waveform display

Tracked in Phabricator:
Task T103527

Basically something like this. I think the improvement in usability compared to what we have now is quite obvious, at least for File: pages at Commons. Might be useful as an option in Wikipedia articles as well. --El Grafo (talk) 11:29, 21 September 2015 (UTC)

The Community Tech team is focused on curation and moderation tools for editors. This (interesting) proposal is clearly out of scope for this team. Maybe it is a good candidate for #possible-tech-projects? I have commented in the task.--Qgil-WMF (talk) 11:49, 21 September 2015 (UTC)

Out of scope. MER-C (talk) 16:28, 14 November 2015 (UTC)

MER-C closed this proposal for being out of scope for the Community Tech team. It is, but I think it's still worthwhile to gauge community interest for this idea. It doesn't duplicate or conflict with a product team's current roadmap, so this can stay open. -- DannyH (WMF) (talk) 23:33, 18 November 2015 (UTC)

Improve SVG rendering (2)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Duplicate of #Improve SVG rendering. MER-C (talk) 11:49, 11 November 2015 (UTC)

---

Tracked in Phabricator:
Task T40010

Placeholder. Details see here. --2A02:810D:1740:1554:1464:B61E:AF7D:42D 19:29, 26 May 2015 (UTC)

How often is SVG rendering a problem? Appears there is a work around here [12] Doc James (talk · contribs · email) 11:16, 27 May 2015 (UTC)

This is me working on librsvg. I've fixed five long term bugs in five days. SVG is everytime a problem when I draw a scientific graphic. Detailed analysis isn't done yet. Currently I'm trying to get some important fixes into latest gnome release before next freeze. Anything else would mean years of waiting. -- Menner aka 2A02:810D:1740:1554:D50D:D2D:256C:10D4 17:49, 27 May 2015 (UTC)

See also Re-evaluate librsvg as SVG renderer on Wikimedia wikis.--Qgil-WMF (talk) 08:32, 2 June 2015 (UTC)

 Endorsed +1 It is absolutely annoying, time and resource wasting for everyone is willing to share SVG. Take simply a look on Commons, many SVG have an flooded crappy file-history (and then sometimes unused and dead or replaced by pixel-graphics). ↔ User: Perhelion 13:24, 3 July 2015 (UTC)

---

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

SVG Help Button

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Completed on my own -- Menner (talk) 12:45, 15 November 2015 (UTC)

---

Besides improving SVG rendering it would be useful to have a "SVG Help Button". Like the Media Viewer button it could be placed below SVG files on Commons media meta pages visible only for loged-in users. Because SVG itself as a non-WYSIWYG format has many pitfalls, it is important to give guidance to contributors.

Until end of 2015 I'll make a prototype with an idea of its look and feel based on user scripts.

--Menner (talk) 18:11, 29 June 2015 (UTC)

 Endorsed +1 Absolutely needed and simply to implement!! ↔ User: Perhelion 07:39, 3 July 2015 (UTC)

By copying commons:User:Menner/common.js on can try out how this SVG button might look like --Menner (talk) 12:39, 8 August 2015 (UTC)

---

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Notifications

Echo notifications for anyone "listening" besides the page's creator

I think we should use create the possibility to anyone start "listening" a page through Echo notifications as if this user was the page's creator (I think it is the same as T106991 in Phabricator). And, of course, to "stop it" whenever it wants. José Luiz ^talk 00:04, 10 November 2015 (UTC)

Reminders in notifications

Tracked in Phabricator:
Task T88781

See this one. --Edgars2007 (talk) 07:20, 28 May 2015 (UTC)

From the Phab description: "As a user, I'd like to be able to remind myself of a task, after a configurable period of time." Ryan Kaldari (WMF) (talk) 17:07, 12 November 2015 (UTC)

Echo notifications: mark to read

Sometimes happens that I haven't enough time to reply/process all the alerts I've received. But if I open the notification the alert disappear and over time I could forget the ones left behind. So I propose to add the possibility to mark a notification as not read, in order to left the echo alert lited up. --AlessioMela (talk) 15:31, 17 November 2015 (UTC)

Cross projects notifications

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

This is an excellent idea. In fact, it's one of the Collaboration team's quarterly goals for Oct–Dec 2015, and they're actively working on it. See T114350 for more details. So it doesn't make sense as a project for Community Tech :)—Neil P. Quinn-WMF (talk) 19:59, 11 November 2015 (UTC)

---

Tracked in Phabricator:
Task T67661

Notify me when my name is mentioned or I receive a comment on meta in another project (Tell me on mediawiki that I was mentioned in meta).

 Endorsed +1 --AS (talk) 16:31, 27 May 2015 (UTC)

 Endorsed+1 --Edgars2007 (talk) 07:11, 28 May 2015 (UTC)

 EndorsedI agree we need to get cross project notification running. Doc James (talk · contribs · email) 07:22, 28 May 2015 (UTC)

•  Endorsedcentral talk page notification, similar to xecho this is very useful for stewards and other global users. Matanya (talk) 22:40, 19 May 2015 (UTC)

 Endorsed --Jarekt (talk) 16:56, 11 November 2015 (UTC)

•  Endorsed Yep. Fluffernutter (talk) 17:35, 11 November 2015 (UTC)

---

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Cross-wiki alerts

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Duplicate of Cross projects notifications. MER-C (talk) 11:47, 11 November 2015 (UTC)

---

Alerts are for matters that require urgent attention, like mention in a discussion or proposed deletion of a picture I uploaded. It is sad that I almost always see these alerts when I happen to come back to that particular wiki, where it is usually too late. Syced (talk) 07:30, 11 November 2015 (UTC)

---

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Search

Search editsummaries

I would like to be able to get a list of all edits made with a specific editsummary (but not limited to one specific editor, like this tool). The Quixotic Potato (talk) 06:41, 29 September 2015 (UTC)

 Endorsed This is also something I have wished for, on more than one occasion. IJBall (talk) 03:42, 17 November 2015 (UTC)

Improve Special:LinkSearch

Special:LinkSearch presently provides a rather messy and inflexible interface. It is useful only for finding links to sites that are rarely linked, as the list quickly becomes cluttered. Of the possible improvements, two would greatly increase its usability for editors:

• Allow the search to be easily limited to a single namespace. This would allow editors to focus on links appearing in articles rather than in talk-page discussions, userpages, etc
• Identify whether the link appears in the article body, references, or at the end of the article. By consensus, certain links are not considered to be reliable sources but may be used as external links; generally, external links should not appear inline (except as interwiki links). Nikkimaria (talk) 00:45, 13 November 2015 (UTC)

 Endorsed Please note that the first bulletpoint is a duplicate of my proposal ("Linksearch per namespace") below. The Quixotic Potato (talk) 01:20, 13 November 2015 (UTC)

 Endorsed. Add phab:T35030 (support for protocol relative URLs), phab:T14810 (default to all protocols -- HTTPS spam is becoming more common) and phab:T100807 (speedup) to the things that need to be done. MER-C (talk) 21:23, 13 November 2015 (UTC)

Image searches based on image recognition

This is mainly needed on Wikimedia Commons. But if we had it there it would be useful in many other places.

Image searches based on image recognition is a newish area of technology, I've seen it demonstrated at the British Library, it would have many interesting uses on Wikimedia Commons, not least in categorising new images; but also in enabling our GLAM partners and others to find new similarities amongst art objects and especially archaeological objects uploaded on Commons. Ideally it should work both from an individual image - "find images like this" from a category - these thousand images are examples of what a ship looks like, please find more like them, and from a highlighted area of an image. WereSpielChequers (talk) 21:03, 10 November 2015 (UTC)

•  Endorsed I think I also saw the presentation that WSC is talking about, a year ago by a couple of research students from the visual geometry group at Oxford. In a week, they downloaded a million images from the BL Mechanical Curator set, extracted a 100-element feature vector for each one, and were then able to show off these two demos using convolutional neural networks trained on the fly -- one giving total recall of similar objects from a sample image, without the very narrow limitations of the kind of perceptual hashing we've seen before; the other giving impressive thematic retrieval for arbitrary ask-the-audience themes. Very impressive, and it would be fantastic to have similar indexing, supporting similar tools, running on Commons. Jheald (talk) 23:13, 10 November 2015 (UTC)

Show Reasonator-style manual+automatic descriptions in Wikidata searches

User-provided description fields on Wikidata are often empty, or minimal. Make Wikidata search-page results easier to interpret, as Reasonator does, by including auto-generated descriptions as well as the stored ones -- compare Reasonator search vs usual search for "John Arbuthnot". Jheald (talk) 13:07, 13 November 2015 (UTC)

Provide a means of searching for deleted pages

Tracked in Phabricator:
Task T109561

As an administrator, I want to search the archive table for deleted pages whose title I don't exactly remember, or are similar in nature -- e.g. "Dr. John Smith", "John Anthony Smith" and "John Smith". Bonus: add pagination to Special:Undelete (should be easy). MER-C (talk) 21:33, 13 November 2015 (UTC)

Improve Special:Log

This is a collection of tickets to improve the ability to search for logged actions.

• Implement a namespace filter for the logging table (already available via the API)
• Ability to select log entries for pages staring with "foo"
• Implement non-exact title searching in Special:Log
• Allow Special:Log to be filtered by log_action as well as log_type (e.g. search block log for unblocks only)

MER-C (talk) 21:37, 13 November 2015 (UTC)

Multilingual search

Allow users to search across all languages of a project, e.g. to optionally return results of a search on English Wikipedia across all the Wikipedias. Fences and windows (talk) 12:37, 14 November 2015 (UTC)

•  Endorsed but with care - this will likely not be computationally cheap and wholesale "all-wiki searches" should be discouraged for that reason. However, searching over 2 or 3 languages is both useful and not-too-expensive. Davidwr/talk 06:06, 16 November 2015 (UTC)

Linksearch per namespace

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Duplicate of #Improve Special:LinkSearch. MER-C (talk) 21:25, 13 November 2015 (UTC)

---

The MediaWiki software does offer the ability to search for links only in a specific namespace, but this functionality is disabled on WikiMedia projects, due to efficiency issues. The Quixotic Potato (talk) 01:39, 11 November 2015 (UTC)

---

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Talk pages

Global (cross-wiki) user talk page

Tracked in Phabricator:
Task T88416

As an editor who is active in many Wikimedia projects, I have to oversee a large amount of own user talk pages for new messages, in spite of being only one person behind this account. I have meanwhile lost track of which wikis I have visited and occasionally edited, so I left soft redirects to my home wiki talk page on some of them. It turns out, however, that users from other wikis want to stay in their wiki and just write comments under the soft redirect, with no possibility for me to take notice unless I regularly visit all wikis for new messages (which I do not do).

I therefore propose to have an opt-in possibility to activate a global user talk page on user level, somewhat similar to the global user page on meta. Consider including these features in the global user talk pages:

• Accessible and editable on local wikis, i.e. users do not need to leave their home wiki; workflow for other users should not change of course
• New messages are automatically tagged with the wiki they originate from (e.g. “This message was written on de-wiki“)
• Wikilinks need to be prefixed, if not already done by the author of a comment
• Multi-language functionality: all structural parts of the talk page are shown in the language of the display wiki or according to visiting user settings; babels can be added like: de-N, en-4, $DISPLAY_WIKI_LANGUAGE-0; …
• A global user talk page replaces all local user talk pages, which should go to archives during initial installation of a global user talk page

—MisterSynergy (talk) 06:57, 10 November 2015 (UTC)

•  Endorsed yes, it would be good to have a central user talk page. --Edgars2007 (talk) 08:17, 10 November 2015 (UTC)
• See also T88416. Helder 11:30, 10 November 2015 (UTC)

  Thanks for the phab. But what does it mean? Do we need more support to get that running, or is WMF not going to support it at all? Do you know of other occasions where this idea has been discussed? —MisterSynergy (talk) 17:41, 10 November 2015 (UTC)

  I'm sure it was discussed as an ancient idea that should have happened years ago when the strategy wiki was run in 2009. No idea why the developers keep blocking it and instead wasting resource on counterproductive vanity projects such as AFT, mediaviewer etc etc. WereSpielChequers (talk) 19:55, 10 November 2015 (UTC)

•  Endorsed --Yann (talk) 16:26, 10 November 2015 (UTC)
•  Endorsed When I am trying to notify user that his image is about to get deleted, I use automatic tools to do that, I would like to be able to leave that message on user's home wiki so there is a chance that he/she finds it in time. A global (cross-wiki) user talk page might be just a way for users to specify at which wiki they would like to receive messages. --Jarekt (talk) 19:26, 10 November 2015 (UTC)
•  Endorsed We have a thousand wikis, the wisdom of crowds is undermined by the subdivision of our crowd. We have needed this for a decade. WereSpielChequers (talk) 19:55, 10 November 2015 (UTC)
•  Endorsed--Shizhao (talk) 02:25, 11 November 2015 (UTC)
•  Endorsed Perhaps everything that is somehow user-related should be unified... --Usien6 (talk) 02:46, 11 November 2015 (UTC)
•  Endorsed Amir (talk) 10:12, 11 November 2015 (UTC)
•  Endorsed Usien6 makes a good point: with SUL in place, there's really no reason we should be forcing users to keep userpages, talk pages, watchlists, Echo, etc, localized if they don't want to. We've already implemented global userpages; let's keep the globalization ball rolling! Fluffernutter (talk) 17:27, 11 November 2015 (UTC)
•  Endorsed Currently I have an infobox notice on many projects asking people to comment on my en wiki talk page. Yes, that's a good idea. I'd suggest something with auto-heading, ex. someone leaving me a message on pl wikibooks should have said message copied to en wiki with a header "From pl wikibooks" or such. --Piotrus (talk) 04:27, 12 November 2015 (UTC)
•  Endorsed Yes! --Jfblanc (talk) 08:28, 12 November 2015 (UTC)
•  Endorsed --Gnom (talk) 10:00, 12 November 2015 (UTC)
•  Endorsed --Helichrysum Italicum (talk) 08:08, 13 November 2015 (UTC)

Random question for anyone: The Collaboration team is currently working on cross-wiki notifications, although I don't know what the current ETA is. If we had cross-wiki notifications, would you still be interested in having a cross-wiki user page? -- DannyH (WMF) (talk) 23:20, 17 November 2015 (UTC)

As the original proposer: Yes, I would still be interested since I still don’t see a necessity to own and maintain dozens (70 at the moment) of own talk pages that all serve exactly the same purpose: talk to me. Wikimedia projects have become much more international by the introduction of Wikidata, thus we visit and edit more projects meanwhile than we did years ago, and with SUL we can finally centralize of lot of functionality. However, reliable cross-wiki notification would indeed improve the situation a lot if we didn’t get cross-wiki talk pages. Other opinions are still welcome. —MisterSynergy (talk) 06:44, 18 November 2015 (UTC)

Okay, thanks for your response. I agree this would be really useful. There are several elements for this proposal that require structured discussions -- separating individual discussions from the page, posting the same discussion in multiple places, tagging discussions with the wiki they originate from. This is basically Flow functionality. -- DannyH (WMF) (talk) 21:10, 18 November 2015 (UTC)

I wouldn’t be surprised if this is a rather complicated task to solve, and I don’t expect fast results. If Flow would help to solve this, I would be happy (although “my” de-wiki community actually seems to oppose Flow, unfortunately). —MisterSynergy (talk) 07:24, 19 November 2015 (UTC)

Access talk pages in the mobile interface from main article.

Tracked in Phabricator:
Task T54165

Currently, there is no way to access an article talk page from an article, unless you type the talk page name into the search bar or the article has a wikilink. Perhaps there could be a "talk" button, akin to what we already have on desktop wikis? Chess (talk) 17:29, 25 May 2015 (UTC)

Filed phab:T100343. Simple requests like this can be directly requested on phabricator. --Glaisher (talk) 17:51, 25 May 2015 (UTC)

This is partially intentional left out though. A wikitext editor on mobile is a very confusing and unusable interface unless you are already able to use it... Just encountering it already seems to scare people. I think adding such a button right now would negatively impact the quality of the mobile website. We need to find a better interface first. —TheDJ (talk • contribs) 07:38, 27 May 2015 (UTC)

As an editor, though, I wish the mobile site was a lot better for actually editing. Chess (talk) 23:39, 4 June 2015 (UTC)

Have you tried commenting / editing in Flow pages? It's not that bad already today. While there is not much precedent about writing encyclopedias and books on mobile devices (although even this is changing), by now there is a big load of prior experiences on mobile discussions, as seen in social media and blogs. Promising, at least for lighter discussions.--Qgil-WMF (talk) 08:47, 5 June 2015 (UTC)

Done This is done. Kaldari (talk) 17:55, 7 July 2015 (UTC)

 Endorsed No, it's not. Nemo 08:28, 15 November 2015 (UTC)

Standard way to be able to enable archiving of sections marked closed

It would be good to be able to mark sections 'closed' and for them then to be transferred to an archive.

Yes, I know that on some wikis there are bots set up that may be able to do this automatically; but I am not sure whether that is true on all wikis, or smaller wikis where nobody may be running such a bot. (eg on Wikidata, it would be nice to be able to implement this for d:Wikidata:Classification noticeboard, ideally together with searchable archiving, but I have no idea how to set this up).

Yes, I also know that Flow can sort-of do this; but it would be nice to be able to do this in a conventional wiki talk page environment, with archiving to conventional editable wiki pages, without having to adopt everything else about Flow. Jheald (talk) 13:37, 13 November 2015 (UTC)

Generate automatic summary /* blah */ when I manually add a new section heading when editing

Tracked in Phabricator:
Task T22307

See #Generate automatic summary /* blah */ when I manually add a section heading when editing. Particularly helpful on talk pages. Wbm1058 (talk) 15:04, 16 November 2015 (UTC)

Develop tools to convert Flow and LQT pages to normal talkpages

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

If that hypothetical scenario ever did become true, the proposed tool would be fully-developed. The WMF has a duty and intends to maintain or improve the extension, and that extends through all the standard software life-cycle phases. Quiddity (WMF) (talk) 00:38, 14 November 2015 (UTC)

---

Tracked in Phabricator:
Task T90075

In the not too distant future the Flow project will be abandoned and people will be forced to admit that it failed (just like LQT). When the inevitable happens, we need to have a way to convert the messy and unreadable Flow and LQT pages back to talkpages. The Quixotic Potato (talk) 05:46, 21 July 2015 (UTC)

Subsequent discussion moved to this talk page. Rogol Domedonfors (talk) 06:25, 26 July 2015 (UTC)

---

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Improve talk pages editing

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

As stated in the Survey description, "A proposal that duplicates or conflicts with items on another WMF team's roadmap may be flagged by the Community Tech team, and not included in the voting phase." The Collaboration team is responsible for Flow, and Community Tech isn't going to override their plans. Proposals for disabling Flow will not be included in the voting phase. Concerns about Flow and the Collaboration team's roadmap should go to the Collaboration team; this page is not an appropriate place for discussing them. DannyH (WMF) (talk) 19:30, 15 November 2015 (UTC)

---

Tracked in Phabricator:
Task T90075

I'm not sure how to migrate existing talk page to something like mw:Extension:Flow, but it would be helpful. Current page-like-editing is not user-friendly for newbies :( --AS (talk) 16:51, 27 May 2015 (UTC)

There is already a team of developers working on Flow from what I understand. There is an early version that one can test at the link you give. Doc James (talk · contribs · email) 00:56, 28 May 2015 (UTC)

thanks, now I've noticed roadmap on mw:Flow --AS (talk) 11:05, 28 May 2015 (UTC)

 Oppose Flow is a failed experiment. What we need is tools to convert Flow and LiquidThread pages back to talkpages. The Quixotic Potato (talk) 10:57, 15 November 2015 (UTC)

• Some years ago, the community identified four desirable improvements to talk page editing, all of which can be done in MediaWiki using Wikitext (and hypothetically could be extended also to VE editing). They are:
  • automatic signatures on talk page entries (easily done, we have bots that do it now - Flow automatically appends the username, not the user signature)

Tracked in Phabricator:
Task T21110

• • a button on the editing toolbar to automatically and correctly indent a post in a discussion and automatic outdenting after a certain number of indents (both also fairly easily done - on last looking at Flow, the indentation scheme made most threads almost unreadable)
  • more graceful edit conflict management (significant work on this has already been done - this is the only thing Flow is better at, but that is because it literally creates a new page for each entry)

Tracked in Phabricator:
Task T72163

• • ability to watchlist an individual thread or discussion (this is a challenge for wikitext, but Flow's current solution seems to be that you have to watchlist individual threads on a 'page' in order to see changes to that thread, which essentially deprecates watching entire 'pages')

Tracked in Phabricator:
Task T2738

• It escapes me why we have gone on to create a *third* user interface that new users would need to learn in order to be full participants in their editing communities. (In fairness, VE is optional on most projects.) Even if Flow was fully implemented on all talk pages, users would still need to use wikitext for a large number of workflows such as deletion discussions (where Flow would actually impede the work with its method of data storage), many discussion boards, requests for comment, requests for adminship, and dozens of other places. Adding another user interface adds complexity, it does not make things easier for new users. What it does is marginalize them, because it makes it that much harder to learn how to participate in almost all of the areas where input from community members is important. If it weren't for the fact that VE prevents people from adding signatures (and blocks a few other key wikitext functions), I'd say just go with permitting VE on talk pages. In fact, I think it would be fiscally more efficient to figure out how to add these features to VE dependent on namespace, rather than invest further in Flow. Risker (talk) 22:26, 23 July 2015 (UTC)
  • Agree User:Risker spending time improving our current editing system and allowing VE on talk pages makes a lot of sense. Doc James (talk · contribs · email) 22:33, 23 July 2015 (UTC)
• I think this is one of the points where exposure of the WMF software development roadmap to the community would be useful. Currently the Flow Portal shows the roadmap ending at 2014-15 Q4, ie at the end of last month. (I may say that the paragraph there beginning The roadmap items that appear below are guesses does not exactly fill me with confidence.) Questions have been asked of the ED as to her plans for Flow, but that discussion remains unresolved. It is hard for the community to make sensible proposals for improvements or new features if it is not told what the software base is expected to be, nor what the design criteria are, nor when, if ever, it is to be delivered. Rogol Domedonfors (talk) 10:16, 24 July 2015 (UTC)

• We are still at the stage where some people are unwilling to admit that Flow has failed, just like LiquidThreads before it. The Quixotic Potato (talk) 10:57, 15 November 2015 (UTC)

---

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Templates

Inserting templates in PDF and Books

Tracked in Phabricator:
Task T73808

Since... well, don't know since when, books and PDFs are not rendering information inside templates. As lots of information is inside templates (also happens with tables) all of this is not rendered when you download the file in PDF. -Theklan (talk) 22:18, 9 November 2015 (UTC)

I think that it comes from the templates, some of them contain the "class=noprint" because the local community decided it.

But if you want to generate some books with their recurrent templates (eg: disclaimer), dynamically from its table of content, I recommend you to export my Lua module. JackPotte (talk) 23:11, 9 November 2015 (UTC)

•  Endorsed Taha (talk) 00:18, 10 November 2015 (UTC)

 Endorsed @JackPotte, the problem it's not the "class=noprint", the current pdf engine is especially buggy in rendering table and dont show template containing table (like infobox). On november 2014 a message from Erik Moeller on wikitech ambassors mailing list describe the current status and said that is not a high priority project to fix them.--Moroboshi (talk) 07:30, 10 November 2015 (UTC)

•  Endorsed--Bramfab (talk) 18:05, 11 November 2015 (UTC)

As the author of the PDF backend, I can confirm that the issue is not with templates, it is with tables. We have a large number of very complicated tables in our projects, and it is a non-trivial task to figure out how to lay them out in LaTeX. Basic patch here: https://gerrit.wikimedia.org/r/107587 -- but it would break more pages than it would help at this point. Help wanted, of course! But it would be even better to write an HTML-based PDF backend for mw:OCG and bypass LaTeX altogether. Hopefully we could use phantomjs 2.0 and not lose the nice support for Indic languages that we currently have. Cscott (talk) 18:39, 11 November 2015 (UTC)

A powerful, handy TemplateTiger

Currently, TemplateTiger feeds on dumps and is very unhandy, if you are dealing with high-use templates. Therefore please, oh WMF, please provide a tiger which prowls through templates live and which can be piloted as easy as catscan (when it's available). → «« Man77 »» ^[de] 18:40, 10 November 2015 (UTC)

 Endorsed Having a live version would definitely be useful. Other things that would be useful for maintenance are detection of invalid parameters (I maintain a similar tool that provides this for frwiki, but unfortunately, I don't have resources and time to run it for any other wiki). Orlodrim (talk) 19:04, 10 November 2015 (UTC)

 Endorsed —MisterSynergy (talk) 21:07, 10 November 2015 (UTC)

Central Global Repository for Templates, Lua modules, and Gadgets

Tracked in Phabricator:
Task T41610

Tracked in Phabricator:
Task T1238

Tracked in Phabricator:
Task T91162

We could use a single location where to keep templates, Lua modules, and Gadgets that are used on all the wikipedia projects. Just like images from commons can be used on other projects, code from such site would be visible to all the projects. The current system of 100's of out of sync copies of the same templates or Lua modules occasionally synchronized with the original is very hard to maintain. --Jarekt (talk) 20:06, 10 November 2015 (UTC)

•  Endorsed --Jarekt (talk) 20:06, 10 November 2015 (UTC)
•  Endorsed. See also mw:Extension:Gadgets/Roadmap. Helder 20:53, 10 November 2015 (UTC)
•  Endorsed —MisterSynergy (talk) 21:10, 10 November 2015 (UTC)
•  Endorsed Danmichaelo (talk) 21:25, 10 November 2015 (UTC)
•  Endorsed A best-of-breed centralised Lua toolkit for Wikidata is particularly needed. Jheald (talk) 22:53, 10 November 2015 (UTC)
•  Endorsed--Shizhao (talk) 02:32, 11 November 2015 (UTC)
•  Endorsed Amir (talk) 10:13, 11 November 2015 (UTC)
•  Endorsed Having spent entirely too much time lately shuffling templates, template docs, and modules from one project to another as I tried to use them and discovered they didn't exist locally, I say an emphatic "yes" to this! Fluffernutter (talk) 17:30, 11 November 2015 (UTC)
• I think that phab:T91162 ("Shadow namespaces") is also related, since it proposes a concrete mechanism for implementing a global repository. Cscott (talk) 19:31, 11 November 2015 (UTC)
•  Endorsed It would redeem smaller wiki-projects --Usien6 (talk) 19:47, 13 November

2015 (UTC)

•  Endorsed. --Stegop (talk) 19:58, 13 November 2015 (UTC)
•  Endorsed Very nice idea! --Sampayu (talk) 20:18, 14 November 2015 (UTC)
•  Endorsed While one central "Global Repository" would be valuable, even better is if we can transclude a generic page from any sister-wiki. With the recent development of SUL, the recent development of special translation support, and the current work on cross-wiki notifications, the ability to "locally-write" information for cross-wiki work and have it "locally displayed" on another wiki opens revolutionary opportunities. One of the most immediate Use Cases would be for the WMF to simply post Project announcements (and this Wishlist survey!) on a WMF-local announcement page. The page(s) would be displayed in sections at EnWiki Village Pump elsewhere. Local wikis could then apply the new translation features. This functionality is very valuable to the Community, and it's a huge boon for the plans at WMF_product_development_process. Alsee (talk) 12:13, 15 November 2015 (UTC)
•  Endorsed Some valuable templates are only available in few projects. Having a central repo for templates would make all the projects benefit of all templates. Moreover, this would remove all potential duplicates of code. That said, the migration to a central repo should be done with care (converging similar templates to a unique one, removing all unneeded templates, ...). Bibi6 (talk) 15:53, 15 November 2015 (UTC)
•  Endorsed Please, please, please. With proper code review (ideally, a git bridge with gerrit code-review on top of it and a way to test candidate changesets directly on-wiki) — Arkanosis ^✉ 16:30, 18 November 2015 (UTC)
•  Endorsed 4nn1l2 (talk) 00:09, 19 November 2015 (UTC)
•  Endorsed --Jane023 (talk) 12:55, 19 November 2015 (UTC)

Global templates

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Duplicate of #Central Global Repository for Templates, Lua modules, and Gadgets. MER-C (talk) 13:25, 14 November 2015 (UTC)

---

A lot of effort goes to duplication of templates all along different wikis. It would be ideal if certain / many of them would be available under a Global Template wiki, with multilingual support by Wikidata. --FocalPoint (talk) 21:51, 13 November 2015 (UTC)

---

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

global, shared gadget list users can pick from

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Duplicate of #Central Global Repository for Templates, Lua modules, and Gadgets. MER-C (talk) 11:44, 11 November 2015 (UTC)

---

See also: Requests for comment/Global bits and pieces#Scope, mw:Extension:Gadgets/Roadmap, mw:Gadgets 2.0 and mw:Gadgets 3.0

Tracked in Phabricator:
Task T22153

Tracked in Phabricator:
Task T31272

Yes, I know if you put your gadgets on meta it gets to all wikis, but this is not user friendly and has a lot of RTL issues all over the place. Matanya (talk) 22:46, 19 May 2015 (UTC)

 Endorsed And they need to be live searchable, so there is no reason to restrict on publishing gadgets, because "the preferences section already has 60 of them". —TheDJ (talk • contribs) 06:55, 20 May 2015 (UTC)

We need a whole package of add ons (such as template and gadgets) that Wiki's can opt into and which are supported by the WMF. I love WikEd for example but it is not an option on many Wikis and thus if I want to use it I need to copy the content to En Wiki first. Doc James (talk · contribs · email) 04:08, 22 May 2015 (UTC)

 Endorsed+1 for global, centralized and configurable gadgets! Helder 16:32, 25 May 2015 (UTC)

---

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Watchlists

Watchlist priority options

Many veteran Wikipedians have watchlists that span thousands of articles, completely beyond the ability to effectively manage. If said Wikipedian can't edit for a certain period (say, a week), just going over the changes in the watchlist can take hours and become a chore that editors simply avoid, at the possible expense of missing vandalism and/or edits that they need to see.

There are external tools for creating and organizing watchlists in different ways, but I'd like to see many of those features built-in as part of MediaWiki. One important addition should be a tag for 'high-priority' articles, similar to how GMail has a tag for 'important' e-mail. While having multiple watchlists would support such functionality indirectly, it would be great to be able to see articles marked as 'important' inside the existing watchlist, and be able to filter them like one can now hide/show own edits, hide/show bot edits, etc.

—Ynhockey (talk) 20:49, 7 November 2015 (UTC)

•  Endorsed as this is a collection of rather annoying shortcomings in core MediaWiki. All editors of all MediaWiki installations should benefit from this, so  Oppose if it is implemented as an extension, gadget or any WMF specific means. MER-C (talk) 12:44, 8 November 2015 (UTC)
•  Endorsed :JarrahTree (talk) 00:24, 10 November 2015 (UTC)
•  Endorsed My watchlist has become a useless list with dozens entries each day, after 10 years. I want more customization, colors, etc. --Piotrus (talk) 04:59, 10 November 2015 (UTC)
•  Endorsed Same the above. Along with customization on I/F, I'd like to have a sort function by selected namespaces. Currently we can search in one namespace with an associated one (main + talk etc,), but sometimes we have to search in multiple namespaces, like Project+Project talk+User talk etc. --Aphaia (talk) 05:09, 10 November 2015 (UTC)
•  Endorsed This is indeed a much-needed feature. I've tried to achieve this by extending my CSS configuration. This is, however, quite cumbersome and also tricky as apostrophes and other characters cannot be used in CSS tag names. I would suggest to give users options to colorize watchlist entries, i.e. the operation that adds a page onto a watchlist should have the option to give it a specific color (for a fixed set of colors depending on the overall style). Color assignments should also be possible while viewing the watchlist. --AFBorchert (talk) 06:54, 10 November 2015 (UTC)
•  Endorsed 4nn1l2 (talk) 09:13, 10 November 2015 (UTC)
•  Endorsed--Liridon (talk) 13:56, 10 November 2015 (UTC)
•  Endorsed --Yann (talk) 16:09, 10 November 2015 (UTC)
•  Endorsed I would love to have " watch for a week/month/year" option. I also find current watchlists very hard to manage and had to in the past ask for help when my watchlist grew bigger than tools ability to display. --Jarekt (talk) 19:15, 10 November 2015 (UTC)
•  Endorsed Kropotkine 113 (talk) 21:37, 10 November 2015 (UTC)
•  Endorsed Of course. IJBall (talk) 03:44, 17 November 2015 (UTC)
•  Endorsed I also like the idea submitted by Jarekt (above) that would allow me to add something to my watchlist and optionally specify an expiration, at which point I'll automatically stop watching it (perhaps more useful with talk pages than mainspace articles, but still a useful function). As long as we are discussing the watchlist, it would be nice if there was a way to create a private note about pages on one's own watchlist, such as to-do items or a self-reminder as to why the item is on the watch list in the first place. It would also be useful if a user could specify a section, rather than an entire article, for a watchlist. This might be useful if I place a comment on a particular talk page, and want to be notified if someone replies below my comment, but I'm not concerned about other conversations on the same page. (Probably most useful on drama boards, Jimbo's talk page, project space, etc.)Etamni (talk) 07:22, 17 November 2015 (UTC)
•  Endorsed I want to be able to flag certain items for a month at a time. --Timeshifter (talk) 17:43, 19 November 2015 (UTC)

Add a user watchlist

Tracked in Phabricator:
Task T2470

Allow editors to "watch this user" by adding a tab or link on user (talk) pages, contributions, history, Special:Block and other appropriate places, and a separate user-watchlist special page which lists the latest contributions from users on the list.

• As an admin, I want to be able to check on potentially problematic editors at some time in the future.
• As an experienced user, I want to follow each step of a newbie I'm coaching, to fix their edits, assist in their discussions, provide guidance in general, without having to watchlist all the pages they may edit, so that all my time is spent helping them
• As a wiki trainer with dozens people to follow, I want to have a page where to have an overview of their complete activity, controlled by a "central" list of usernames which I can just edit/past in a single place. I can then act on specific edits/pages/users or just know what's going on overall.

Limit to admins only if necessary to mitigate stalking concerns. I currently use something I hacked up myself, but this really needs to be in core MediaWiki. MER-C (talk) 12:51, 8 November 2015 (UTC)

For simple wiki training groups, there is toollabs:magnustools/herding_sheep.php. Nemo 15:00, 8 November 2015 (UTC)

 Endorsed --V111P (talk) 06:47, 10 November 2015 (UTC)

See w:pt:Special:PrefixIndex/MediaWiki:Gadget-watchUserContribs. Helder 11:30, 10 November 2015 (UTC)

 Endorsed--Liridon (talk) 14:01, 10 November 2015 (UTC)

•  Endorsed --Yann (talk) 16:07, 10 November 2015 (UTC)
•  Endorsed --Fritzmann2002 (talk) 17:30, 10 November 2015 (UTC)
• Editors stalking each other can be quite a problem, and this would make it easier. Would it be possible to limit it to admins and trainers but not allow all users to use this? WereSpielChequers (talk) 19:25, 10 November 2015 (UTC)

• The specification should include a user right to allow access to this special page, which can be given to admins by default with changes past that based on community consensus. This would be no different technically than the ability to delete, block, view Special:Unwatchedpages, etc -- all that is required is a configuration change. MER-C (talk) 21:42, 10 November 2015 (UTC)

•  Endorsed With use limited to admins or those holding a new, associated userright ("watcher"?), if necessary. Fluffernutter (talk) 17:22, 11 November 2015 (UTC)
• Oppose. Doesn't this seem a little stalkerish? Anyone wanting to look at someone's contribs can do that, but it would feel quite creepy to think that, every time one makes an edit, a particular person is alerted. It would make no difference if that person were an admin. Sarah ^talk 21:40, 11 November 2015 (UTC)

• We can also make watchlists public with reasons given for watching and additions and removals logged (like mine is). One would then presume that abuse of the tool would lead to desysopping. MER-C (talk) 12:25, 12 November 2015 (UTC)

•  Endorsed as an admin tool only. This could be very helpful in monitoring problematic users contribs, but it does seem to also have the potential for abuse. Of course, the tool could be developed and projects could decide locally who should have access. Beeblebrox (talk) 01:22, 12 November 2015 (UTC)
•  Endorsed --Gnom (talk) 09:59, 12 November 2015 (UTC)
•  Endorsed It is a bit stalkish. For that reason each project should decide who gets to use this ability or if it is turned on at all. Davidwr/talk 06:10, 16 November 2015 (UTC)
•  Endorsed If "watching" good editors or good admins, or "bad actors" (esp. IP vandals), makes one "stalkerish", so be it... IJBall (talk) 03:46, 17 November 2015 (UTC)
•  Endorsed This would automate actions that can already be accomplished manually. It would be helpful for watching future actions of confirmed vandals and spammers, which is not necessarily an admin task. I'm fine with making this a user-right that needs to be requested (perhaps a similar procedure as asking for rollbacker rights). Etamni (talk) 07:09, 17 November 2015 (UTC)
•  Endorsed 4nn1l2 (talk) 00:12, 19 November 2015 (UTC)

Watchlist timed expiry

Tracked in Phabricator:
Task T100508

I would like to be able to set an expiry time for watchlist items, of say one week or one month. There are many pages that I do maintenance on or repair vandalism that I would like to watch for a brief period of time, but have no long term interest in. The UI I envisage would just have additional tick boxes: watch this page indefinitely, watch for one week; watch for one month. Derek Andrews (talk) 23:49, 8 November 2015 (UTC)

• This is on the radar of the German TCB team, with no ETA.  Endorsed if the Community Tech team can help get this out the door faster. MER-C (talk) 20:35, 9 November 2015 (UTC)
•  Endorsed--Shizhao (talk) 02:00, 10 November 2015 (UTC)
•  Endorsed--V111P (talk) 06:44, 10 November 2015 (UTC)
•  Endorsed. Helder 11:30, 10 November 2015 (UTC)
•  Endorsed --Yann (talk) 16:11, 10 November 2015 (UTC)
•  Endorsed --Jarekt (talk) 19:16, 10 November 2015 (UTC)
•  Endorsed Thibaut120094 (talk) 23:33, 10 November 2015 (UTC)
•  Endorsed This would be particularly useful for vandalism- and new page patrollers, I think. Fluffernutter (talk) 17:23, 11 November 2015 (UTC)
•  Endorsed Sarah ^talk 21:42, 11 November 2015 (UTC)
•  Endorsed This could be extremely useful to admins allowing them to watch "hot spots" where blocking or protection has had to be employed but where they have no personal interest in the page in the long term. Beeblebrox (talk) 01:24, 12 November 2015 (UTC)
•  Endorsed --Helichrysum Italicum (talk) 08:04, 13 November 2015 (UTC)
•  Endorsed I now default everything to unwatched and occasionally purge thousands of pages from my watchlist. If I had a feature such as this I would be happy to default to watchlisting pages I delete or edit for a few weeks. WereSpielChequers (talk) 04:45, 14 November 2015 (UTC)
•  Endorsed Extremely valuable, and this is one of the easiest items to implement. Alsee (talk) 11:40, 15 November 2015 (UTC)
•  Endorsed Yes. IJBall (talk) 03:47, 17 November 2015 (UTC)
•  Endorsed Per my comments in another proposal, this is needed. Etamni (talk) 07:25, 17 November 2015 (UTC)
•  Endorsed Yes. JohnCD (talk) 22:48, 17 November 2015 (UTC)
•  Endorsed 4nn1l2 (talk) 00:14, 19 November 2015 (UTC)

Section watchlists

Tracked in Phabricator:
Task T2738

I would love to be able to watch sections of a page instead of whole articles, particularly for pages like Reference Desk. Otherwise, pertinent changes to sections that interest me get superceded by subsequent changes to other sections.

 Endorsed Agree would be useful for ANI were all one may be interested in is certain sections. Doc James (talk · contribs · email) 07:14, 28 May 2015 (UTC)

Superseded by Flow? --Ricordisamoa 16:06, 6 June 2015 (UTC)

Yes Flow would solve this issue I think. Doc James (talk · contribs · email) 16:10, 6 June 2015 (UTC)

No, because Flow is a failed experiment. The Quixotic Potato (talk) 14:43, 12 November 2015 (UTC)

No, because the Future of Flow is unclear, and it doesn't alter the request to watchlist sections that aren't Flowized. Alsee (talk) 12:29, 14 November 2015 (UTC)

 'Endorsed'Support. Section watchlisting is a long requested and very valuable ability. This is clearly NOT Superseded by Flow, as Flow obviously doesn't work on non-Flow pages, and obviously can never work in Articlespace. Alsee (talk) 19:50, 16 September 2015 (UTC)

•  Endorsed This is particularly important on noticeboards and discussion boards, which may have dozens or even hundreds of sections, and which, when watchlisted, are nearly impossible to follow a single thread on because of that. Fluffernutter (talk) 17:13, 11 November 2015 (UTC)
•  Endorsed Would help. --Piotrus (talk) 04:34, 12 November 2015 (UTC)
•  Endorsed —MisterSynergy (talk) 12:54, 12 November 2015 (UTC)

 Endorsed --Gnom (talk) 21:19, 12 November 2015 (UTC)

•  Endorsed this is valuable in all namespaces. Article sections, policy sections, workflow sections, and of course discussions. Alsee (talk) 12:17, 14 November 2015 (UTC)
•  Endorsed Per my comments in another proposal, this is needed. Etamni (talk) 07:26, 17 November 2015 (UTC)

Cross-wiki watchlist

Tracked in Phabricator:
Task T5525

Now that SUL finalization is complete, there is no longer an obvious obstacle to developing a proper cross-wiki watchlist. This is a very old request (phab:T5525 from September 2005) and has been cited as one of the reasons why users on, say, Wikipedia are reluctant to branch out and participate on Meta, Commons, etc. There has been an effort to develop this as an external OAuth tool (phab:T92955), but it really should be developed within MediaWiki itself, dovetailing in with the existing Special:Watchlist page in some manner. This, that and the other (talk) 10:05, 17 July 2015 (UTC)

Note: the bug had 32 votes. --Nemo 11:00, 17 July 2015 (UTC)

Note: Upcoming phab:T92955 is released as Crosswatch. --Menner (talk) 06:39, 19 August 2015 (UTC)

Right now every time I want to check my watchlist, I do it separately for Persian Wikipedia, Commons, English Wikipedia, Meta, and Wikidata. I have to open five pages and check them one by one. If we can have a central place for all of my watched pages (or at least some number of opt-in wikis). It would make my life much easier. We do have a tool in WMF Labs but something integrated with mediawiki sounds more convenient to users. Amir (talk) 23:47, 9 November 2015 (UTC)

 Endorsed. This is also one of the reasons some people are so keen to just upload images locally rather than at Commons. Jenks24 (talk) 02:30, 10 November 2015 (UTC)

I was just thinking about cross-wiki watchlist and also cross-wiki notifications yesterday :) Yes, please. --Edgars2007 (talk) 05:24, 10 November 2015 (UTC)

 Endorsed. Helder 11:30, 10 November 2015 (UTC)

 Endorsed Useful. בנימין (talk) 14:21, 10 November 2015 (UTC)

•  Endorsed --Yann (talk) 16:23, 10 November 2015 (UTC)
•  Endorsed As all accounts are nowadays SUL accounts, this appears to be a natural next step. Likewise, notifications should be cross-wiki enabled. --AFBorchert (talk) 18:21, 10 November 2015 (UTC)
•  Endorsed --Jarekt (talk) 19:19, 10 November 2015 (UTC)
•  Endorsed - I already see this would be useful and I have only been involved in 3 or 4 wikis ArthurPSmith (talk) 19:27, 10 November 2015 (UTC)
•  Endorsed I think this is one of the long overlooked high priorities that we identified in the 2009 strategy process. WereSpielChequers (talk) 19:40, 10 November 2015 (UTC)
•  Endorsed Danmichaelo (talk) 21:24, 10 November 2015 (UTC)
•  Endorsed. Also the additional features from the Labs tool (eg. inline display of diff's) plus the ability to dismiss the notifications you already acknowledged (may be implemented with cookies to exempt the server from more load) and a "send thanks" button. --Usien6 (talk) 02:46, 11 November 2015 (UTC)
•  Support. — Green Zero обг 09:18, 11 November 2015 (UTC)
•  Endorsed. Multichill (talk) 09:57, 11 November 2015 (UTC)
•  Endorsed —Ynhockey (talk) 12:26, 11 November 2015 (UTC)
•  Endorsed Please, please, pleeeeease. Fluffernutter (talk) 17:24, 11 November 2015 (UTC)
•  Endorsed --Gnom (talk) 10:00, 12 November 2015 (UTC)
•  Endorsed very valuable. Alsee (talk) 23:46, 14 November 2015 (UTC)
•  Endorsed - modeled on Special:Watchlist it would be great. Scannable, one item per line. No margins left unused. --Timeshifter (talk) 00:24, 17 November 2015 (UTC)
•  Endorsed -- needed :JarrahTree (talk) 00:07, 18 November 2015 (UTC)
•  Endorsed Please. Also, cross-wiki preferences — Arkanosis ^✉ 16:30, 18 November 2015 (UTC)

Shared watchlists

It would be nice to be able to share a common watchlist between legitimate alternative accounts. Currently, watchlisted items must be manually copied between accounts. Any editor with an alternative account who uses watchlists would benefit. There is already a "key" that allows a watchlist to be exported via a feed, so adding the ability to input that key into a different account should be fairly simple. Example of how this might be used: I have my main account (Etamni) as well as a declared alternative account used for mobile edits and edits from shared computers or public WiFi (Etamni-m). This ability would allow me (or others in similar positions) to use a master watchlist for both accounts. If I add or remove a watchlist item from either account, the change would apply to both accounts automatically. This would be an opt-in feature and would not apply to editors who don't want to use it. Etamni (talk) 08:17, 17 November 2015 (UTC)

One could create a page X in your userspace that links the pages to be watched, then go to Special:Recentchangeslinked/X. MER-C (talk) 12:14, 17 November 2015 (UTC)

Tools for fly-by-night-editors to analyze silent reverts

Backgound

I am a fly-by-night-editor: Most of my edits are to pages I visit only once. Occasionally I get feedback for my edits in the form of a overt revert, but not very often. If I were an optimist, I would pat myself on the back and assume that my work has been accepted. But I am a realist and I know that many of the edits I made have been silently reverted once I have left the scene, when another editor simply edited over my edit rather than revert it. This is my definition of a silent revert.

Silent reverts happen for two reasons I can think of:

• The most common is probably done by another fly-by-nighter who parachutes into an page, knows nothing about its history and simply edits something that s/he believe needs fixing
• There are also a few editors who revert silently deliberately on-the-sly. In my case these types are stalkers who for reasons they have never shared with me just do not like my edits. They know I do not watch pages I edit and take advantage of it.

Tool request

It would be nice to have a tool that one could use to analyze a sampling of articles one edited to easily spot Silent reverts.

Sorry for submitting this half-baked tool request, but it looks like time is running out on this survey. Ottawahitech (talk) 15:34, 19 November 2015 (UTC)

Dropdown diffs of last edits

This has been implemented in Crosswatch. It should be incorporated into Special:Watchlist too. It is revolutionary, and will make it easier to edit more. If editors can edit more in the same period of time, then that can help maintain the number of active editors (5 or more edits per month):

• File:Active editors on English Wikipedia over time.png --Timeshifter (talk) 18:01, 19 November 2015 (UTC)

Add a Category watchlist

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

I've got good news on this one :) TCB, Wikimedia Deutschland's Community Tech team, has been working on a Category watchlist, and we should see the first deployments within the next few weeks. You can check out the Phabricator ticket for more details. -- DannyH (WMF) (talk) 22:54, 18 November 2015 (UTC)

---

Tracked in Phabricator:
Task T9148

Add a category watchlist feature, that lists all changes, additions to, and removals from a category. En-Wiki has HUGE maintenance backlogs dating back to 2006 or earlier in categories like Articles lacking sources. I don't think those backlogs would be as bad if we could watchlist categories and know when an article was added to them. Likewise, some articles have a significant overlap, and if interested editors could watchlist categories and see when new articles were added to categories it would help avoid unnecessary duplication of content. ONUnicorn (talk) 14:11, 8 November 2015 (UTC)

• This is currently being worked on right now by the German TCB Team and will be made available in the coming months. See the linked ticket for details. I  Endorsed this, by the way, if Community Tech can help get this out the door faster. MER-C (talk) 14:19, 8 November 2015 (UTC)

1.  Endorsed I need that too. JackPotte (talk) 23:02, 9 November 2015 (UTC)
2.  Endorsed --Ilya (talk) 23:11, 9 November 2015 (UTC)
3.  Endorsed --Nicolabel (talk) (sysop in it.wp) 23:18, 9 November 2015 (UTC)
4.  Endorsed --JarrahTree (talk) 00:19, 10 November 2015 (UTC)
5.  Endorsed Beeblebrox (talk) 00:41, 10 November 2015 (UTC)
6.  Endorsed –Davey2010^Talk 00:53, 10 November 2015 (UTC)
7.  Endorsed Esquilo (talk) 08:06, 10 November 2015 (UTC)
8.  Endorsed בנימין (talk) 15:05, 10 November 2015 (UTC)
9.  Endorsed --Yann (talk) 16:08, 10 November 2015 (UTC)
10.  Endorsed WereSpielChequers (talk) 19:26, 10 November 2015 (UTC)
11.  Endorsed Fluffernutter (talk) 17:22, 11 November 2015 (UTC)
12.  Endorsed Sarah ^talk 21:41, 11 November 2015 (UTC)
13.  Endorsed absolutely yes! --Helichrysum Italicum (talk) 08:04, 13 November 2015 (UTC)
14.  Endorsed Jheald (talk) 13:10, 13 November 2015 (UTC)

This feature is now in core MediaWiki, but disabled by default. @Addshore: What else needs to be done for this to be deployed and enabled? MER-C (talk) 13:22, 14 November 2015 (UTC)

 Oppose calling this a new "Community Tech project". This is obvious very valuable, but it appears to be completed, deployed, and awaiting routine-review(?) to flip the on-switch. Alsee (talk) 13:11, 15 November 2015 (UTC)

---

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Cross-Wiki Watchlists

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Duplicate of #Cross-wiki_watchlist. MER-C (talk) 18:30, 12 November 2015 (UTC)

---

Tracked in Phabricator:
Task T5525

Notes and bug-links collated at mw:Watchlist wishlist.

Now that SUL finalization is complete, there is no longer an obvious obstacle to developing a proper cross-wiki watchlist. This is a very old request (phab:T5525 from September 2005) and has been cited as one of the reasons why users on, say, Wikipedia are reluctant to branch out and participate on Meta, Commons, etc. There has been an effort to develop this as an external OAuth tool (phab:T92955), but it really should be developed within MediaWiki itself, dovetailing in with the existing Special:Watchlist page in some manner. This, that and the other (talk) 10:05, 17 July 2015 (UTC)

Note: the bug had 32 votes. --Nemo 11:00, 17 July 2015 (UTC)

Note: Upcoming phab:T92955 is released as Crosswatch. --Menner (talk) 06:39, 19 August 2015 (UTC)

 Endorsed. See also https://github.com/he7d3r/mw-gadget-CrossWikiWatchlist. Helder 12:01, 12 November 2015 (UTC)

---

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Watch single sections of a Talk Page

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Duplicate of #Section watchlists. MER-C (talk) 12:27, 12 November 2015 (UTC)

---

Sometimes, I just want to watch a single section of a Talk Page and not all of it. Thanks, --Gnom (talk) 10:13, 12 November 2015 (UTC)

It's now available using mw:Flow and can be activated on talk pages (or user talk page) per user or community request, for example mw:Talk:Flow. Kenrick95 (talk) 11:23, 12 November 2015 (UTC)

Unfortunately, it is not clear whether all communities will get Flow in near future. And even if so, it will certainly not replace all talk pages. WMF has realized that Flow is a good piece of software, but also far away from being a solution for all talk pages. We will therefore have to continue to deal with regular wikitext talk pages for quite some while. This proposal needs endorsement. —MisterSynergy (talk) 11:44, 12 November 2015 (UTC)

 Endorsed —MisterSynergy (talk) 11:44, 12 November 2015 (UTC)

 Endorsed I hope those who still support Flow won't prevent us from getting improvements in talkpages without the burden of Flow. WereSpielChequers (talk) 11:47, 12 November 2015 (UTC)

---

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Wikidata

Automatic search for similar items in Wikidata

In small Wikipedias, where our task force is reduced, we have lots of pages (mainly subtemplates and categories) that are not linked to items in Wikidata. Some of this items (for example, automatic taxonomy subtemplates) can be found in different languages but it's a very hard work to link by hand all of them. As most of them follow the same structure, and many of them have even the same name, maybe a bot could suggest links. -Theklan (talk) 22:16, 9 November 2015 (UTC)

•  Endorsed but with cautious. Some language can have a same spelling, but different meaning totally. Need to be vetted by local verifier. Yosri (talk) 02:31, 10 November 2015 (UTC)

• https://tools.wmflabs.org/wikidata-todo/duplicity.php exists with a lot of this functionality. It generates suggestions that are pretty good in most cases. I have worked a bit on the ga:wp list and the outstanding items are mostly corner cases that the auto-suggester struggles with. Filceolaire (talk) 06:02, 10 November 2015 (UTC)
•  Endorsed --Gnom (talk) 09:59, 12 November 2015 (UTC)

Make it easy to build infoboxes that display information from wikidata

Tracked in Phabricator:
Task T112987

Currently, there is no well-established system across different wikipedias that would help editors to build infoboxes (there is no established Template:Infobox across different wikipedias).

Building an infobox that displays information from wikidata is even more difficult: Building a nice infobox that displays information from wikidata requires modules written in Lua (without that, it is impossible to make wikilinks work properly). It would be nice to have one standard Lua module for this purpose, maintained and stored in one central place (e. g. on meta), without the need for each and every wikipedia to copy this module over and continue to maintain the copy.

Both editors and readers would benefit from a solution. Furthermore, a solution would promote Wikidata, because it would be much easier to use information present on Wikidata on all wikipedias.

Proposed solution: Implement both A and B:

A. Devise a Template:Infobox that is easy to use and that is maintained in a central place.

B. (Perhaps a bit easier than A.) Write a Lua module that formats content from Wikidata properly (e. g. in a Wikipedia article about a city, create a formatted list of the sister cities (cf. d:Property:P190), where each list element is a link to the article about the sister city or, if this wikipedia does not yet have an article about a particular sister city, a link to the Wikidata item about this sister city). Provide this Lua module in a central place where every wikipedia can directly use it.

--UV (talk) 22:36, 9 November 2015 (UTC)

•  Endorsed For now Wikidata has almost no integration with Infoboxes. Scripts are lacking and buggy. Almost no data is used on Wikipedias, which questions importance of Wikidata existence as it's data is of almost no use. Lots of properties on Wikidata are missing because almost no one is using it to fill real Infoboxes on Wikipedias --Ilya (talk) 23:13, 9 November 2015 (UTC)
•  Endorsed Should allow individual language to insert translations. Yosri (talk) 02:22, 10 November 2015 (UTC)
  • About the globally stored infobox/module, that all Wikipedias can use without copy-paste part - the idea has been proposed several times (can't say by who or when or where). Some cool Wikidata data retrieving infoboxes, that I'm aware of - this one is fully taken from Wikidata (search for insource:/\{\{[Ii]nfobox - osoba\}\}/ in cswiki), also frwiki has some Lua modules for better Wikidata support - this one, for example. --Edgars2007 (talk) 05:36, 10 November 2015 (UTC)
•  Endorsed UV has a very good idea. I work on cycling (more info here), I produce a very big number of photos, and develop five modules (1, 2, 3, 4, 5). French users now work on Wikidata for a part, but the very big problem is I don't know how translate these modules in the other languages because all is different. It is a major problem in Wikipedia. We work together on Commons and on Wikidata, there is no problem, but we are not able to work together on Wikipedia because everybody has their own templates. I think if we solve that problem, we will permet to develop all smaller Wikipedias. Ans even for big Wikipedias it is interesting, because we have people to enter datas, so it is useless to let user do the same work in different country. And if people don't lost time to enter datas, they will can spend time to write, this is very positive for the project and for our readers. More than infoboxes, we will share list of participating teams and cyclists, classifications, team rosters... it will be very interesting when there will have a change, we will save again a big amount of time. I sometimes discuss with foreign users (like Papuass for .lv, Edgars2007), everybody find the idea as interesting, but very few people is able to play with templates and modules. To conclude, this proposal is very important because it will renew our way to work/contribute. Jérémy-Günther-Heinz Jähnick (talk) 10:49, 10 November 2015 (UTC)
  • Yes, of course I noticed that discussion at Papuass' talk page :) Latvian has some few problems that one user can't handle, but that isn't discussion for here. And I'm not a Lua coder :) --Edgars2007 (talk) 16:05, 10 November 2015 (UTC)
•  Endorsed. Helder 11:30, 10 November 2015 (UTC)
•  Oppose. Is blocked by phab:T1238 (Central Code Repository for code used on wikis -- Templates, Lua modules, Gadgets), and hence is not feasible. MER-C (talk) 15:55, 10 November 2015 (UTC)
•  Endorsed--Gbeckmann (talk) 21:37, 10 November 2015 (UTC)

•  Like but  Oppose at this time. Some random thoughts gathered from my own experience...
  • Wikidata does not contain all Property information and that should probably be addressed as a high priority 1st.
  • Though a nice idea; however, one size does not fit all (IMHO).
  • The labels in Wikidata for properties might not be useful to produce labels in an infobox if one wants to use a Module to build a complete infobox from scratch.
    • I have seen at least one Wikidata entry with no title or label.
  • The actual data retrieved may not be satisfactory and acceptable for everyone.
  • Accessing Wikidata multiple times to fill in entries of an infobox (multiple template calls for each property) may take a load hit and result in a Lua runtime error.
    • To get to some information one may have to drill down into the Wikidata structure to get the desired data. (to get a currency symbol as an example)
    • One may have also to access multiple Wikidata entities (Objects) to get other desired data as well. (Wikidata entry IDs for sister cities as an example)
  • May need to know the id (Qnnn) if an article is not associated with a Wikidata entry but does in fact have a Wikidata entry.
  • Language translation(s) may be an issue in Wikidata. (Not sure if all languages are incorporated or represented.)
    • In Wikidata use ?setlang=xx in URL to see if other languages exist -- access via a module using mw.language.getContentLanguage(arg1).code
  • Some properties have multiple instances.
    • In some cases, all instances would be relevant (ie. sister cities, bordering countries etc.)
    • Description(s) on the other hand may present a problem. (which one is useful - is it acceptable)
  • There may be code/design changes for wikibase and Wikidata which might result in further issues (are these solid enough?).
  • Use of Unicode characters and internationalisation need to be included in any Module.
  • Sorting of multiple instances and formatting of data output - presents another decision to be made.
  • Accessing a certain or particular data element may be useful (ie. flag, coat of arms, decimal latitude, longitude).
  • Timing of the execution of a template and a module may also present a problem (if other widget/code occur before the actual retrieved data is available). Matroc (talk) 04:55, 11 November 2015 (UTC)
• Related tasks: phab:T114251 ("Magic Infobox Implementation"), phab:T112987 (Wikimedia Developer Summit 2016 proposal discussing the various options) Cscott (talk) 18:45, 11 November 2015 (UTC)

Whole Infobox from Wikidata

Most of the data are still embedded on the article's infobox, while all the information should be stored and retrived from Wikidata. The approach should be (in any order):

• write a complete LUA module able to collect any kind of information (not only the easiest ones with one single value)
• those information should be formatted according to the specific wiki-project standards
• all the information currently stored in each project should be moved from each specific wiki-project (deleted) and stored in Wikidata
• the information on wikidata should follow a standard in order to simplify the data collection & formatting

this would avoid data discrepancy between sister projects and between language versions of the same project.

A nice to have would be a pop-up window that allow to change/update any infoboax data in Wikidata, without leaving the current wiki project. --Andyrom75 (talk) 00:13, 10 November 2015 (UTC)

I think this is a candidate for merging with this idea.  Like the idea about pop-up window. Something (basic structure) can be taken from this one. JS coders could create the base structure, that can be adapted for each infobox later by non-JS coders (like just filling the form) --Edgars2007 (talk) 05:46, 10 November 2015 (UTC)

 Endorsed. Helder 11:30, 10 November 2015 (UTC)

Edgars2007, Helder FYI in Wikivoyage we already use pop-up windows for other purpose. Although they would need further development (especially for language versions customization), they are already enough user friendly. For example see it:voy:Firenze and click on any gray and small "modifica" link. --Andyrom75 (talk) 11:48, 10 November 2015 (UTC)

 Endorsed. In Basque language Wikipedia we have been making some work on this topic. Here you have an example of our last work: eu:Autauga konderria (Alabama). It could be easier, but we need some LUA experts and we lack them. -Theklan (talk) 13:01, 10 November 2015 (UTC)

Information in an Infobox is usually a codified version of the article text. If we transclude the infobox from Wikidata the people who watchlist the article won't know when the infobox changes, and we will have more situations where the infobox contradicts the article text. This is a problem! It could be reduced by amending watchlists so that if you watchlist a page you are informed of changes to its infobox in wikidata. WereSpielChequers (talk) 19:00, 10 November 2015 (UTC)

 Endorsed--Gbeckmann (talk) 21:10, 10 November 2015 (UTC)

• Similar to the previous proposal; see also phab:T112987 and phab:T114251. Cscott (talk) 18:54, 11 November 2015 (UTC)

Wikidata support for Wiktionary

ENable wikidata support for interwiki (phase 1) as soon as possible at least for other than main namespace. JAn Dudík (talk) 07:52, 10 November 2015 (UTC)

 Endorsed. Helder 11:30, 10 November 2015 (UTC)

 Endorsed. HakanIST (talk) 12:40, 10 November 2015 (UTC)

@JAn Dudík: I may be wrong, but don't think, that this is in the team's scope. This probably should get posted here. --Edgars2007 (talk) 16:14, 10 November 2015 (UTC)

 Endorsed Aryamanarora (talk) 18:51, 10 November 2015 (UTC)

This is on the Wikidata team's list for 2016. --Lydia Pintscher (WMDE) (talk) 14:12, 13 November 2015 (UTC)

 Endorsed I still endorse this. It is required high time. --Satdeep Gill (talk) 13:15, 14 November 2015 (UTC)

Gender-specific labels for Wikidata objects

Slovene and other Slavic languages (and perhaps some others too) use gender-specific words to describe occupation of a person, with male form being default. It would be useful to add a descriptor M/F to an object's description in a given language, and enable targeted transclusion of this data to Wikipedias. Then, infoboxes for women could be auto-filled with appropriate words. This would of course necessitate creating a second label for the variant for the other gender, so I don't know it it's really feasible, but it's something to think about.

This functionality is already being discussed at Wikidata (see d:Wikidata:Property proposal/Unsorted#Female form of label (string)), but maybe additional attention would help to find a solution. — Yerpo ^Eh? 12:05, 10 November 2015 (UTC)

 Oppose. Recruitment companies in most of these countries are working at creating gender neutral labels for occupations and these are what we should be using for labels in all languages in Wikidata because the wikidata items are gender neutral so any label that isn't is a label that is wrong. This is just as the English words 'actor' and 'waiter' have, over the last twenty years, come to mean either a man or a woman. The solution to this problem is first to resolve a way to give these occupations gender neutral labels ('programador/a' or even 'programador or programadora'). That is not a technical problem the Community Tech can help with.

Once we have the gender neutral labels sorted then we can look at whether we also need properties for the male and female versions and a couple of lines of Lua code to find them or if we can just switch to using the gender neutral labels in wikipedia infoboxes in all languages. Filceolaire (talk) 06:47, 13 November 2015 (UTC)

@Filceolaire: gender-neutral labels are of course possible, but cumbersome if the purpose is to fill infoboxes. We aren't recruiting unknown people to fulfill some roles, we are describing existing men and women (in other words, Ada Lovelace is not a programador/a, she is a programadora). I don't understand why should we condition looking for solution with setting up an inelegant system. Instead, an inelegant system should be put in place if a better solution is not possible. — Yerpo ^Eh? 07:49, 13 November 2015 (UTC)

Reasonator as stub page handler

See also Filling red links with Wikidata

On a small wiki, visiting any missing page or searching for a page not on the wiki should load up Reasonator in the local wiki language. For example, the Johann Sebastian Bach info page can and should be shown on all 272 wikis that don't have a J.S. Bach page. Global south!

• Comment We would need a campaign to translate Wikidata content or the small wikis would be filled with generated English articles. --Molarus (talk) 10:37, 15 November 2015 (UTC)
• We will not do this with Reasonator. However the underlying idea is already in development with the ArticlePlaceholder and will go live in early 2016. --Lydia Pintscher (WMDE) (talk) 12:49, 15 November 2015 (UTC)

Modify Media Viewer to include Wikidata information

When the Media Viewer is enabled, if a Wikipedia user clicks on a file image, the information shown is summarized from Commons. Though not all Commons images have Wikidata items and this will probably never happen, many images of artworks such as paintings and sculptures have very detailed items on Wikidata that can be offered to the user in his/her native language. For images that are linked with Wikidata items, the user should be offered the "More information" button with the WIkidata logo in addition to the "More information" button with Commons logo. If this is enabled, it should also become easier to add a wikidata item number to all images in a Commons category (e.g. artworks have detail images etc) so that whichever file is viewed on Wikipedia, the media viewer will be able to pick up the correct wikidata item for that image even though it is not the "lead image" on Wikidata for that item. --Jane023 (talk) 12:51, 19 November 2015 (UTC)

Wikisource

Allow Copy of Pages

As a Wikibooks user, I would like to see the feature "copy this page" (source, target) next to the move-feature. This would be great for normal user extending a book without touching the original one.

Example: Lets say you would like to improve a book about the programming language "Java". The book describes version 6 and you would like to start a new book on version 8. If it is worth having both books, than I see no way to preserve the original book and edit the text with respect to the original editors.

Example: Lets say two contributors have different but strong opinions about the future of a book. This typically leads to conflicts, where some user leave the community. The copy-the-page feature would be a good technical solution to settle the conflict.

-- Qwertz84 (talk) 23:17, 9 November 2015 (UTC)

•  Endorsed Would be very helpful on Wikisource too... --Ernest-Mtl (talk) 03:35, 10 November 2015 (UTC)

• This could be considered a use case for phab:T113004 (branching support), and there is a related proposal above. Cscott (talk) 18:47, 11 November 2015 (UTC)

@Qwertz84 and Ernest-Mtl: There is an Extension to duplicate pages (with their edit history): mw:Extension:Duplicator. It works fine. -- Reise Reise (talk) 17:21, 14 November 2015 (UTC)

Tool to use Google OCRs in Indic language Wikisource

For a long time Indic languages Wikisource projects depended totally on manual proofreading, which not only wasted a lot of time, but also a lot of energy. Recently Google has released OCR software for more than 20 Indic languages. This software is far far better and accurate than the previous OCRs. But it has many limitations. Uploading the same large file two times (one time for Google OCR and another at Commons) is not an easy solution for most of the contributors, as Internet connection is way slow in India. What I suggest is to develop a tool which can feed the uploaded pdf or djvu files of Commons directly to Google OCRs, so that uploading them 2 times can be avoided. -- Bodhisattwa (talk) 13:50, 10 November 2015 (UTC)

•  Endorsed --Yann (talk) 16:30, 10 November 2015 (UTC)
•  EndorsedJayantanth (talk) 18:09, 10 November 2015 (UTC)
•  Endorsed , and other languages--Shizhao (talk) 02:28, 11 November 2015 (UTC)
•  Endorsed --Satdeep Gill (talk) 07:34, 13 November 2015 (UTC)
•  Endorsed --Pmlineditor (t · c · l) 16:34, 13 November 2015 (UTC)
•  Endorsed--Charan Gill (talk) 11:33, 14 November 2015 (UTC)
•  Endorsed--Omshivaprakash (talk) 12:02, 14 November 2015 (UTC)
•  Endorsed--Vikassy (talk) 16:26, 17 November 2015 (UTC)

Better support for djvu files

Djvu files are a very interesting open format for full book digitalization, but mediawiki uses them only as "proofreading tools". On the contrary, they could be an interesting output of wikisource work, working about thoroughly editing of text layer and fully using their metadata. Even when they are used simply as "proofreading tools", much work could be done using details of text layer mapping, since it contains interesting suggestions about formatting (text alignment and indentation, text size, paragraphs, blocks...) presently not used at all.

Here a list of ideas:

1. to shift to indirect mode of djvu structure (so allowing a faster access to individual pages with a djvu reader extension of browsers);
2. to add a set of API requests, as an interface to all read-only DjvuLibre routines;
3. to add some API too for editing text layer by djvuxmlparser;
4. to allow minor changes of djvu files (i.e. editing some words into text layer) without the need of re-uploading the whole djvu file (the history of text edits could be saved with something like reviews history).

--Alex brollo (talk) 14:07, 10 November 2015 (UTC)

 Endorsed really really useful in wikisource context. --AlessioMela (talk) 14:12, 10 November 2015 (UTC)

•  Endorsed --Yann (talk) 16:30, 10 November 2015 (UTC)
•  EndorsedJayantanth (talk) 18:00, 11 November 2015 (UTC)

To implement a Internet Archive-like digitalization service

Just as many other wikisource users I appreciate a lot Internet Archive digitalization service, and I use it as deeply as I can (djvu files being only one from many uses of the rich file set that can be downloaded: collection of high-resolution jp2 images and abbyy xml being really extremely interesting).

I'd like that mediawiki should implement a similar digitalizing environment, but with a wiki approach and a wikisource-oriented philosophy, to share the best possible applications to pre-OCR jobs of book page images (splitting, rotating, cropping, dewrapping... in brief, "scantailoring" images), saving excellent lossless images from pre-OCR work; then the best possible OCR should be done, with ABBYY OCR engine or similar software if any, saving both text and full-detail OCR xml; then excellent images and best possible OCR text should be used to produce excellent seachable pdf and djvu files; finally - and this step would be really "wiki" - embedded text should be fixed by usual user revision work done into wikisource.

This is a bold dream; a less bold idea is, to get full access to best, heavy IA files (jp2.zip and abbyy xml) and to build tools for use them as thoroughly as possible. --Alex brollo (talk) 07:08, 11 November 2015 (UTC)

 Endorsed. Jayantanth (talk) 17:42, 11 November 2015 (UTC)

 Endorsed --Yann (talk) 14:06, 17 November 2015 (UTC)

Visual Editor adapted for Wikisource

Tracked in Phabricator:
Task T48580

Actually, Wikisource is using the old but reliable text editor. This requires all Wikisource contributors to know lots of templates that are different from one Wikisource language to another. Having a special version of the Visual Editor, adapted for the Wikisource needs, would facilitate inter-language help on Wikisource and bring ease to new contributors on the Wikisource projects. By having selected buttons on this adapted Visual Editor for titles, centering, left or right margins text, tracing lines, etc, would be easy to learn, especially if those are derived from a word processor general look and contribute to bring people on different language Wikisource...

Placing a title in French, in English, in Spanish or Croatian would now be the same thing : selecting the text and pressing a button... not use a different named-template depending on which Wikisource you are. Many people could help proofread pages in different languages, for example, with a global project of the week... Myself, being a french-speaking canadian, yes, I could proofread in French, English, Russian, Ukrainian, Spanish, but I'd need to know all the different templates in all these languages,and as my level of speaking and understanding in these languages are not as fluent as my native language, it is sometimes difficult to find and search on the other Wikisource projects... But nothing would prevent me from helping on any of those or even an Italian, Bulgarian or Portuguese special projects... These are the same fonts... Proofreading only needs us to be able to compare the orignal text of the book and the text transcribed... But not knowing all the templates on the different other wikisource prevent me of helping other communities...

The magic in all this, we don't have to re-invent the wheel! I figure it would be easy to apply some modification to the actual Visual Editor used on the other projects to be able to concentrate the needs of Wikisource editing in a concise list of buttons for the most basics needs, that would allow to proofread 95% or even more of the actual book pages... Worst case scenario, the 5% left would be done the old-fashion way...

--Ernest-Mtl (talk) 03:31, 10 November 2015 (UTC) — WMCA

 Endorsed Slowking4 (talk) 04:36, 11 November 2015 (UTC) user interface major impediment to new users - make WSUG happy

I believe the linked phab task (phab:T48580) is at least one of the prerequisites to this task. Generally speaking, wikisource uses several extensions to mediawiki core, and both Visual Editor and Parsoid need to have code added to support those extensions. cscott (talk) 18:57, 11 November 2015 (UTC)

Tool to upload from Panjab Digital Library

Panjab Digital Library has 1791 manuscripts and 8996 books on their website. All the manuscripts are in public domain and many books are also in public domain. Most of the manuscripts and books are in Punjabi language but some of them are in English, Hindi and Persian as well. They have digitized everything in form of images and they are not searchable. They have uploaded images in such a form that it is quite difficult to download them. I think a tool should be created to download all the manuscripts and books which are in Public domain. This will help in developing Punjabi Wikisource as well as Punjab related content on other Wikisources. This will again help in improving other projects as well. --Satdeep Gill (talk) 07:31, 13 November 2015 (UTC)

• We have BUB which could be fixed and patched to support this source as well. The maintainers don't currently have time to make it work again. Nemo 09:49, 13 November 2015 (UTC)
• Hi Nemo, patch to support Digital Library of India is also appreciated. -- Bodhisattwa (talk) 11:47, 14 November 2015 (UTC)

 Endorsed. We definitely need these sources to be made available in multiple formats and multiple sources as government sites always go missing all of a sudden. An another reason to upload these sources to wikimedia project is to get away from technical difficulties in finding and researching further on the material through collaboration. Omshivaprakash (talk) 10:34, 14 November 2015 (UTC)

 Endorsed the idea of fixing the BUB or DLI Downloader. --Subhashish Panigrahi (talk) 12:31, 14 November 2015 (UTC)

 Endorsed--Charan Gill (talk) 15:14, 14 November 2015 (UTC)

 Endorsed--Hundalsu(talk)

 Endorsed--Dineshkumar Ponnusamy (talk) 08:43, 17 November 2015 (UTC) 08:42, 17 November 2015 (UTC)

Miscellaneous

Page-view Stats tool

Wikipedia uses the old stats.grok.se that should be patched to be used corretly from the other wikis. Several bug have been highlighted long time ago, but no one took them in charge.

On the other hand recently has been developed wikiviewstats that is a more complete and flexible, graphic tool. Unfortunately, it has been stop, and no one was able to take it back on track.

I suppose that should be quicker to fix the above issues instead of writing from scratch a brand new stats tool able to monitor the accesses of any articles (fundamental to understand the visitor's insterests), however any of the two choices would be a good improvement. --Andyrom75 (talk) 22:01, 11 November 2015 (UTC)

 Endorsed. Seems to be something that's regularly complained about and also something that should be achievable. Jenks24 (talk) 10:43, 12 November 2015 (UTC)

 Endorsed Absolutely! IJBall (talk) 03:50, 17 November 2015 (UTC)

Create a bot to show changes in articles for each WikiProject

• Problem: I'm working on articles about gastropods (= snails), We already have more than 30,000 articles in the Wikipedia:WikiProject Gastropods. There is already a bot for new articles (en:User:AlexNewArtBot/GastropodsSearchResult), but not for changes made in existing articles. This makes it quasi impossible to track those changes and remove any possible vandalism. And this goes for all other WikiProjects.
• This would benefit all users.
• Proposed solution: creation of a bot for each WikiProject, tracking changes in each WikiProject. Articles in each WikiProject are easy to identify since they have a dedicated template on their talk page. JoJan (talk) 14:54, 8 November 2015 (UTC)

•  Oppose the proposed solution because it is WMF specific and WMF resources are better utilized improving the core software.  Endorsed a special page like Special:Recentchangeslinked as referred to in phab:T117122, as long as it is shipped with core MediaWiki. MER-C (talk) 15:05, 8 November 2015 (UTC)

• We certainly very much need something to show changes to articles within a project, however exactly it is done. Invertzoo (talk) 15:23, 8 November 2015 (UTC)

•  Endorsed a solution which makes tracking changes within a project straightforward. How this is done technically I have no idea. BernardP (talk) 22:58, 8 November 2015 (UTC)

•  Endorsed a solution which makes tracking changes within a project. --Snek01 (talk) 06:19, 9 November 2015 (UTC)

•  Endorsed. If somebody is interested there was a tool long time ago in old Toolserver times. Here is the user, but he's not active anymore. --Edgars2007 (talk) 10:16, 9 November 2015 (UTC)
•  Endorsed - project space and project tagging is either over-done or not at all - anything to create an even playing field and encouragement of a more balanced approach to project work - where ever or how ever :JarrahTree (talk) 00:27, 10 November 2015 (UTC)

@JoJan: Would you be satisfied with a solution like the one described in task T117122 (a special page rather than a bot)? Ryan Kaldari (WMF) (talk) 02:56, 13 November 2015 (UTC)

This would be a big step forward. All I want to do is check the changes in articles in all the categories (and these could be many), included within a particular WikiProject. JoJan (talk) 08:07, 15 November 2015 (UTC)

Text-to-speech for phonetically spelled words

I realize this may be a bit out of scope but I wanted to throw it out there...

It would be very useful to have some mechanism that would generate a sound file from phonetically spelled words, at least in English. Right now if one clicks on a phonetically spelled word (e.g. one tagged as a IPAc-en inline template), one is directed to a pronunciation key. It would be nice if wikimedia created some sort of function that would also sound out the word say in an .ogg file. Wikiliki (talk) 17:30, 9 November 2015 (UTC)

Or even just a tool that made it easy for anyone to record a sound file of the pronunciation and add it. Filceolaire (talk) 05:56, 10 November 2015 (UTC)

Collaborative way to generate SVG/PNG graphs using Lua modules

Extension:EasyTimeline lacks some features and doesn't support complex text rendering features needed for scripts other than Latin. Wikipedia community also created hand crafted family tree graphs, e.g. en:Template:Inglis family tree, using HTML tables hack. Now that we have a proper programming language support on Wikipedia wikis, it would be nice if SVG/PNG graphs could be generated using Lua script or wikicode by community, something like mw:Extension:Inline SVG extension but updated and ready to use, or adopting one of Lua bindings of Cairo graphic library. --ebrahim^talk 23:16, 9 November 2015 (UTC)

•  Endorsed --Ilya (talk) 23:26, 9 November 2015 (UTC)
• There is also the recently introduced Extension:Graph, it's not IMHO very user friendly, but work was done on de.wiki to generate simple graph using Lua and Graph extension (see de:Modul:Graph and imported in other wikis.--Moroboshi (talk) 13:35, 10 November 2015 (UTC)
• It's not user friendly because it's backed by Vega which is a pretty complicated visualization grammar that can do anything. Have you looked into Lyra (which is a GUI editor for Vega) and Vega Lite (which has a much friendlier but more limited syntax)? Curious if those would help make the Graph extension more useful, and happy to help make them a reality. Milimetric (WMF) (talk) 13:41, 11 November 2015 (UTC)
  • There should be better support for Graph extension in Lua modules - pie charts aren't supported, as far I understand, at least, they aren't included in documentation. And better help/documentation for Graph extension at Wikipedia/Meta Wiki. --Edgars2007 (talk) 11:31, 12 November 2015 (UTC)

Make SecurePoll feature-rich

Tracked in Phabricator:
Task T117127

Tracked in Phabricator:
Task T118073

SecurePoll extension is now used for ArbCom elections at English and Persian Wikipedias and WMF Board elections at Meta, all of which are multi-winner elections (i.e. multiple seats to be filled) but all the options that SecurePoll currently offers are single-winner voting systems. Approval voting, Schulze method, Range voting, and Plurality are all used to elect a single winner and using them to elect multiple winners is an abysmal choice. The conventional Support/Neutral/Oppose system widely used on Wikipedia is unprecedented in the real world — you cannot find any academic book or journal article on it so its possible disadvantages are unknown to us.

There is another problem: The English Wikipedia's ArbCom Elections and The WMF Board Elections usually end up with high turnout whereas elections on smaller communities, such as Persian Wikipedia, suffer from low turnout (about 50 voters). Low turnout requires a robust voting system to produce reasonable outcome. The Persian Wikipedia community is considering using alternative voting systems such as Meek STV which are not available in SecurePoll right now. I also propose to include various other methods available in voting software. I have also found an open source software which can be used to implement a proportional Condorcet method. You may want to see its algorithm. There is another software which covers various voting systems but is not free, namely OpenSTV. 4nn1l2 (talk) 23:40, 9 November 2015 (UTC)

•  Endorsed Huji (talk) 17:22, 13 November 2015 (UTC)
•  Endorsed Dalba 10:19, 19 November 2015 (UTC)

Searchable contributions

Resolved.

It would be nice to be able to search one's contributions by edit summary or such. For example, I label my proposed deletions as such, and then I check on them once or twice a year. Currently I have to look at 1000+ entries, and do a search for them using a browser function. Would be nice if this was doable through the contributions page itself. --Piotrus (talk) 05:04, 10 November 2015 (UTC)

Hmmm... There is such link at the bottom of user contributions page ("Edit summary search"), at least at enwiki. Or you are thinking about something else? --Edgars2007 (talk) 05:49, 10 November 2015 (UTC)

User:Edgars2007: wow, I never noticed that. Ha. Thanks. Through in this case I'd revise my request to: make the tool work faster. It's been chewing on my query for several minutes now... (Finished: Elapsed time: 332.21 seconds. ) --Piotrus (talk) 03:28, 12 November 2015 (UTC)

As in that tool is used the biggest Wikipedia database table (revisions), I think it can't be faster. --Edgars2007 (talk) 11:20, 12 November 2015 (UTC)

Virtual computer keyboard in search field

It would be good to introduce a virtual computer keyboard in search field (like in Google search field). There are moments when you can not use the keyboard. For example. I had two occasions when I broke my keyboard. Without a keyboard I could not type anything in the search field of Wikipedia. And this was very unpleasantly surprised me, because I was effectively denied access to Wikipedia. — Green Zero обг 10:19, 10 November 2015 (UTC)

@Green Zero: Your operating system already has a virtual keyboard. Windows users can find it at %SystemRoot%\system32\osk.exe and Macintosh users can follow these instructions. The Quixotic Potato (talk) 14:23, 12 November 2015 (UTC)

 Oppose as unnecessary. MER-C (talk) 16:34, 14 November 2015 (UTC)

 Oppose I broke my CPU, I was unpleasantly surprised to discover I was effectively denied access to Wikipedia (chuckle). I'm not opposed to this functionality per se, but I'm opposed to this taking the slot of more valuable Community Wishlist projects. Alsee (talk) 00:10, 15 November 2015 (UTC)

Yes, virtual keyboard is very complicated thing for programmers. — Green Zero обг 16:24, 15 November 2015 (UTC)

Enabling EPUB conversion on Wikipedia

Tracked in Phabricator:
Task T97672

There used to be a tool that enabled the conversion of Wikipedia articles into EPUB files. This functionality has been disrupted because the partnership between Wikimedia and PediaPress ended up. I wish the TechTeam could work on a new EPUB converting tool.--Kimdime (talk) 10:53, 10 November 2015 (UTC)

Reported on phab:T97672. Helder 11:32, 10 November 2015 (UTC)

There is a current Outreachy project to add OpenZIM export. Both ZIM and EPUB are standalone HTML variants, so in theory EPUB support will be easier once the ZIM support lands. Cscott (talk) 19:01, 11 November 2015 (UTC)

Preliminary Interwiki linking and Second language preferences

My idea is to allow users to create Preliminary interwiki linking on Wiki-data by linking existed article with non-existing article from another language. What are the benefits from this change? It will help our editors and visitors by giving them chance to read/translate articles from another language especially if they are bilingual/multilingual. Anyone can change his/her preferences and add "Second language" then the system automatically will connect any red links with blue link from his/her second language.

• Examples:
  • If french is my first language and English is my second:

conjonctivite allergique ^{[En anglais]}

• Spanish:

La conjuntivitis alérgica ^{[en Inglés]}

• English and set Arabic as second language:

Almashad mosque bombing ^{[In Arabic]}

I wish that you get my idea and if anyone wanna make any clarification he/she more than welcome :) --Ziad (talk) 13:19, 10 November 2015 (UTC)

 Endorsed This would also be nice to integrate with mw:Extension:ContentTranslation, so that bilingual users could easily start new articles from redlinks in their 'first language'. Cscott (talk) 19:05, 11 November 2015 (UTC)

Comment: Take a look at en:Template:Interlanguage link multi, which has much of the functionality. Finnusertop (talk) 18:09, 12 November 2015 (UTC)

wdsearch.js already offers this feature when visiting red links, try and open w:it:Terri Attwood. Content translation already offers to create an article by translation when clicking a red link, too. Nemo 18:14, 12 November 2015 (UTC)

We can't link articles preliminarily on Wikidata. Among other things we have not way to tell later if the article that was created at that place is actually about the topic it was linked with in Wikidata. --Lydia Pintscher (WMDE) (talk) 14:16, 13 November 2015 (UTC)

comment: That's why I suggested this idea to change wikidata and allow such thing. linking articles through wikidata will be manual task after that the system will automatically link articles on any Wikipedia page. --Ziad (talk) 16:19, 13 November 2015 (UTC)

It is not a matter of changing Wikidata. It is a fundamental issue with how article creation can be done independent of Wikidata. --Lydia Pintscher (WMDE) (talk) 12:52, 15 November 2015 (UTC)

Error categorization by #ifexist bug

Tracked in Phabricator:
Task T14019

Pseudolinks #ifexist by using the parser. On Special:WhatLinksHere also pages are disturbing enough, lists that contain templates that use #ifexist. Known since 2007. --Atamari (talk) 19:24, 10 November 2015 (UTC)

• I absolutely support this wish → «« Man77 »» ^[de] 19:10, 13 November 2015 (UTC)
•  Endorsed --Aschroet (talk) 18:40, 16 November 2015 (UTC)

WikiProject Wizard

Tracked in Phabricator:
Task T97210

Creating good WikiProject portals is extremely tedious and time consuming. It requires deep knowledge of WikiText template syntax and how to interface with the numerous tools and bots that exist for WikiProject portal use. Using FormWizard (or a new custom script), a wizard interface could be created for building WikiProject portals which would dramatically simplify the process.

As part of WikiProject X I wrote a requirements document for a Project Builder. I hope to work on it sometime in the next couple of months. harej (talk) 19:16, 11 May 2015 (UTC)

 Endorsed--Shizhao (talk) 07:53, 12 November 2015 (UTC)

 Endorsed -- :JarrahTree (talk) 00:10, 18 November 2015 (UTC)

Support for version branching for pages

Tracked in Phabricator:
Task T113004

Add ability to create own branch of page and ability to merge that version into main history (main branch). This would help to avoid most of edit wars and make comparing of different versions easier. --AS (talk) 10:13, 27 May 2015 (UTC)

I am not sure if I am understanding User:AS what you mean? Doc James (talk · contribs · email) 11:11, 27 May 2015 (UTC)

See w:Revision control. Branches need to be policed for garbage, and I'm not too sure giving everyone an easy means of making w:WP:STALEDRAFTs is a good idea. MER-C (talk) 13:21, 27 May 2015 (UTC)

I mean ability for a user to create a version (something like non-stabilized version in FlaggedRevs, but with few parallel versions, because there could be conflicts in non-stabilized version). For example a non-admin user can suggest a change for Main page, and if the change is ok, an admin just merges the version, without forking a page, copy-pasting etc.

It would be nice to have at least next abilities (which don't need core changes):

ability to fork page. Create a copy of page in personal namespace with one click and some magick to not include the page into categories. Why: for experiments and for users forbidden to edit particular pages.

ability to see diff of different pages. As I understand, there is currently no fast way to see diff of a fork and original page.

ability to partial reverting. During editing, when I see last diff, would be nice if I could just click some "revert" buttons next to particular chunks in diff so it would revert corresponding text in textarea. So I don't need to jump between diff and text to revert some changes on a page. --AS (talk) 14:02, 27 May 2015 (UTC)

This would greatly complicate the process of article editing, steepening the learning curve, at a benefit only in very specific cases. It looks like an attempt to solve with technology a problem that should be solved socially. As for copying a page to personal namespace, just copying and pasting the wikicode will do: it's not a hard task that urgently needs simplifying. I share User:MER-C's concern that making it easier to create user drafts will lead to many mor stale drafts. MartinPoulter (talk) 14:30, 27 May 2015 (UTC)

„This would greatly complicate the process of article editing, steepening the learning curve“ — this way of editing would be optional. „It looks like an attempt to solve with technology a problem that should be solved socially“ — imho, for now we are solving with social conventions a problem that could be solved with both technology and conventions (and we should delegate as much problems to technology as possible). „making it easier to create user drafts will lead to many mor stale drafts“ — why stale drafts could be a problem (how many is too many)? --AS (talk) 16:25, 27 May 2015 (UTC)

We already have sandboxes for articles that are locked such as this one. How does this differ to that? Doc James (talk · contribs · email) 00:55, 28 May 2015 (UTC)

1) no fast way to compare (to preview diff of) sandbox with original page and with other sandboxes. 2) no ability for other person to merge my changes with saving of authority, so I'll be mentioned as author of the version (smth. similar to stabilizing version in FlaggedRevs). --AS (talk) 11:20, 28 May 2015 (UTC)

One just copies the current article into the sandbox hits save and than uses history to view the dif. One can state who the author is in the edit summary. I do this all the time when I edit in other languages and add content written by other people. Doc James (talk · contribs · email) 11:31, 28 May 2015 (UTC)

„uses history to view the diff“ - with original version, not with current version of original page (if I understand correctly). „One can state who the author is in the edit summary“ — that should be avoided if possible. --AS (talk) 08:57, 30 May 2015 (UTC)

Other problem: one can't see list of all sandboxes and can't see list of all proposed diffs --AS (talk) 19:29, 5 June 2015 (UTC)

phab:T40795? Helder 18:28, 10 June 2015 (UTC)

 Endorsed phab:T113004 is the proposal for the 2016 Wikimedia Developer Summit, and lists a large number of related tasks. It's probably the best place to put current discussion. cscott (talk) 18:13, 11 November 2015 (UTC)

en:Wikipedia:Content forking explains why this is a bad idea. The Quixotic Potato (talk) 14:46, 12 November 2015 (UTC)

 Oppose per my comments above and en:Wikipedia:Content forking. MER-C (talk) 16:35, 14 November 2015 (UTC)

I don't think that en:Wikipedia:Content forking actually is relevant at all. We already have "draft" namespaces, for instance. This could simply enable a better implementation of en:Wikipedia:Drafts, which is already consensus on enwiki. Further, English Wikipedia is not all of the wikimedia project; you'll notice that some of the requests about this feature come from wikisource or wikibooks. So citing policy on enwiki should not be considered determinative; once implemented each projects can determine whether to enable this on a namespace-by-namespace basis. Cscott (talk) 22:04, 18 November 2015 (UTC)

Ability to enable code editor separately from "enhanced editing toolbar"

Tracked in Phabricator:
Task T47850

For me "enhanced editing toolbar" is useful only because of code editor, so I'd like it to be enabled for me only in case I'm editing lua/javascript/css page --AS (talk) 09:31, 30 May 2015 (UTC)

A code editor appears whenever you want to edit a Lua / JavaScript / CSS page regardless of your "enhanced editing toolbar" preferences, isn't it? I believe this is true at least in mediawiki.org.--Qgil-WMF (talk) 08:34, 9 June 2015 (UTC)

No, the code editor is part of the enhanced toolbar (integrated into the WikiEditor extension). Disabling it will disable the code editor. Bawolff (talk) 04:12, 10 June 2015 (UTC)

Understood, thank you. I could not find a task corresponding to this request in Phabricator. If it is created, it should go under phab:tag/wikieditor/.--Qgil-WMF (talk) 07:55, 10 June 2015 (UTC)

phab:T47850? Helder 18:24, 10 June 2015 (UTC)

•  Endorsed --Edgars2007 (talk) 11:39, 12 November 2015 (UTC)

Technical user right to edit summaries

Tracked in Phabricator:
Task T15937

The user right to edit summaries. For example, I've made an edit in some Lua-module but forgot to leave an explanation of the change for other developers. --AS (talk) 11:42, 18 September 2015 (UTC)

See phab:T15937 and phab:T12105. Helder 12:16, 10 November 2015 (UTC)

•  Endorsed --Edgars2007 (talk) 11:40, 12 November 2015 (UTC)
•  Endorsed but only if the change-history of the summary itself is available to at least those who hold this user-right if not to the general public. Davidwr/talk 06:14, 16 November 2015 (UTC) Clarification: This condition that the history be available to everyone who has the ability to change an edit summary (or better yet, the general public) is for "normal" edit-summary changes. I am not demanding that changes to hide or suppress edit summaries for good reason (similar to what is currently done with revision-deletion and revision-suppression tools) be visible to everyone who has the ability to change an edit summary (far from it - the code should allow for non-current edit summaries should be oversightable (suppressable) and "revision-deletable" even if the page-revision is not oversighted or revision-deleted, with "enabling" this option done on a per-project basis according to that project's consensus). Davidwr/talk 23:44, 16 November 2015 (UTC)
•  Endorsed I would support the addition of the right of every user to ADD to their own edit summaries information they forgot to include, and to EDIT their own edit summaries if there have been no subsequent revisions. This is not contradictory. If I edit a page and forget to put in an edit summary, I could go back and do so. If I misspell something and realize it right after posting the edit, I could fix it. However, once someone else edits the underlying page, I could only ADD info to the end of my previous edit summary. This would still allow me to add a forgotten edit summary, but not remove what was already there when someone else made an edit after I did. There may need to be a time limit on either action to prevent abuse, and it should always be apparent to the reader when they are reading an edit summary that was added after the fact. Etamni (talk) 07:46, 17 November 2015 (UTC)

Editor Stats API/GUI

Create an API and/or GUI that can display information like:

• How many page views have the non-redirect articles User X has created received in their lifetime?
• How many bytes of text has User X added to all Wikipedia articles?
• User X has actively edited Wikipedia on how many days since they created their account? And what is their activity level in the past 6 months...
• What are the top 5 wikiproject categories of articles User X has edited in their lifetime? In the last 6 months?

I think these, and other similar queries could be used to create a Contributor's Dashboard (along with other statistics) which would demonstrate a lot of aggregate information about who does what and how much of it. The goal would be to create snapshots of what people work on that would make it easier to know whom to contact and whom you're dealing with when you interact. It'd also serve as a potential 'gamifying' motivator by letting editors see the growth in their stats over time. Ocaasi (talk) 17:48, 21 May 2015 (UTC)

Agree these are excellent ideas. Some of this data is already available on an article by article basis such as here for gout [13].

And the rest of the data could be added to here [14]

Clarifying who writes Wikipedia would improve transparency. Doc James (talk · contribs · email) 04:06, 22 May 2015 (UTC)

I love this proposal. We worked on making pageview stats publicly available, and that will be announced literally within a day or so. It's not queryable in the exact way requested here, but it wouldn't be hard to add another endpoint. Look out on the Analytics mailing list for an announcement and comment exactly how you'd like it improved. And we're focusing on edit data for the next 6 months at least (making it publicly queryable from a stable API). So the data for this is really close, now we just need some sort of user profile to dump it into, and various teams at the foundation have worked on that. Milimetric (WMF) (talk) 13:34, 11 November 2015 (UTC)

 Endorsed This might be related to mw:Extension:SocialProfile, which already has some of these features? Perhaps this task could investigate deploying that extension more widely. cscott (talk) 18:24, 11 November 2015 (UTC)

Unlikely, the requests are more similar to mw:Extension:Contribution Scores and mw:Extension:UserDailyContribs. Nemo 09:58, 13 November 2015 (UTC)

 Oppose. Contributing to Wikimedia projects is not a game, and should not be presented as such. Points two and three are enough to reject this -- we want quality contributions, and yes, that includes removing content that does not belong. Quality cannot be measured by the number of bytes added or edits made. MER-C (talk) 16:10, 14 November 2015 (UTC)

 Endorsed wikidata game is very successful, micro-contributions may be a way forward for mobile. it is unclear that the powerusers want quality, or power. Slowking4 (talk) 04:57, 15 November 2015 (UTC)

 Endorsed Gamification is a good way to get new contributors. --Piotrus (talk) 06:47, 16 November 2015 (UTC)

Education Program interface changes

As an educator who uses the Education Program page, I'd like the following changes to happen:

1. Special:Students is pretty useless ([15]). It should be made sortable, but even more important, filterable: I want to use it to see only MY students. And all of them, not a batch of 50 or whatever is the locked in length of table on that page.
2. Special:MyCourses needs an archive, an option to auto-collapse student entries and to select the length of days one wants to display on the front page. For now it is sadly a page me and my students always skip, with a sigh as it is pretty useless. It is particularly problematic if one has several courses; I currently have four, and this is a mess, as some students show in 2+ course listings, the one I want is not usually at the top, etc. Also, the student activity should show their edits outside English Wikipedia (I have my students edit Korean Wikipedia, for example).
3. Student's list of articles (ex. at [16]) should support articles outside English Wikipedia; I have students edit articles on Korean Wikipedia and Wikivoyage, but we cannot create hyperlinks there.
4. I'd like to be able to sort students on that page into teams, probably with colors and names.
5. I'd like that page to be sortable (by article, student's name, team)
6. I'd like that page to have a place where you can add student's real name/student number. It's a pain when students register with nicknames, and I have to keep a separate list of who they are.
7. I'd like to have some sort of progress track for each article/student/group. Ex. students are required to submit an outline on the article's talk page, or make an edit, or ask for a review, or whatever. I'd like to be able to define those, with deadlines, for each course, and have checkboxes display next to each student/group/article entry.
8. That list should have a collapsed by expandable box for their recent edits (like on Special:MyCourses), and I'd like it to display the number of each student edits in the last week or so. --Piotrus (talk) 04:49, 12 November 2015 (UTC)

•  Endorsed LeoRomero (talk)
•  Oppose. Insufficient benefit for the core community, WMF specific. MER-C (talk) 16:06, 14 November 2015 (UTC)

SUL account merging

According to SUL § I have two or more accounts with different names. Can they be merged into one account?, SUL account merging is yet to be implemented. But I didn't find any truly helpful information regarding the actual progress of the implementation of such feature. I have five legacy (those with a tilde that are listed in my user page over ptwiki) and wonder when will the merging be finally available. Before the placing of tildes, I felt harassed in my home project. When arguing with a not-really-friendly sysop, he noticed the screen-name similarities and inquired me whether I was puppeteering and suggested to go to the "Newbie Café" (a page in our Community portal dedicated to novices). That given that I'm one of the (if not the) oldest editor (since 2004) still-active in my project. Fortunately, I was never harassed in votings about my then low edition count, but I had to place a disclaimer in my user-page on the issue. The disclaimer stills there, and I can't wait to erase it... --Usien6 (talk) 15:43, 13 November 2015 (UTC)

AFAIK there is already a tool for account merging which has several “bugs”, which means that more often than desired it makes the accounts to be merged totally unusable. They therefore hesitate to continue, and probably even consider to not use it at all. IIRC the reason for this problem is that the database of 15 years is too complex to safely merge accounts. You might want to get in contact with @DerHexer:, who has insight into SUL related issues and is probably willing to give a short update. —MisterSynergy (talk) 16:52, 13 November 2015 (UTC)

The tool cannot be used, a re-write is required. But Usien6 can confirm with each of these accounts on their userpages that all accounts are his own. Then I could manually rename them to Usien6 where he can merge them on his own. Cheers, —DerHexer (Talk) 17:18, 15 November 2015 (UTC)

Dear @MisterSynergy: Thank you for the update! Dear @DerHexer: Thank you for your stance, I'll be contacting you in your talk page soon... --Usien6 (talk) 16:21, 17 November 2015 (UTC)

•  Support, although I suppose this may be outside the expertise of Community Tech. This, that and the other (talk) 08:21, 17 November 2015 (UTC)

Mailman emails passwords in cleartext

Tracked in Phabricator:
Task T52864

Mailman, the GNU Mailing List Manager, emails passwords in plain text... This should be fixed ASAP. The Quixotic Potato (talk) 12:29, 14 November 2015 (UTC)

There's nothing here the Community Tech team can help with, unfortunately. MER-C (talk) 13:06, 16 November 2015 (UTC)

Multiple redirects in one time

See my idea. --Edgars2007 (talk) 07:19, 28 May 2015 (UTC)

FWIW, when I have to create many redirects on it.wiki, I just add a bunch of aliases on Wikidata and then wdsearch informs the users. --Nemo 18:39, 31 May 2015 (UTC)

Major overhaul to Special reports

For a variety of reasons many of the special reports have become useless and some projects have been forced to create their own custom reports such as database reports or through means of the WMFLabs/Toolserver. I recommend a complete overhaul be done to the way these reports are generated that would allow some role within a user community (like Admin or template editor) to be able to modify the code that drives these special pages. Some functionality I think would be useful to do should include:

1. The ability to hide reports from the list of those displayed if they aren't relevant to the project
2. Add new reports under some type of custom section
3. Be able to modify the criteria that is used to generate the reports.
4. Have more flexibility to expand the length of a report even if that is to break it into 1000-2500 article chunks across multiple pages.

Of course this is just a short list and more detailed requirements and analysis of the problem would be needed. Some things have already been suggested here as minor changes to individual reports or other utility changes but what is really needed is a complete overhaul of the way the Mediawiki system creates and handles reports. Reguyla (talk) 14:48, 26 August 2015 (UTC)

Most of the QueryPage special pages run very expensive queries on the database so it is not a good idea to let users on wiki modify them. But we should investigate ways to let the pages more flexible (i.e. options in the form). --Glaisher (talk) 17:16, 26 August 2015 (UTC)

Thanks that's good to know. I think I heard that about the queries and maybe as part of the investigation we could see if its possible to make some of them run with less resources. Its also possible some aren't needed at all and could just be eliminated completely or turned off. For example, Pages without language links is pretty irrelevant for Wikipedia now (although some Wiki's may use it) so maybe that could be an example of one we disable and don't run. Does anyone really use Dormant pages or Orphaned pages? My guess is probably not. Reguyla (talk) 17:33, 26 August 2015 (UTC)

•  Support at least for consideration. I think it is worth including this in stage 2. This, that and the other (talk) 08:24, 17 November 2015 (UTC)

Students Wiki knowledge tracking, for educators

Problem

Supervision of Wikipedia students' progress, in detail

Benefit

Educators / instructors, Wikipedia education, Wikimedia movement through evaluation statistics

Curently addressed

Personal notes / databases unlinked to user accounts

Solution

Start developing evaluation tools

--ManosHacker (talk) 11:51, 16 November 2015 (UTC)

Cookies for autoblocker

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Duplicate of #Improve MediaWiki's blocking tools. MER-C (talk) 11:51, 11 November 2015 (UTC)

---

Tracked in Phabricator:
Task T5233

This extends the autoblocker such that a cookie is placed when a user is blocked, and triggers the autoblocker when such a cookie is detected. This impedes shifting IPs (sometimes unintentionally) to evade blocks. MER-C (talk) 01:50, 8 June 2015 (UTC)

Isn't that way too easy to exploit? The Quixotic Potato (talk) 15:56, 16 July 2015 (UTC)

It's better than what we have now, which only triggers the autoblocker when the same IP address is used. MER-C (talk) 01:46, 20 July 2015 (UTC)

---

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.