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. 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 may submit 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

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)

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)

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)

Make PageCuration work on projects besides English Wikipedia

Tracked in Phabricator:
Task T50552

Section watchlists

Tracked in Phabricator:
Task T2738

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)

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)

Cross projects notifications

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).

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

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

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

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

global, shared gadget list users can pick from

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)

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)

+1 for global, centralized and configurable gadgets! Helder 16:32, 25 May 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)

Improve SVG rendering

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 [1] 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)

+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)

SVG Help Button

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)

+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)

Support for version branching for pages

Tracked in Phabricator:
Task T40795

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)

Reminders in notifications

Tracked in Phabricator:
Task T88781

See this one. --Edgars2007 (talk) 07:20, 28 May 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)

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

Gadget statistics

Tracked in Phabricator:
Task T21288

See also: Gadgets and mw:Extension:Gadgets/Roadmap.

Statistics on gadgets usage (number of users like for beta-functions). It is currently unclear, which old gadgets should not be maintained anymore. --AS (talk) 09:26, 30 May 2015 (UTC)

Yes we list the number of people using the beta features [2] so one would think this would not be too difficult. Doc James (talk · contribs · email) 10:40, 30 May 2015 (UTC)

I think, that beta features and gadgets are quite different story, but yes, it would be nice for developers to see, which gadgets are used more (are more popular), so they can be developed more. --Edgars2007 (talk) 07:27, 31 May 2015 (UTC)

I made a proposal (with wireframe sketch) at mw:Talk:Requests for comment/Redesign user preferences#Gadgets for a potential upgrade to the gadgets tab, which would include usage numbers (+other info).

The main hub of notes/links is mw:Extension:Gadgets/Roadmap. --Quiddity (WMF) (talk) 22:38, 1 June 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)

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)

Cookies for autoblocker

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)

Increase edit summary and log reason length

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)

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)

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)

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)

Develop tools to convert Flow and LQT pages to normal talkpages

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 the talk page. Rogol Domedonfors (talk) 06:25, 26 July 2015 (UTC)

Develop tools to convert Flow and LQT pages to normal talkpages

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)

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)

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)

Linksearch per namespace

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 The Quixotic Potato (talk) 01:39, 11 November 2015 (UTC)

Watchlists

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)

Increase edit summary and log reason length

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)

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)

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)

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)

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)

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)

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)

Add a Category watchlist

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)

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)
• Only 1 endorsement is needed for this phase of the survey. The voting phase will happen later. Further discussion is welcome though. Ryan Kaldari (WMF) (talk) 17:29, 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)

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)

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)

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)

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 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 required work 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 File:Fluoxetine 2.png TODO

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

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 also support selecting bugs, mastering libRSVG code and software release.

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)

Discussion

• What are the GNOME Bugzilla tickets for the problems you want fixed e.g. [3][4][5]? 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)

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)

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)

Make it easy to build infoboxes that display information from wikidata

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)

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)

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)

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)

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)

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)

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)

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)

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)

Cross-wiki watchlist

Tracked in Phabricator:
Task T5525

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)

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)

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)

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)

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)

Visual Editor adapted for Wikisource

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 wich 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

Searchable contributions

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)

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)

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)

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 Wikipedia:Metadata gadget for all readers by default, 2) develop a complimentary 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)

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)

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)

Wikidata support for Wiktionary

ENable wikidata support for interwiki (phase 1) as soon as possible at least for other than main nanespace. 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)

OTRS permissions checker

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)

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)

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)
•  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)

•  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)

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)

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)

Enchance 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);

Opinions

•  Endorsed --Yann (talk) 16:37, 10 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)

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)

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)

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)

Special:NewPagesFeed

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)

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)

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)

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)

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)

•  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)

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)

Central Global Repository for Templates, Lua modules, and Gadgets

Tracked in Phabricator:
Task T41610

Tracked in Phabricator:
Task T1238

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. 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)

Halve edit conflicts

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)

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)

Line 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 line, like there is in GitHub. I mean, a tool that, given a line (or a set of lines), points out the last edition (or, perhaps, all the editions) in which this line showed up in the differential. Sometimes it wouldn't work due to line merges or 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)
• 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)

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)

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

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)