Community Wishlist Survey 2019/Archive

This page is an archive for Community Wishlist Survey 2019 proposals that won't go on to the voting phase. Proposals may be archived for various reasons, including: the proposal is too vague, the idea is technically unfeasible, the problem has already been solved, an existing product team is already working on it, the proposal is a social/community change rather than a technical one, or the proposal is asking to remove features that WMF product teams have built.

Only members of the Community Tech or Technical Collaboration teams should move proposals into or out of the Archive. If your proposal has been archived and there's still time before the voting phase starts, please continue the discussion on your proposal! You may be able to fix a problem with the proposal, and get it back in the survey. Once the voting phase starts on November 16, 2018, we can't move any proposals out of the Archive.


Create and maintain a structured process for new editor recruitment and editor retention

  Withdrawn by proposer (too many proposals)

  • Problem:

On most WMF projects, editor activity levels have remained stagnant (or have even declined) for at least several years. The editor base is also still composed of pretty much the same mix of people as it was ten years ago (with a demographic bias towards white men in the "global North"). Maybe this is fine, or maybe it shouldn't be.

Currently the editor recruitment process consists largely of the "Edit" and "Create account" buttons, both of which are out of sight and out of mind for the typical reader finding out what happened today, settling an argument with someone, or researching their school project. As for editathons, I'll quote two articles in the English Wikipedia's Signpost:

"[...] in a nutshell, the story of all my outreach in Namibia. Operation successful, patient dead: A well-run workshop resulted in exactly zero new editors, zero subsequent edits, zero subsequent picture uploads."
"[...] they are a useful institution. However, they don't generate many new persistent editors. They mostly attract attendance by promising new biographies, and newbies arrive expecting to make articles about their friends."

To me, this immediately raises two issues (although I'm not going to pretend that I've done in-depth research, I hope these are fairly plausible conclusions):[1]

  • Most people don't really know what Wikipedia editors actually do or what they write about.
  • Most people don't really think about editing Wikipedia regularly, or consider that they in particular should become a Wikipedia editor.

If almost no one is actually aware (or made aware) that they can fix typos or write about their favourite musician's back catalogue or participate in the latest culture war or share their vacation pictures, then the obvious conclusion is that no one will actually come to edit. Songs that millions of people have listened to, for instance,[2] might not even get their own Wikipedia article (in any language). Just one of those millions of people would have been enough for those songs to get their own article.

I think it would be beneficial to all Wikimedia communities for the WMF to have some sort of process of recruiting editors extending outside the existing Wikimedia websites and outside the people who are already in Wikimedia movement.[3]

  • Who would benefit: Wikimedia projects, broadly construed; new editors
  • Proposed solution:

I can't propose one solution to this. However, perhaps at least raising awareness on other parts of the internet (or other parts the real world) would help. Advertising might be beneficial, and it was the first thing I thought of that might help. It might be more convincing than "anyone can edit" at telling people that they in particular should try out editing and/or edit regularly (i.e. "why should I edit? anyone else can already edit"). Perhaps specific groups of people[4] could be asked to, say, spend their evening commute fixing some typos or adding information to Wikidata items; or some large billboard could have some information about Wikipedia or the less-well-known projects.[5] In particular, targeting specific groups might help with finding groups of people who are likely to come back after making their first edit. Other avenues might include submitting op-eds to medium-importance newspapers, or having an interesting Twitter account.[6] Furthermore, it might also be beneficial to explore new on-wiki ways of getting people to edit regularly, perhaps by sending a notification if new users haven't edited in a while,[7] or by sending suggestions of what to try to new and currently active editors.[8]

Of course, editing Wikimedia projects (possibly excepting uploading to Commons) is never going to have obvious mass appeal, given that most people haven't had to cite sources in years. But there are always going to be people who just haven't found out that they want to edit yet.

  1. These apply to Wikipedia more than they do to the other projects, since there is much lower awareness among the general public that the other projects actually exist.
  2. Examples: "Lovely", by Billie Eilish ft. Khalid; "Amigos Con Derechos", by Reik and Maluma; "Peligrosa", by J. Balvin, Wisin and Yandel. At time of writing, none of these have existing articles on any Wikipedia or any Wikidata items, but each has more than 100 million YouTube views and more than 40 million Spotify plays.
  3. To me, the WMF seems to leave the actual content creation to chance most of the time (correct me if I'm wrong). I don't really blame them, since it is clearly working to some extent, but maybe a more active role would be better.
  4. For example: librarians; people interested in specific topics like TV series or 19th-century philosophers; specific groups of university students.
  5. Specific things, that aren't platitudes like "Imagine a world where knowledge is free".
  6. Examples: Mashable – "Merriam-Webster's Twitter is the political shade queen", USA Today – "Sorry McDonald’s, Wendy’s Twitter account is winning the war on beef". I'm not saying that @wikipedia should be engaging in esoteric fights, but maybe something other than a stream of random facts that are mostly mildly interesting but irrelevant to popular culture would boost its popularity.
  7. Facebook does this by notifying users of their friends' activity daily, and it is very annoying, so maybe not every day and stop sending notifications after a while if the user doesn't come back.
  8. Emphasis on "new", since people who have been here for 15 years are probably not going to like those being automatically turned on.
  • More comments: If something like this is indeed pursued, I would hope that the process is transparent to editors (at least on the English Wikipedia, there are sometimes complaints about how the developers didn't bother to tell anyone that they were going to do something). For example, if notifications are to be sent to new users asking them to come back and edit some more, the affected projects' communities could be informed of what the notification looks like and could have a consensus-based final approval on its text.
  • Phabricator tickets:

Discussion

This proposal in its present form is too vague and therefore not actionable. We'll have to archive it unless some concrete technical things to do are added to it. On another hand, we have a whole team - Growth - that work on this full time, so it might be unnecessary at all. Max Semenik (talk) 21:28, 29 October 2018 (UTC)

  • Yes, we have a new team, Growth, that is working specifically on new editor recruitment and retention, so it would be better to convey these ideas to that team rather than having the Community Tech team work on it as a wishlist item. Ryan Kaldari (WMF) (talk) 00:38, 30 October 2018 (UTC)
    @Ryan Kaldari (WMF) and MaxSem: Okay. I'm actually planning to post two other proposals (and have already posted two), so perhaps if no one else decides to pick up the specific concrete proposals (targeted advertising, increased notifications to new users) then I'll abandon it by the end of the proposal period. Jc86035 (talk) 06:00, 30 October 2018 (UTC)

Add "divers" to preferences - user profile - How do you prefer to be described

 N Only active registered users can create proposals. Please find someone to adopt your proposal.

  • Problem: Germany will add the third gender option by the end of the year, about a dozen nations in the world already recognize more than two genders
  • Who would benefit: everyone who wants to be addressed in another way as he / she / neutral
  • Proposed solution: Add another radio button to the preferences page
  • More comments:
  • Phabricator tickets:

Discussion

For some previous discussion, also see phab:T61643 --AKlapper (WMF) (talk) 13:04, 30 October 2018 (UTC)

Reinstate all Chinese Wikipedia's CheckUsers' permissions

 N Proposes a social/community policy change rather than a technical feature

  • Problem: Since Chinese Wikipedia's CheckUsers had been discharged this March (2018), CheckUser requests could not be dealt in time. From my perspective and my experience of w:zh:WP:RFCUHAM, I have found out that tthough the number of requests has decreased, it can be seen from the content of the request that for the administratora, the speed of accurately handling all the damage involving socket puppets is restricted.
  • Who would benefit: All Chinese Wikipedia community members
  • Proposed solution: Reinstate all Chinese Wikipedia's CheckUsers' permissions.
  • Phabricator tickets: Currently N/A, please consult the Wikimedia Foundation for more information.
  • Proposer: Mend My Way 11:25, 30 October 2018 (UTC)

Discussion

@WQL: Could you please provide more content what "discharged in March 2018" means exactly? Any links to any changes, discussion, announcements around March 2018? Thanks! --AKlapper (WMF) (talk) 12:40, 30 October 2018 (UTC)


@AKlapper (WMF): https://meta.wikimedia.org/wiki/Special:Log?type=rights&user=WMFOffice&wpdate=2018-03-31 --Krenair (talkcontribs) 12:48, 30 October 2018 (UTC)
Anyway this appears to be completely nontechnical. --Krenair (talkcontribs) 12:49, 30 October 2018 (UTC)
@AKlapper (WMF): Wikipedia talk:用戶查核#Notification of Wikimedia Foundation actions regarding local CheckUser. — regards, Revi 12:50, 30 October 2018 (UTC)
Ah, thanks! Indeed, this sounds like a configuration setting which does not require any code to be written. So it might be out of scope for the Community Wishlist Survey. --AKlapper (WMF) (talk) 12:53, 30 October 2018 (UTC)
More of user permission that is revoked. I agree that this is outside of the scope for Community Wishlist Survey since it does not relate to Community Tech. — regards, Revi 14:43, 30 October 2018 (UTC)
Yeah it's not even a configuration setting AFAIK. The user group still exists on zhwiki but it's empty. Nothing technical to do, this seems all political/legal. --Krenair (talkcontribs) 14:56, 30 October 2018 (UTC)
For yes, that is a political call rather than a technical call.--1233 | Questions?| This message is left by him at 16:34, 30 October 2018 (UTC)

This is indeed, as noted above, outside of this survey's scope as it's a non-technical change. Sorry about that. -- NKohli (WMF) (talk) 18:43, 30 October 2018 (UTC)

Stack trace of errors (error handling) by parser functions

 N Only active registered users can create proposals. Please find someone to adopt your proposal.

  • Problem: When parser function (ex. expr) gets invalid input, it generates error message which sometimes isn't helpful:

Expression error: Unexpected < operator ({{#expr:<span class="error">Error of the Template</span>}}), especially when editing templates which calls other templates (ex. Inflation) and use #iferror with custom error messages (or with incorrect pairs of brackets {}).

  • Who would benefit: Wikipedia editors, Wikipedia template editors
  • Proposed solution: Chain (stack trace) errors (or invalid input):

Expression error: Unexpected < operator: Error of the Template ({{#expr:<span class="error">Error of the Template</span>}}: <span class="error">Error of the Template</span>) on article page, or only in preview

  • More comments:
  • Phabricator tickets:

Discussion

Option to insert cite in VE without ref tags

 N Only active registered users can create proposals. Please find someone to adopt your proposal.

  • Problem: When inserting ex. external links by using Cite (automatic) in Visual Editor, there's no way (as far as I know) to remove the ref tags (switch to code editor is needed)
  • Who would benefit: Wikipedia editors
  • Proposed solution: Option in Cite dialog to bypass inserting the ref tags, or option in VE to remove/add ref tags
  • More comments:
  • Phabricator tickets:

Discussion

The solution might be simple checkbox - when chcecked, citation will be S REFERENCE, WHEN UNCHECKED, as literature. JAn Dudík (talk) 19:10, 30 October 2018 (UTC)

Keep inclusion history

  Withdrawn by proposer (too many proposals)

  • Problem: Many times we need to know not only where some page is included, but also where it was.
  • Who would benefit: Looks like any wiki editor, patroller and admin.
  • Proposed solution: Keeping the inclusion history for pages. Category, template, module, image mostly. Category means including and excluding pages to it, and not the opposite. Each entry will show some inclusion or exclusion the page in some particular page.
  • More comments: It can take a lot of space, so it can be possible to keep the history fot templates, and only them, for the last month only.
  • Phabricator tickets: None.

Discussion

This proposal, as well as the similar one that requests the same for categories, misses a real problem statement. What is the actual problem you're trying to solve here? Why is it important? How do you want to surface this information? Max Semenik (talk) 21:33, 29 October 2018 (UTC)

I propose it just because there were hundreds of times I was needed this information. Here are a couple of examples. Last week on Commons there was a deletion request for an image. It was not included in any article in wikipedias, because after the deletion request some user removed it from the article, with summary "going to be deleted". So, the users that discussed and decided if the image should be deleted, did not have the information for which article it was uploaded. Another example. I'm editing a template. As a result, it should stop to add some category to a group of articles. I need to check if it removed from exactly the same partition of articles that is needed to, not more and not less. Another example. Some bot removed unintentionally some template from a lot of pages. I need to have the list of them, so I can revert this easily, even if the pages were edited by other users after this, and even a year later. Hope it helps. Thank you. IKhitron (talk) 21:52, 29 October 2018 (UTC)
I think it would be beneficial (and be advantageous due to the vote-based selection process) to merge the closely-related proposals together if they all target the same problem. Jc86035 (talk) 15:56, 30 October 2018 (UTC)
I do not understand, Jc86035, there is another proposal with the same target, that I do not aware about? IKhitron (talk) 16:05, 30 October 2018 (UTC)
As in, if Community Wishlist Survey 2019/Miscellaneous/Create a magic word to check category inclusion for previous page version would be solving the same problem, then I think it would help to merge it into this one. (In any case, each user can only own three proposals, so you would have to abandon one of them at some point.) Jc86035 (talk) 16:09, 30 October 2018 (UTC)
I see. Well, it should solve absolutely different problem, there is no connection between these two proposals at all. About three proposals, I know, and I'll remove one of course. IKhitron (talk) 16:18, 30 October 2018 (UTC)
Hey IKhitron, unfortunately this proposal is not suitable for the same reasons as the category one: it's a big feature with a lot of hardware requirements. Our team just wouldn't be able to work on this. MaxSem (WMF) (talk) 22:24, 14 November 2018 (UTC)

Make dashboard completely translatable

  Withdrawn by proposer (too many proposals)

  • Problem: Currently some of the things in the dashboard can only be in English. WMF can't handle a one-language-software, but we are encouraging to use it everywhere, without solving first this problem.
  • Who would benefit: People who don't speak English
  • Proposed solution: Make everything translatable via Translatewiki
  • More comments:

Discussion

Make Pagebanner work and deploy it elsewhere

  Withdrawn by proposer (too many proposals)

  • Problem: Pagebanner is a solution to put a big image in the top of the pages. Wikivoyage uses it and some Wikipedias are using it for different purpouses. Currently, the image origin button is not working, making it very difficult to design pages correctly. Also, this feature is not deployed in most Wikipedias, and it could be interesting to have it elsewhere, as it gives a different look to pages (i.e. help or wikiproject pages can have this distinction with Pagebanner).
  • Who would benefit: Readers and wikis with Pagebanner installed.
  • Proposed solution: Solving the origin problem and deploying it.
  • More comments:

Discussion

  • What is the image origin button that does not work? · · · Peter (Southwood) (talk): 12:39, 30 October 2018 (UTC)
@Pbsouthwood: It's explained in task T191689

Unbreak the book creator

  Withdrawn by proposer (too many proposals)

  • Problem: The book creator has been broken for more than a year. It doesn't seem to be a priority to solve it, but actually is a very interesting feature for educators.
  • Who would benefit: Readers
  • Proposed solution: Hurry up in the current effort to solve it, it should be working one year before.
  • More comments:
  • Phabricator tickets:

Discussion

@Theklan: Please describe what exactly "broken" means. Do you refer to saving a book in PDF format? Or something else? --AKlapper (WMF) (talk) 13:02, 30 October 2018 (UTC)

See here. --NaBUru38 (talk) 16:10, 30 October 2018 (UTC)

Make possible to link to an existing Wikidata item with no interwikis

  Withdrawn by proposer (too many proposals)

  • Problem: When creating an article about something that doesn't exist in another language but you can find in Wikidata, there's not a way to link from Wikipedia to Wikidata directly.
  • Who would benefit: Wikipedia editors
  • Proposed solution: Add it as an option in the same place that the interwiki linking button is
  • More comments:
  • Phabricator tickets:

Discussion

Wikidata translatable SVGs

  Withdrawn by proposer (too many proposals)

  • Problem: Translating SVGs is currently very difficult, as the best ones are not real text svgs, but rendered shapes. But we could make a better option if we could translate SVGs directly using Wikidata items. Many things should still be translated by hand, but think on anatomy, astronomy or chemistry schemas automatically translated using Wikidata labels.
  • Who would benefit: Small Wikipedias
  • Proposed solution: Giving the possibility to label svgs by Q instead of directly writing it.
  • More comments:
  • Phabricator tickets:

Discussion

  • I think Commons's tabular data pages might be better for this, since Wikidata items and lexemes aren't really suited to translation of long phrases. Jc86035 (talk) 16:19, 30 October 2018 (UTC)
@Jc86035: Thanks for the insight. I have to delete this proposal, as 3 is the limit. Would you like to adopt it? -Theklan (talk) 20:12, 30 October 2018 (UTC)
@Theklan: Sorry, I can't because I already have three active proposals. Jc86035 (talk) 05:45, 31 October 2018 (UTC)

Require Editors to Have Accounts and Login Before Editing

 N Proposes a social rather than a technical change.

  • Problem: Wikipedia is plagued by vandalism from users who don’t bother to create accounts and just edit using their IP address. This makes pointless and frustrating work for experienced editors who constantly have to revert such edits and makes it difficult to determine who is responsible for edits since IP addresses can be shared.
  • Who would benefit: Everyone who is serious about using and editing Wikipedia. It would cut down on the possibility of new users to see nonsense posted on some page, on the workload of people watching pages, and on admins who need to hold vandals responsible.
  • Proposed solution: Last month (September 2018) I participated in the Semantics 2018 conference on the Semantic Web in Vienna. One of the most interesting talks was a keynote from Elena Simperl a professor of computer science at the University of Southampton titled: One does not simply crowdsource the Semantic Web: 10 years with people, URIs, graphs and incentives. You can find the PDF of her talk below, I recommend it, it was full of good real world data and examples: Semantics 2018 Crowdsourcing Keynote The absolute number one take away point she had was very simple: the most disruptive and non-constructive contributions to crowd sourced projects (of which of course Wikipedia is one of the seminal examples) come from users who do not bother to set up an account. This is something that’s amazed me ever since I joined Wikipedia several years ago. It may have made sense when Wikipedia was new and the goal was just to attract as many people as possible but IMO there is no doubt that if we collected data on the balance of constructive vs disruptive edits from IP users the balance would be exponentially greater that such users do far more harm than good. It doesn’t take long to set up an account. You need to give an email, user ID, and password. If you can’t be bothered to do that you clearly don’t care much about editing. People are now used to the concept of logging into systems. This would be a trivial change, it wouldn’t take any significant work from the over worked technical people and IMO it would save endless hours of reverting vandalism from IP users.
  • More comments:
  • Phabricator tickets:

Archived

Hi, unfortunately I had to decline this proposal as it describes a policy/social issue while this wishlist is for technical issues only. If you want to make this change happen, you need to get consensus to disable anonymous editing from affected communities. Once such consensus has been achieved, making a technical change would be trivial, it wouldn't need to be on the wishlist. Thanks for participating in our survey. MaxSem (WMF) (talk) 21:13, 30 October 2018 (UTC)

Provenance

 N Proposes a social/community policy change rather than a technical feature

  • Problem: This item used to belong to...? where did it come from? etc.
  • Who would benefit: Useful addition to infoboxes to help sort out chronology of owners in works of arts, collector's items, any artifact ++
  • Proposed solution: Would it be possible to include the value "provenance" or former owner to be used on works of art, books, items etc.
  • More comments:
  • Phabricator tickets:

Discussion

@Orf3us: Do you mean that this data (owned by (P127)) should be shown in infoboxes, or that a new Wikidata property should be created? Jc86035 (talk) 15:14, 30 October 2018 (UTC)

Thank you for asking. I think I mean both. Orphée (talk) 15:47, 30 October 2018 (UTC)
@Orf3us: Usually I would think that all of the ownership data is in statements which use owned by (P127). If d:Q23908#P127 is the sort of data you're referring to I don't think new properties should be needed, and it would be out of the scope of Community Tech anyway, since anyone can propose new Wikidata properties at d:Wikidata:Property proposal. Also, unless it is currently technically impossible to show that data on your wiki , it's probably out of the scope of Community Tech to edit a single infobox. (I am unfamiliar with Wikidata infoboxes, because they are little used on the English Wikipedia.) Jc86035 (talk) 16:44, 30 October 2018 (UTC)
Thanks anyway for your answer and solution. Orphée (talk) 18:39, 30 October 2018 (UTC)
Thanks for your proposal, Orf3us. Jc86035 is correct that this is not a technical change. Proposing new Wikidata properties and changes to infoboxes can be done on Wikidata. It is a community-controlled change rather than a technical one. -- NKohli (WMF) (talk) 21:27, 30 October 2018 (UTC)

Centralized templates and modules

 N Outside the scope of Community Tech

  • Problem: We have a proliferation of Templates and Modules which are copied from one WMF wiki to another, without the ability to maintain them centrally, because all Templates and Modules are specific to one wiki. This puts a huge burden on editors of small wikis when we try to copy existing Templates and Modules from larger wikis.

    Commons already stores images centrally for other WMF wikis to use. If we can have the same behaviour for Templates and Modules, this will save a lot of time for everyone. The central repository of Templates and Modules can be hosted on either Commons or Wikidata - either is fine.

    This problem was discussed extensively at the Wikidata and infoboxes panel at Wikimania 2017 and there is strong consensus that a central repository of Templates and Modules will solve this problem.

  • Who would benefit: Small wikis and cross-wiki editors; Template and Module curators.
  • Proposed solution: When someone tries to transclude a template or invoke a module which doesn't exist locally, but there is an equivalent module or template in the central repository (say, Commons), transclude that template or module instead.

    This is basically the same behaviour as pulling media from Commons, but for templates and modules.

  • More comments:
  • Proposer: Deryck C. 12:30, 30 October 2018 (UTC)

Discussion

Thanks Deryck Chan! I found this problem when installing the fully automated template system on some small Wikipedias. They don't have anything, not even a coordinates system there. Modules could be better mantained with this system, and there's always the possibility to fork and i18n. -Theklan (talk) 12:34, 30 October 2018 (UTC)
  • Not sure that the central repository of templates and modules should be commons as there are a lot of templates and modules on there that are commons specific. If it was to be used as the central repository, the shared templates and modules should be stored in separate namespaces, for example sharedtemplate: and sharedmodule: rather than within template: and module: -- WOSlinker (talk) 13:46, 30 October 2018 (UTC)
    • @WOSlinker: That shouldn't be a problem: if a local Template or Module exists, then the local Template or Module will be loaded instead. It hasn't been a problem that certain files are Commons-specific. Alternatively, we can put the central repository for Templates and Modules on Wikidata. Deryck C. 14:05, 30 October 2018 (UTC)
  • I think that this proposal has an important social issue: Who is going to exercise editorial control on the modules and templates? The community that hosts the repository or the communities that use it? An edit to the repository might break pages on another project and that will lead to conflict if there is no regulatory process. If people apply a lot of local opt outs to avoid this problem many benefits of the central repository will be negated. Jo-Jo Eumerus (talk, contributions) 15:22, 30 October 2018 (UTC)
    Presumably the new wiki would have its own administrators and policies? I think it would be easiest to think about it as if it were Wikidata but for templates and modules (the analogy being that Wikidata content is also transcluded to multiple wikis). Jc86035 (talk) 15:28, 30 October 2018 (UTC)
    And do the communities that use the repository get a say in how it drafts its policies and appoints its administrators? The issue isn't so much how to organize the repository, but how to organize the repository so that it forestalls any "decisions in the repository affect content elsewhere" problems. Incorrect data on Wikidata have caused problems on other projects where it has been transcluded, since editors on the other projects do not always know how to fix the incorrect data or where the problem lies, and I think we ought to avoid the same problems reoccurring on a code repository. Jo-Jo Eumerus (talk, contributions) 15:34, 30 October 2018 (UTC)
    Repository doesn't mean "mandatory". A repository of commons templates (coordinates, collapsible list...) can be there and if a local community wants changes, they make them locally, not in the repository. -Theklan (talk) 20:14, 30 October 2018 (UTC)

Der, Legoktm may be able to tell you what is the status of this, I think it was a part of their work. Gryllida 22:56, 30 October 2018 (UTC)

  • Unfortunately this is one of those monolithic projects that's outside of Community Tech's scope. Furthermore this was a top 10 wish in the 2015 survey (before we refined our scope), so there's no need to re-propose. Rest assured this is known wish -- everybody wants it, but our small team isn't capable of delivering it. As such I'm moving it to the archives, but thank you for the taking the initiative to propose it again :) Please feel free to continue with the discussion. MusikAnimal (WMF) (talk) 23:00, 30 October 2018 (UTC)
    • Der & MusikAnimal (WMF): If community tech doesn't have enough resources for such project, we should think how to re-scope it/break it down to smaller and feasible steps. For example, converting top 5 used templates (across all wikis) to Lua extension (suggested name: wmf-common-templates extension). eranroz (talk) 02:28, 31 October 2018 (UTC)
      • Not a bad idea! There was talk of doing something similar for common gadgets as a workaround to global gadgets. I don't recall what happened with that. Anyway, if we're just talking about setting up an extension to contain global modules (probably not also templates), and not implementing these modules, then this might be feasible for us. If you want to create a new proposal for it, you should :) MusikAnimal (WMF) (talk) 03:33, 31 October 2018 (UTC)

Extend "in the news" and "on this day" features to more languages

  Withdrawn by proposer (too many proposals)

  • Problem: Currently this features are only visible in some languages, but our missions should be having it in as most languages as possible.
  • Who would benefit: Wikimedia users whose mobile is not configured in English or another big language
  • Proposed solution: Extending the "in the news" and "on this day" features to the main 50 Wikipedias.
  • More comments:
  • Phabricator tickets:

Discussion

@Theklan: Could you please clarify what is technically blocking you from setting up something like https://en.wikipedia.org/wiki/Template:In_the_news (if that is what you refer to?) on your preferred wiki? Thanks! --AKlapper (WMF) (talk) 13:08, 30 October 2018 (UTC)

Any community that wants this, can already do this. Just make your own mobile compatible template for the mainpage of your wiki and done. For the apps, you need to setup the 'featured feeds', like mw:Extension:FeaturedFeeds and mw:Extension:FeaturedFeeds/WMF_deployment. Are you saying that configuration is too hard and you want the team to do it for the wikis ? —TheDJ (talkcontribs) 14:20, 30 October 2018 (UTC)

One of problems should be, taht some wikis haven't articl of day but article of week/month. JAn Dudík (talk) 19:37, 30 October 2018 (UTC)

Allow viewing of own deleted contributions on Special:DeletedContibutions

 N Too problematic from a legal point of view

  • Problem: Administrators can use Special:DeletedContributions to search for user contributions that have been deleted before. However, most users gain many deleted contribs over time, maybe by patrolling new pages, or by doing simple mistakes. Reviewing these revisions would make many things easier, especially for newbies:
    • After a sysop deleted your work, you can review what you did wrong to understand his concerns.
    • You can comprehend your own wiki-history even years later and do some statistics.
    • Really problematic things are hidden by oversight anyway.
  • Who would benefit: All non-admins with interest in their own on-wiki history of some sort, as mentioned above.
  • Proposed solution: Introducing a mydeletedhistory permission allowing to view the history of own deleted contributions, but not their content, as this can be problematic (copyright, privacy, offending edits, private information store). By default, this permission could be assigned to the autoconfirmed group.
  • More comments:

Discussion

I like this idea, it would be very useful at Wikinews to allow users to browse their deleted submissions and corresponding reviewer feedback. 1) However this takes many clicks to view for a sysop now, I would suggest to write an interface where people can view the old page contents with one click. 2) Also I would maybe suggest to make it limited to a particular user right because often people could abuse this feature to re-create deleted pages which were highly promotional. Gryllida 22:44, 30 October 2018 (UTC)

Archived

Unfortunately, this is a no-go for legal reasons: we're legally not permitted to store publicly certain kinds of content, even if "publicly" means "whomever has password to a certain non-privileged account". Regardless, thanks for participating in our survey! MaxSem (WMF) (talk) 22:40, 31 October 2018 (UTC)

@MaxSem (WMF): I have a few problems with this assesment:
  • This proposal is about introducing permissions like that. This part isn't legally problematic per se. Assigning them to appropiate groups is a second part. Particularly, this isn't targeted at making own deleted content visible, but only own log entries of this content. There might be a misunderstanding here regarding the readability of deleted content, for further information please consult the linked task on Phabricator.
  • Has this particular suggestion been legally assesed before? I wasn't able to find any record of this idea on Phabricator. If yes, please provide additional information.
I think it would be a pity if this proposal is archived before it's investigated whether it's really that problematic as it may seem. --MGChecker (talk) 22:57, 31 October 2018 (UTC)
Yes, we ran this past our legal team. MaxSem (WMF) (talk) 23:05, 31 October 2018 (UTC)

Vote for your admins

 N Proposes a policy change rather than a technical feature

  • Problem: Users often disagree about what is a good admin, and why they (you) should not support a specific admin. At various projects this has been solved (or sort of solved) in various ways, some vote their admins in and out without much rules, while other use fixed terms and extremely elaborate rules. No rules makes it easy to get rid of a non-functional admin, but it can be very scary to be an admin without rules. Fixed terms should on the other hand lead to rotation of admins, but often it does not. It also lead to rather harsh and unfriendly admins when they are not up for reelection – sorry for that admins! :)
  • Who would benefit: All users would benefit from a more representative admin group, where it is easier to vote admins in and out, at any time. This could stop the continuous rant about admins protecting other admins, as it would be easy to withdraw a vote for a specific admin. It would also be better for the admins themselves to know more about their own standing in the community, as they would instantly know if they have support for their actions.
  • Proposed solution: Create a special page where the admins, or any user group that needs clear support for their actions can be listed, and let a user "vote" for their admins by placing a tick mark by the admins name. Let the user give one vote in total, but spread it evenly on each checked admin. It should be possible to sort the admins on their total weights, and then let the bureaucrats remove the admins that does not get above a certain threshold. This is nearly the same as a w:borda count, and it scales quite well as the project community grows and shrinks.
  • More comments:
    • The threshold can be calculated as a fraction of the overall edit activity on the project.
    • Bureaucrats should be given a notification when an admin drops below the threshold.
    • There should be a visible note on the admins user page saying how they score.
    • It is tempting to include some measure of the admins activity themselves, but that would be out of context.
    • It should probably be possible to propose yourself as an admin candidate, given some limits, or ask the bureaucrat to ad someone.
  • Phabricator tickets:
  • Proposer: — Jeblad 20:47, 31 October 2018 (UTC)

Discussion

Unfortunately, I had to decline this proposal as it proposes a wiki policy change first and foremost, and this survey is a wrong venue to do that. We won't be able to work on technical aspects of this proposal until there's a policy in place. Thanks for participating in our survey. MaxSem (WMF) (talk) 22:46, 31 October 2018 (UTC)

I have described a special page that a project may choose to use, I'm not even sure how it is possible to read it any other way? Using a tool like the special page could imply a policy change within a project, creating a tool does not. — Jeblad 23:27, 31 October 2018 (UTC)

Vote for undo action

 N Proposes a policy change rather than a technical feature

  • Problem: Someone disagrees, and something is done that leads to an unpopular or outright faulty action. Most users have been there. And often (but not always) one part is an admin. The war-like situation is not easy to resolve for anyone, and we need some kind of tool that is reasonably fast and efficient. We need an easy way to vote for an undo action.
  • Who would benefit: Users in general could request a vote over an undo action, but it would be a help for admins in particular as it takes a problem (the do-action) and force it into another process (the undo-action).
  • Proposed solution: Assume something is done, like an edit war, and an admin tries to resolve the problem. To do so one of the users are blocked, and unfortunately the wrong user in one or another perspective. The admin disagree and the whole thing starts to turn into a rage war. That is not good at all, for any of the parties. Now assume the blocked user can still request a vote over the do-action (the blocking) in effect requesting a vote over a proposed undo-action. This vote request can be logged and shown as outstanding at some central page (like the signpost). It is open for 24 hours, and if the outcome is accepted then it is automatically done. If it is rejected it simply goes away by itself. The default action would be to reject, and votes would be given weights according to the users groups. Voting would be anonymous, but you would see your previous cast vote. Involved users (their IP) would be blocked from voting.
  • More comments:
    • Bureaucrats should be able to close a vote process unless they are involved in the action somehow.
    • The vote process should only be started by autoconfirmed users, possibly also only involved users, or bureaucrats.
    • It is not easy to implement simple undo-actions for all possible do-actions.
    • Involved users could be collected from page revision history, etc.
    • Starting the vote-process can also be used as an implicit request to hold the do-action for the duration of the process, ie giving a cool off for 24 hours.
    • It is important that the vote-process use a drop-through model, where no votes imply a reject.
  • Phabricator tickets:
  • Proposer: — Jeblad 22:58, 31 October 2018 (UTC)

Discussion

Sorry, I'm archiving this proposal because our survey is the wrong venue to propose policy changes and we're not going to work on technical measures that don't already have policy support on the wikis. Thanks for participating in our survey. MaxSem (WMF) (talk) 23:27, 31 October 2018 (UTC)

Again, I have described a special page that a project may choose to use, I'm not even sure how it is possible to read it any other way? Using a tool like the special page could imply a policy change within a project, creating a tool does not. — Jeblad 23:29, 31 October 2018 (UTC)

Show top ranked articles for a category

  Withdrawn by proposer

  • Problem: The closest we have to a "news section" is a portal page, but it is often stale with outdated information. What would be very nice is to show the currently active articles, that is top ranked pages for a given category. Such a page would be like a news section in a news paper, and could answer the question "what is trending within this field right now".
  • Who would benefit: The editors would see what is most active within their field of expertise, and the readers could use Wikipedia like a newspaper.
  • Proposed solution: The easiest solution is probably to make the top list from WikiStats2 available at the individual wikis as JSON, like this one, and leave the implementation to some Lua hackers. A slightly better (but also more involved solution) would be to create a special page like the w:Special:NearBy, but for w:Special:Category/Norway (or perhaps w:Special:Portal/Norway) instead. It would be necessary to include a lot more content than at the nearby page, more like the extracts used in the mobile interface.
  • More comments:
    • Nearly every hard problem for this is solved except making the data available for reuse at the individual wikis.
    • The (special) page should be able to show an overall top list for the main page, and separate top lists for categories.
    • It could be interesting to use a parser function instead, and embed the generated content on portal pages.
  • Phabricator tickets:
  • Proposer: — Jeblad 21:49, 31 October 2018 (UTC)

Discussion

Automatisches Überspringen von Zurücksetzungen eigener versehentlicher Zurücksetzungen beim durchblättern der Versionsgeschichte

  Withdrawn by proposer

  • Problem: Gelegentlich kommt es vor, das man statt des Danke-Buttons anzuklicken eine Bearbeitung revetiert oder anderweitig versehentlich auf den Revert-Button klickt. Diese Rücksetzungen blähen die Versionsgeschichte auf und sind beim durchblättern der Versionsgeschichte störend.
  • Who would benefit: Jeder der sich die Versionsgeschichte anschaut und/oder durchblättert.
  • Proposed solution: Benutzer sollten die Möglichkeit haben derartige eigene unbeabsichtigte Doppel-Zurücksetzungen auch im Nachhinein als solche zu markieren, was dazu führt, dass sie beim durchblättern über " ← Nächstältere Version" oder "Nächstjüngere Version →" automatisch übersprungen werden. Zudem sollten Benutzer die Möglichkeit erhalten über die Einstellungen derartige Bearbeitungen auch aus der Versionsgeschichte auszublenden.
  • More comments:
  • Phabricator tickets:
  • Proposer: JTCEPB (talk) 19:06, 29 October 2018 (UTC)

Discussion

Good afternoon. If you have no problem with my bad grammer, we can speak english. The page you refer to, would make the most of my wish for the future unnecessary. The option to skip unwanted rollbacks when searching through the edit history would still be nice, but would in my eyes not have a high or even normal priority.--JTCEPB (talk) 19:57, 30 October 2018 (UTC)
@JTCEPB: No worries about the grammar! Since WMDE is already working on rollback confirmation, did you want to revise and keep your proposal? If not, I will move it to the archives. The decision is up to you :) Regards, MusikAnimal (WMF) (talk) 01:18, 31 October 2018 (UTC)
Sure, archive it. No problem with that from my side.--JTCEPB (talk) 01:37, 31 October 2018 (UTC)

OSM map on dewiki

 N Only active registered users can create proposals. Please find someone to adopt your proposal.

  • Problem: The Geohack tool on dewiki does not use updated coordinates after update.
  • Who would benefit: all users of dewiki calling up the OSM map of any article (which is systematically displaying the initial coordinates)
  • Proposed solution:
  • More comments: already requested earlier (e.g. [1], [2])
  • Phabricator tickets:
  • Proposer: 213.208.157.35 12:03, 3 November 2018 (UTC)

Discussion

Mapframe does not work well at the poles

  Withdrawn by proposer

  • Who would benefit: Users/editors working on topics that are close to the north or south pole
  • Proposed solution: Use a different coordinate system that works better at the poles
  • More comments: This is probably more tricky than it sounds, as it requires a fundamental logic change in Kartographer to handle a different coordinate system. It was recently marked as "declined" on phabricator as "It's unlikely we'll have the resources in the foreseeable future to support multiple projections."

Discussion

  • Hi @ Mike Peel. You suggest Kartographer use a coordinate system that will solve the problem of distorted, empty polar maps. Do you know of such a system? What are the alternatives and the tradeoffs each brings? Anyone? —JMatazzoni (WMF) (talk) 04:15, 3 November 2018 (UTC)
Comment: en:List of map projections provides a useful overview. Of those covered, several feature lower distortion in the polar regions than the Mercator; the most readily implemented might be the en:Miller cylindrical projection which retains a rectangular shape and somewhat improves the poles. A much better alternative IMO is the en:Hammer projection; its downside is the ellipsoidal shape, which requires more screen real estate for a given resolution of features. --Elmidae (talk) 12:06, 3 November 2018 (UTC)
@JMatazzoni (WMF): It's complicated. In my day job, we use en:HEALPix to pixelize the whole astronomical sky - and then you can render individual patches using cartesian maps in order to display them (cartesian maps are fine as long as they're smaller than a few degrees on a side). The issue is that a single rendered map is used for the whole of the globe. However, I've just had a look at the south pole on OpenStreetMap, and as they use the same system they have the same problem - so it's not actually possible to edit the map at the poles, which makes displaying the map correctly at the poles rather redundant. As such, I'm withdrawing this proposal. Thanks. Mike Peel (talk) 14:16, 3 November 2018 (UTC)
@Mike Peel: I'm a bit late, but it is actually possible to edit close to the poles (or at least it's possible to make mechanical edits close to them), even though the objects don't get displayed on the map. However, almost all OSM maps and renderers (except possibly Marble) only use Mercator, and there is basically nothing there right now, possibly because most satellite imagery that OSM can use is also Mercator (and so no imagery tiles are generated south of about 85°). Jc86035 (talk) 15:42, 17 November 2018 (UTC)

  Request withdrawn Mike Peel (talk) 14:16, 3 November 2018 (UTC)

Small Monobook CSS changes for Tablets and Smartphones in Desktop mode

  Withdrawn by proposer (too many proposals)

  • Problem: Improve the use of the Monobook interface on Smartphones and Tablets
  • Who would benefit: Every mobile user that want to edit pages using the Monobook skin. Especially tables can benefit from this small enhancement.
  • Proposed solution: Add 10 additonal pixels in margin-top to easily allow using the desktop interface on Smartphones and Tablets. Only one single line needs to be added into the standard CSS style sheet. Change the standard Monobook CSS to add e.g. body { margin-top: 10px; } for Wikipedia and div#globalWrapper { margin-top: 10px; } for Wikidata.
  • More comments: The mobile skin does not allow for easily editing all parts and options of a page. Switching to desktop mode with the Monobook skin gives the user the same interface as on a laptop or desktop. Currently the top menu bar is too close to the address bar on a mobile device, so when a user wants to click on an menu option the address bar is inadvertently activated, and the menu options are not easily accessible. See https://www.mediawiki.org/wiki/Snippets/Tablets_and_Smartphones_in_Desktop_mode
  • Phabricator tickets:
  • Proposer: Geert Van Pamel (WMBE) (talk) 14:58, 4 November 2018 (UTC)

Discussion

  • @Isarra: Would it be possible to just commit this to Monobook? (I don't think this is large enough for Community Tech, because it's basically two lines of CSS.) Jc86035 (talk) 15:23, 4 November 2018 (UTC)
    This could be an excellent solution. Geert Van Pamel (WMBE) (talk) 17:15, 4 November 2018 (UTC)

Page Table of contents Top-right

  Withdrawn by proposer (too many proposals)

  • Problem: Large Table of Contents (TOC) allocate useful screen surface often leaving 2/3th of the right screen unused blank. Even a picture cannot be easily put at that location.
  • Who would benefit: All MediaWiki users (basically everyone)
  • Proposed solution: Frequently the page table of contents takes up a large vertical size of the screen while more than half of the (right) screen width remains blank. The real page content is needlessly shifted down, potentially moving all text off-screen on small screens, with subsequent additional scrolling being required from the user. Moving the TOC from top-left to top-right makes better use of the available screen space and produces a better visual presentation allowing for more easy reading. Frequently leading sections do not contain too much text, nor tables, nor images, so it perfectly aligns the screen layout with the TOC.
  • More comments: A few lines of CSS code moves the page table of contents (TOC) "top-right" instead of (the default) "top-left". No further impact on the GUI. No impact on the software. Useful for all skins. Version independent. Only the CSS #toc style needs to be changed. For the CSS code, see mw:Snippets/Page Table of contents Top-right
  • Phabricator tickets:
  • Proposer: Geert Van Pamel (WMBE) (talk) 15:55, 4 November 2018 (UTC)

Discussion

  • This is something any community could freely do if they wanted to. What does the community tech team have to add to this? --Yair rand (talk) 19:29, 4 November 2018 (UTC)

Central repository for gadgets, templates and Lua modules

 N Outside the scope of Community Tech

  • Who would benefit: Gadget, template and module developers who need to keep things in sync across multiple wikis. Users of those gadgets, templates and modules, who may have to use older versions.
  • Proposed solution: Have a template and Lua module namespace that is shared across multiple wikis, in the same way that we have global user pages.
  • More comments:

Discussion

Simplicity

 N Proposes a social/community policy change rather than a technical feature

  • Problem: This wish list is too complicated for many contributors to understand
  • Who would benefit: People who write articles, but don't understand the technology
  • Proposed solution: Help ordinary contributors to make suggestions on improvements
  • More comments:
  • Phabricator tickets: A case in point
  • Proposer: AlwynapHuw (talk) 07:55, 4 November 2018 (UTC)

Discussion

I have read every single proposal on this "wishlist" but I don't understand 90% of them. They appear to be technical questions about technical issues that I don't understand. Answers to the few problems that I can emphasise with appear to be dealt with by "Phabricator tickets" and other jargon. So my wish is a way for people who write articles on Wikipedia, who are unfamiliar with the guts of the system that produce the articles, to be able to add to this discussion in simple "non tech" language - like this is a problem I have encountered, can it be overcome? AlwynapHuw (talk) 07:55, 4 November 2018 (UTC)

@AlwynapHuw: Hi, this sounds like a social problem and not like something that the Community Tech team could solve technically. There are for example technical village pumps to discuss technical issues and work together if something is complicated, and anyone is free to add comments in the "Discussion" section of every proposal in order to clarify. Have you run into any issues trying that? --AKlapper (WMF) (talk) 17:19, 4 November 2018 (UTC)
Sorry everything is so hard to understand! Unfortunately (or fortunately, depending on how you view it), that is the exact purpose of this survey. We are a technical team and we want to build technical solutions for the community. As AKlapper says, you are most welcome to comment on proposal to get more insight as to what they are about. From there we can reword the proposals to make them easier to understand. That's about the best we can do :( I am archiving this as a social problem, but please feel free to continue discussion here, or even start a thread on the survey talk page. Kind regards, MusikAnimal (WMF) (talk) 22:44, 4 November 2018 (UTC)
I'm not sure that my point has been understood. I know how to ask for help on Village Pump / Cafe / Tavern sites for tools etc that are already available. My problem is with this annual survey. I write on average 500 new articles per year and edit many more. In doing so I often think I wish there was a way of doing XXX easier. This annual survey should be a place that I can ask Is there any way to make doing XXX easier?. But I can't because the survey is too technical for my understanding. Say, for example, having posted an article without any images and linked to Wikidata I would like a "hint box" coming up saying have you thought of using one of these images to illustrate this article?, I don't know how to add such a suggestion to this survey because I don't know how to suggest it in the technical terms that the survey requires. (I am not asking for an Image Hint, just suggesting that such everyday language suggestions should be allowed as part of a wishlist) AlwynapHuw (talk) 05:16, 8 November 2018 (UTC)

Limiter la durée des mandats


 N Proposes a social/community policy change rather than a technical feature. Any community that wants to can implement this policy as they see fit.

  • Problem: Concerne les seuls admins. La durée indéfinie donc infinie des mandats induit la constitution d'un “esprit de groupe” qui a pour effet de former une sorte de caste qui préserve ses positions au détriment de la fluidité des contributions.
  • Who would benefit: Tous les contributeurs.
  • Proposed solution: Limiter la durée des mandats (pas de suggestion ferme mais un ou deux ans me semblent une bonne option) et le nombre de mandats (selon moi, un à trois).
  • More comments: Rien à ajouter, sinon mon salut à toutes et tous.
  • Phabricator tickets: Je me demande ce que signifie “Phabricator tickets”... Pas très important sinon que ça dénote d'un “entre soi” très net, seuls les connaisseurs des méandres de Wikipédia peuvent décoder le terme.
  • Proposer: Olivier Hammam (talk) 04:01, 4 November 2018 (UTC)
  • Remarque incidente: Je soumets ma proposition en français parce que mon anglais est insuffisant, merci d'avance à qui se donnera la peine de me traduire en pidgin globish anglais.

Discussion

I shall attempt a first-draft translation into English, with assistance from machine translation since my French is elementary. I'm hoping that someone with a better knowledge of French can fix any parts that are grammatically awkward due to my not knowing on my own what the original French says. I also will attempt to tinker with it by machine-translating it from French to Spanish, which I do know well. Global teamwork FTW! 🤣 Lawikitejana (talk) 08:42, 4 November 2018 (UTC)

  • Problem: Only admins. The indefinite and therefore infinite duration of mandates creates the formation of a "group spirit" [in-group] which has the effect of forming a sort of caste which preserves its position to the detriment of the flow of contributions.
  • Who would benefit: All contributors.
  • Proposed solution: Limit the duration of mandates (no firm suggestion but one or two years seem like a good option) and the number of mandates (in my opinion, one to three).
  • More comments: Nothing to add, otherwise my greetings to all.
  • Phabricator tickets: I wonder what "Phabricator tickets" means ... Not very important except that it denotes a very clear "in-group" [clique], only connoisseurs of meandering Wikipedia can decode the term.

Propose: Olivier Hammam (talk) 04:01, 4 November 2018 (UTC) Incident note: I submit my proposal in French because my English is insufficient, thank you in advance to whoever will take the trouble to translate mine into pidgin globish English. [De ríen! (You're welcome! / ¡De nada! Lawikitejana (talk) 08:42, 4 November 2018 (UTC) ]

Quick note: this user was blocked indefinitely on frwiki in 2017, followed by a block on enwiki, dewiki, itwiki and nlwiki for harasment. — 0x010C ~talk~ 10:47, 4 November 2018 (UTC)
We already do this when we elect stewards, and any wiki can implement this without further technical work – Swedish Wikipedia has one-year terms for admins, 'crats, check users etc. This is a decision that's up to each individual community. /Johan (WMF) (talk) 16:05, 5 November 2018 (UTC)

Searches with Pronoun

 N Only active registered users can create proposals. Please find someone to adopt your proposal.

  • Problem: Please Make there Be able to, when loading, take all pronouns and delete them, to make people not have to change their search
  • Who would benefit: All people who do not like changing their search
  • Proposed solution: Refer back to problem
  • More comments: I, the writer am 10 years old
  • Phabricator tickets:
  • Proposer: 206.57.199.209 19:20, 5 November 2018 (UTC)Jeff G.

Discussion

turtles like pronouns a lot

Implement widespread autoarchiving

 N Outside the scope of Community Tech

  • Problem: Widespread variation in implementation and syntax, bot dependent, intermittently broken, and time consuming for editors to manually implement autoarchiving on talk pages
  • Who would benefit:
    • Editors, as:
      • Decreases needless edits. If (in my experience) pages require 3 - 5 edits to get auto archiving right per page, that's approximately 25 million wasted edits that could be potentially automated for an easily automated process
    • Improve readability of talk pages. Lots of article talk pages have threads on them that potentially expired a decade ago, and for lack of attention and because it's not the easiest thing to do, haven't yet been auto archived. This improves talk page readability, and keeps discussion focused on the active article at hand.
  • Proposed solution:
    1. WMF should provide community talk page archive bots, with a view to eventually assuming community bot responsibilities
    2. WMF should provide an easy prompt to implement autoarching on talk pages (eg duration, number of remaining posts, and desired archive box)
  • More comments:
  • Phabricator tickets:

Discussion

  • If this is to be done, I hope we make this kind of archival as opt-in: Korean Wikipedia largely prefers archiving by actually moving the page (even if I run the autoarchival bot), and wouldn't welcome this kind of stuff forced on them. — regards, Revi 10:21, 4 November 2018 (UTC)

Hi Tom (LT), I have good news and bad news about this proposal. :) The good news is that the Wikimedia Foundation is starting the planning process for a big global Talk pages consultation which will begin in February. The idea is that we need to step back from LiquidThreads and Flow, and start over with a totally public and transparent consultation. We want to bring together as many people as possible, and come to consensus on the problems with talk pages that we want to solve, the good things about talk pages that we want to keep, and the tradeoffs involved in finding a solution that will work for new and experienced editors. You can read a lot more about it on that project page that I linked. The planning has just started, and we're starting to talk about the structure for this consultation and how it's going to work.

The bad news for right now is that we don't want to include proposals about talk pages in the Wishlist Survey voting. No matter what happens in the Wishlist Survey voting, all of the future talk page work will be determined by the Talk pages consultation happening next year. We don't want people to vote for something, and then find out that we still have to have another process before we make any decisions.

But -- these proposals and the discussions that people are having here are important, and I've added a section on the Talk pages consultation page which lists each of the related proposals, so that they can be a part of the public record during this planning stage. We'd like to include all of you in the consultation -- and in the planning, if you're interested. There's a lot to talk about and figure out.

I'm sure this will be disappointing right now; I hope it's also heartening to know that this problem will get a lot of attention next year. Let me know what you think. -- DannyH (WMF) (talk) 06:41, 6 November 2018 (UTC)

Thanks DannyH, no problem and look forward to the discussion. I hope that in our discussion next year, we can talk about both what might make a great future solution (eg. VE, flow, etc.) but also about things that can improve the current experience and can be implemented more easily in the meantime, lest the best become the enemy of the good. --Tom (LT) (talk) 10:31, 6 November 2018 (UTC)
Yes, that's absolutely going to be part of the discussion. Incremental changes could turn out to be the right answer in some cases. -- DannyH (WMF) (talk) 00:32, 7 November 2018 (UTC)

Add a search and ranking system to structured discussions

 N Outside the scope of Community Tech

  • Problem: Add a search and ranking system to structured discussions (Flow). Many things could be added and corrected in order to have a better navigation between topics of a discussion page.
  • Proposed solution: Add standard features on discussions systems :
    • an "internal search" for a discussion page
    • filter open / closed topics
    • move topics
    • improve summary when there is many topics : it is currently impossible to access old topics without "a long scroll".
  • More comments:
  • Phabricator tickets:

Discussion

@Prométhée: Under "Problem", could you please describe a specific, discrete root problem? "The software is incomplete" is not a problem per se - basically every software is incomplete as someone can always request a new feature. :) Please also see https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2019#proposalsphase - it's unclear which problem would be solved by "improving". Thanks! --AKlapper (WMF) (talk) 03:38, 1 November 2018 (UTC)

@AKlapper (WMF): I already propose four features in this topic. Other contributors can add their ideas. Prométhée (talk) 10:45, 1 November 2018 (UTC)
@Prométhée: What is "improve summary" exactly? Without a description of an actual problem, nobody else can guess what to improve exactly. Again, proposals should be about one specific and discrete problem, but this proposal seems to be about four problems instead. See the link I provided. --AKlapper (WMF) (talk) 16:31, 1 November 2018 (UTC)
I renamed the proposal and made changes to bring precisions. Prométhée (talk) 08:26, 2 November 2018 (UTC)

Hi Prométhée, I have good news and bad news about this proposal. :) The good news is that the Wikimedia Foundation is starting the planning process for a big global Talk pages consultation which will begin in February. The idea is that we need to step back from LiquidThreads and Flow, and start over with a totally public and transparent consultation. We want to bring together as many people as possible, and come to consensus on the problems with talk pages that we want to solve, the good things about talk pages that we want to keep, and the tradeoffs involved in finding a solution that will work for new and experienced editors. You can read a lot more about it on that project page that I linked. The planning has just started, and we're starting to talk about the structure for this consultation and how it's going to work.

The bad news for right now is that we don't want to include proposals about talk pages in the Wishlist Survey voting. No matter what happens in the Wishlist Survey voting, all of the future talk page work will be determined by the Talk pages consultation happening next year. We don't want people to vote for something, and then find out that we still have to have another process before we make any decisions.

But -- these proposals and the discussions that people are having here are important, and I've added a section on the Talk pages consultation page which lists each of the related proposals, so that they can be a part of the public record during this planning stage. We'd like to include all of you in the consultation -- and in the planning, if you're interested. There's a lot to talk about and figure out.

I'm sure this will be disappointing right now; I hope it's also heartening to know that this problem will get a lot of attention next year. Let me know what you think. -- DannyH (WMF) (talk) 06:41, 6 November 2018 (UTC)

Release VE on Talk pages

 N Outside the scope of Community Tech

  • Problem: Currently VE is disabled on talk pages without any proper reason. This makes editing, especially for new users, more complicatted.
  • Who would benefit: Everyone, but especially new users.
  • Proposed solution: As I said in the headline: Simply enable VE on talk pages, it's possible.
  • More comments: It would help a lot with regards for help to n00bs, if all wikipages could be edited in the same way. Now there is a artificial and not technically necessary Division between the article and the talk page.
  • Phabricator tickets:

Discussion

Last year it was somehow declared out of scope to simply turn it on on another wikipage, I still don't have the faintest clue, why this was proihibited. Grüße vom Sänger ♫(Reden) 11:53, 30 October 2018 (UTC)

But let VE be able to edit by sections (because VE setup is slow on large pages). --89.25.210.104 17:53, 30 October 2018 (UTC)

I dislike this idea because often I only need to edit a section on the talk page and not the whole thing. I think the script linked above for 'reply' link on talk pages is a better implementation. Gryllida 22:25, 30 October 2018 (UTC)

But that's a problem with the VE on every huge page, regardless where it's located. This is a feature, that should be implemented in the article namespace as well. Up to now the VE makes a artificial differentiation between wikipages and wikipages, despite wikipages should behave the same way everywhere. Grüße vom Sänger ♫(Reden) 05:30, 31 October 2018 (UTC)

This would help in training new editors. I often teach them to use VE, but don't have time to explain source editing, so sometimes they feel lost trying to edit a talk page. It would also make Wikipedia's editing interface on talk pages more consistent. Rachel Helps (BYU) (talk) 17:41, 2 November 2018 (UTC)

If I remember correctly one reason why it's not released on talk pages was that indenting comments is not easy using VE. There should be some button provided by VE where you can choose to which comment you want to reply and indents should then come automatically. Stryn (talk) 21:46, 5 November 2018 (UTC)

There is no problem using indenting here in this discussion with the VE. So if this was given as a reason, it was either a bigus reason then, or it was solved since. I use indention with a ":" here in this paragraph, and I'm using VE, so no problem. Grüße vom Sänger ♫(Reden) 05:27, 6 November 2018 (UTC)

VE was built for article pages, basically--it would take too much time to make it work for talk pages. Even if that were not the reason, re-requesting a change that wasn't in scope last year isn't going to make it in scope this year. --Izno (talk) 02:46, 6 November 2018 (UTC)

A wikipage is a wikipage is a wikipage. There is no difference between wikipages in regard of editability, at least that's what it is supposed to be. Grüße vom Sänger ♫(Reden) 05:27, 6 November 2018 (UTC)

Hi Sänger and others, I have good news and bad news about this proposal. :) The good news is that the Wikimedia Foundation is starting the planning process for a big global Talk pages consultation which will begin in February. The idea is that we need to step back from LiquidThreads and Flow, and start over with a totally public and transparent consultation. We want to bring together as many people as possible, and come to consensus on the problems with talk pages that we want to solve, the good things about talk pages that we want to keep, and the tradeoffs involved in finding a solution that will work for new and experienced editors. You can read a lot more about it on that project page that I linked. The planning has just started, and we're starting to talk about the structure for this consultation and how it's going to work.

The bad news for right now is that we don't want to include proposals about talk pages in the Wishlist Survey voting. No matter what happens in the Wishlist Survey voting, all of the future talk page work will be determined by the Talk pages consultation happening next year. We don't want people to vote for something, and then find out that we still have to have another process before we make any decisions.

But -- these proposals and the discussions that people are having here are important, and I've added a section on the Talk pages consultation page which lists each of the related proposals, so that they can be a part of the public record during this planning stage. We'd like to include all of you in the consultation -- and in the planning, if you're interested. There's a lot to talk about and figure out.

I'm sure this will be disappointing right now; I hope it's also heartening to know that this problem will get a lot of attention next year. Let me know what you think. -- DannyH (WMF) (talk) 06:40, 6 November 2018 (UTC)

I think, this is delaying a simple and feasible solution another year, just to not let people get any experience with the normal editors on talk pages. If you just switch it on, even perhaps just as a test on some user talk pages, there could be some experience with it, but as this could be some positive experience that would be detrimental to Flow, this will not happen. Flow is far too much protected from any harm by those, that seem to have invested a lot in it, regardless of it's usefulness, that any negative possible side projects have to be avoided.
I just saw in the source code, thar VE uses <blockquote> here in this talk instead of normal colons, that's making the text quite unreadable in source code, i.e. the old Editor/normal talk page Editor. Grüße vom Sänger ♫(Reden) 08:12, 6 November 2018 (UTC)
Sänger: Yes, in the past Wishlist Surveys, we closed all proposals related to talk pages because there was another product team working on Flow, and Community Tech couldn't do anything that would interfere with that team's work. We're changing that strategy now, and the Talk pages consultation is going to help us all figure out what we're doing next. Turning on VE for talk pages is one of the things we'll be talking about in that consultation -- see the section in the Talk pages consultation page about "Possible solutions". For right now, we're not going to make any changes related to talk pages, because we want to have those discussions first. -- DannyH (WMF) (talk) 14:16, 6 November 2018 (UTC)
Fine, you moved it from meta to MW, where I'm banned in some shady backroom kangaroo court because I was a bit outspoken against the devs, that ignored facts and perpetuated falsehoods about Flow and VE. I thought MW was only about technical stuff, this is something about social and community interaction stuff, the technology has to follow the needs of the editors, not the other way around. So here on meta would be the right place for this discussion, not over there. Grüße vom Sänger ♫(Reden) 21:06, 8 November 2018 (UTC)

Renovate all discussion pages - they won't be a wikipages

 N Outside the scope of Community Tech

  • Problem: talk pages are not convenient to use.
  • Who would benefit: all users.
  • Proposed solution: turn on talks without wiki-technology in all talkpages (non-multiple-namespaces). Discussions will be like as comments on http://4pda.ru, http://habr.com or other sites with same design of comments. It is simple, laconic and functional. But don't loss the templates with {}, they will work.
  • More comments: Ye, it's a rocket science. Renovate all mechanics of discussions! But... Really, we are the most popular site in the Internet, why we will look like a Soviet tractor? We will look like Yandex, Google and other top sites. Don't be a dinosaur!
  • Phabricator tickets:

Discussion

You seem to be asking for the feature currently called "Structured Discussions", which has a long and somewhat controversial history. Anomie (talk) 14:23, 30 October 2018 (UTC)

I think there is already a good implementation discussed above about adding 'reply' link at talk pages, it is a good implementation in my view. Gryllida 22:27, 30 October 2018 (UTC)

  • I think that now it is unlikely to expect the conversion of discussion pages from wikitext into something else. There were already two attempts (Flow and Structured Discussions), and both ended not very well. I think that a much more useful and realistic direction at the moment is to improve the editing of wikitext. For example, in Russian Wikipedia there is the Convenient Discussions script (made by Jack who built the house). It seems to me that it makes sense to develop this initiative as a gadget for all projects. — putnik 00:51, 31 October 2018 (UTC)
    • Thanks for the link to the script! I'm reading the code now. Enterprisey (talk) 04:48, 31 October 2018 (UTC)
      • Enterprisey How does it compare with yours (w:User:Enterprisey/reply-link.js)? Gryllida 23:54, 31 October 2018 (UTC)
        • I don't think you can select a single comment and reply to it, but I really have no idea - I can't read Russian. That feature is a key part of reply-link. The code looks like it does more or less the same sort of stuff, but it's much more involved than reply-link, so it takes more time to read it. Enterprisey (talk) 03:35, 2 November 2018 (UTC)
    • Putnik regarding that see this proposal if you haven't already. Galobtter (talk) 07:13, 31 October 2018 (UTC)

Hi Фред-Продавец звёзд and others, I have good news and bad news about this proposal. :) The good news is that the Wikimedia Foundation is starting the planning process for a big global Talk pages consultation which will begin in February. The idea is that we need to step back from LiquidThreads and Flow, and start over with a totally public and transparent consultation. We want to bring together as many people as possible, and come to consensus on the problems with talk pages that we want to solve, the good things about talk pages that we want to keep, and the tradeoffs involved in finding a solution that will work for new and experienced editors. You can read a lot more about it on that project page that I linked. The planning has just started, and we're starting to talk about the structure for this consultation and how it's going to work.

The bad news for right now is that we don't want to include proposals about talk pages in the Wishlist Survey voting. No matter what happens in the Wishlist Survey voting, all of the future talk page work will be determined by the Talk pages consultation happening next year. We don't want people to vote for something, and then find out that we still have to have another process before we make any decisions.

But -- these proposals and the discussions that people are having here are important, and I've added a section on the Talk pages consultation page which lists each of the related proposals, so that they can be a part of the public record during this planning stage. We'd like to include all of you in the consultation -- and in the planning, if you're interested. There's a lot to talk about and figure out.

I'm sure this will be disappointing right now; I hope it's also heartening to know that this problem will get a lot of attention next year. Let me know what you think. -- DannyH (WMF) (talk) 06:40, 6 November 2018 (UTC)

Reply link for talk pages

 N Outside the scope of Community Tech

  • Problem: New editors often have trouble understanding how to reply to comments on talk pages, or signing their messages, etc. Especially for editors used to the Visual editor, using talk pages and the conventions of using repeated colons is clearly confusing to new editors. We need a reply link functionality added to each comment, to make it easier for IPs and new editors to reply to comments on talk pages. While Flow was a disaster because it didn't integrate well with the current system in use, there is a much easier solution in the form of a current user script (en:User:Enterprisey/reply-link) which could be implemented globally to great effect.
  • Who would benefit: Everyone would benefit from this proposal, as it makes talk page communication easier, even for experienced users, but new users and IPs would see the greatest benefit, and it would likely encourage more new people to start participating in discussions, which is the first step to becoming a regular editor.
  • Proposed solution: Improving en:User:Enterprisey/reply-link to the point that it is stable enough to be implemented as a Gadget (it could be turned off if people want to, but it should be defaulted as ON if expected to have any impact on new users). While defaulting it as 'ON' would require community consensus, developing it to be stable enough (with code review) is the important first step.
  • Phabricator tickets: T207567 (not an exact match for this proposal)
  • Proposer: — Insertcleverphrasehere (or here) 08:39, 30 October 2018 (UTC)

Discussion

Well, I was thinking of proposing/suggesting something similar but didn't get around to it - Insertcleverphrasehere. I think this can be re-framed a little clearer as a proposal to improve the reply-link script enough so that it is stable enough to be enabled as a gadget, hopefully as a default one (whether to default is a decision by the community based on how stable/useful the gadget is (and can be done by any interface-admin) not by the community tech team). Galobtter (talk) 09:01, 30 October 2018 (UTC)

@Galobtter: Some good points. I've amended the proposal to address your comments. — Insertcleverphrasehere (or here) 09:13, 30 October 2018 (UTC)
(e/c) :It will never be a stable solution. It's analyzing the intent of people when they wrote wikitext, so by definition there will always be a certain failure rate. Which is also why I suspect that WMF will not want to pursue this, as it will introduce something that will permanently cause failures, with no way of solving them. —TheDJ (talkcontribs) 09:22, 30 October 2018 (UTC)
Yeah I was also wondering how stable it is possible to be. I think something like 99-99.9% success rate could be good enough though - new users create far more mistakes that have to be corrected when they use raw wiki-text/have far more issues with wiki-text than that. Galobtter (talk) 09:28, 30 October 2018 (UTC)
Lemme be clear, I do not think this is a "user facing problem" it's a "people will keep creating tickets for the developers for the few times where it fails and demand it gets fixed but it can never be fixed"-problem. Generally that is something that developers try to avoid adding at all costs. —TheDJ (talkcontribs) 09:41, 30 October 2018 (UTC)
Well, since community tech does not provide ongoing support, we wouldn't direct people to phab for fixes anyhow, and so people would be directed to a talkpage where their complaints can be safely ignored :) Galobtter (talk) 09:58, 30 October 2018 (UTC)

I like the idea, didn't even know that the script exists. Gryllida 22:24, 30 October 2018 (UTC)

  • I like this idea and also didn't know there was a script. I think it would be useful unless there is already an onboarding "wizard" that does this. PopularOutcast (talk) 23:12, 30 October 2018 (UTC)
  • (Author of the script here) Good idea! :) I do share TheDJ's concerns about how this script is practically guaranteed to break occasionally. I haven't made up my mind over whether it impedes this idea from being implemented, though. Enterprisey (talk) 04:44, 31 October 2018 (UTC)
  • Enterprisey pointed to ru:Участник:Jack_who_built_the_house/convenientDiscussions.js which works pretty similarly and was created a few months after reply-link (ping Jack who built the house). I'm curious how well that script works in actually reply/i.e if it has breaks less often. Since they seem so similar though there should be one well tested gadget for this.
Another thing; I think if we're going to be deploying to new users we should make it so that they very rarely have to use manual editing interface for replies in talk pages; one thing that would make this so is to allowing the creation of new sections with this interface. Galobtter (talk) 06:12, 31 October 2018 (UTC)
Probably another thing would be making it work in mobile.. Galobtter (talk) 06:15, 31 October 2018 (UTC)
Hi. Unfortanutely, I haven't done the job of internationalizing the script and fixing various bugs before some very ugly things happened in Russian Wikipedia, depriving me of the will to continue the development. Still, I believe, the script is quite stable, working in most cases. Some people have reported successful usage of it outside of Russian Wikipedia, though it was initially developed based on ruwiki specifics. Jack who built the house (talk) 09:47, 31 October 2018 (UTC)

I like the idea and can see the use, but please allow opt-out. Adding a new icon to every comment adds a lot of stuff to talk pages, and I expect many to not want that. Sure, you can always opt out via a custom script, but that is not the right approach. --mfb (talk) 03:17, 4 November 2018 (UTC)

  • Or...just to get rid of that outdated style of talk page and convert to any other style used online in forums or message boards. Where replying and linking to individual comments is much more natural (and eliminating the need of ever signing or indenting again). --Gonnym (talk) 07:22, 4 November 2018 (UTC)
    Oh you, talking so flowingly. --Izno (talk) 01:00, 6 November 2018 (UTC)
  • As it would be a gadget, one would be able to opt-out in preferences. Galobtter (talk) 12:16, 4 November 2018 (UTC)

Hi Insertcleverphrasehere and others, I have good news and bad news about this proposal. :) The good news is that the Wikimedia Foundation is starting the planning process for a big global Talk pages consultation which will begin in February. The idea is that we need to step back from LiquidThreads and Flow, and start over with a totally public and transparent consultation. We want to bring together as many people as possible, and come to consensus on the problems with talk pages that we want to solve, the good things about talk pages that we want to keep, and the tradeoffs involved in finding a solution that will work for new and experienced editors. You can read a lot more about it on that project page that I linked. The planning has just started, and we're starting to talk about the structure for this consultation and how it's going to work.

The bad news for right now is that we don't want to include proposals about talk pages in the Wishlist Survey voting. No matter what happens in the Wishlist Survey voting, all of the future talk page work will be determined by the Talk pages consultation happening next year. We don't want people to vote for something, and then find out that we still have to have another process before we make any decisions.

But -- these proposals and the discussions that people are having here are important, and I've added a section on the Talk pages consultation page which lists each of the related proposals, so that they can be a part of the public record during this planning stage. We'd like to include all of you in the consultation -- and in the planning, if you're interested. There's a lot to talk about and figure out.

I'm sure this will be disappointing right now; I hope it's also heartening to know that this problem will get a lot of attention next year. Let me know what you think. -- DannyH (WMF) (talk) 06:40, 6 November 2018 (UTC)

DannyH (WMF) That sound's like the pragmatic approach. I'm sure that Enterprisey will continue working on the script in the meantime. — Insertcleverphrasehere (or here) 08:30, 6 November 2018 (UTC)

Wikimedia Workshop/Seminar/Conference for the Visually-Impaired

 N Outside the scope of Community Tech

  • Problem: So far, editing/using Wikipedia or other Wikimedia Foundation projects require full usage of our visual, because of keyboard-input method. We need to find a way to expand Wikimedia Foundation project interface to be able to accommodate the visually impaired people so that they also can get the benefit of this free knowledge for mankind of Wikipedia. All of the ongoing projects/solutions can always be brought up into a newly designed Wikimedia Conference for the visually impaired (let's say annually in various places, or as part/section/sub of a bigger Wikimedia Conferences).
  • Who would benefit: People having difficulties in their visual in using Wikipedia.
  • Proposed solution: Make Wikipedia (and other Wikimedia Foundation projects) to be visually impaired-friendly. First, for searching the articles in Wikipedia, we need to create a sound-sensitive input method so that they can easily search any article by speaking (e.g. into microphone input) and automatically convert it into wording and automatically search the related article names from it. Second, for each article, there must be a button that can be clicked (or sound activated mode) in which it will then read out all of the wordings in side one particular article to the user.
  • More comments: So far the closest works for this kind of project is Wiki in Audio (including Wikimedia:Spoken articles, Wikipedia:WikiProject Spoken Wikipedia, Meta:Wikisound). But what I have understood so far, those sound must be fully recorded, thus disabling the spoken voice to speak out when the article gets expanded. So, it is better to make each of the word to be spoken one by one, instead of recording a voice for the whole article continuously. Maybe a more similar approach would be like the voice button at Google Translate, in which it will speak out each word one by one.
  • Phabricator tickets: I have no idea what this is :(
  • Proposer: Chongkian (talk) 04:18, 5 November 2018 (UTC)

Discussion

The Swedish Wikipedia is already working on Wikispeech. I also think that conference organising is not within the scope of this wishlist: Community_Tech#Scope. I do note the availability of Conference grants, rapid grants and project grants programs available to all those who want to organise something. —TheDJ (talkcontribs) 11:51, 5 November 2018 (UTC)

That's correct. Chongkian I suggest you rename this proposal to focus on the technical problem (Make Wikipedia more accessible to the visually impaired possibly). Conference organizing is not within the scope of this wishlist. Sorry. -- NKohli (WMF) (talk) 19:29, 5 November 2018 (UTC)
Oh ok, I've moved this discussion to Community Wishlist Survey 2019/Editing, without mentioning the conference parts. Maybe then the OP/bot can delete this conversation. Chongkian (talk) 04:13, 6 November 2018 (UTC)

Solution to the ‟Bonnie and Clyde” problem

 N Only active registered users can create proposals. Please find someone to adopt your proposal.

  • Problem: Wikidata can only link one article per language. There are, however, cases where a single article in one language corresponds to two articles in some other language. A prototypical instance is Bonnie and Clyde, with most languages having an article about the duo Bonnie and Clyde, some having an article about Bonnie Parker, and some having an article about Clyde Barrow (see also d:WikiProject Cross Items Interwikis). The articles about the individual bank robbers cannot (at least not both) link to the many articles about the duo, which exist in many languages, so it is hard to find the corresponding articles in those other languages when coming from such a single-person article. (Other relevant situations I can think of are misfitting taxonomies; while e.g. in biology the international research community has agreed upon a common hierarchy, this is not the case in many other fields, where it might turn out to be unclear or questionable which term in another language an article should be linked to when there is no perfect match.)
  • Who would benefit: Potentially all readers, exact number of relevant cases unknown so far
  • Proposed solution: While allowing Wikidata items to link more than one page per language is probably not a viable option, having language links as displayed in Wikipedia side-bars link to more than one article in another language should be principally possible. A language link to a language version in which more than one article is linked to the current one could, for instance, show a pop-up menu instead of directly navigating to the foreign-language article in question. More important than the GUI design for this feature would be the question where to take the target articles from. In the case of Bonnie and Clyde, a language link connecting Bonnie Parker articles (or Clyde Barrow articles, respectively) with Bonnie-and-Clyde articles could be obtained from the ‟part of” relation (d:P361). A sufficiently general solution would perhaps allow for a set of relevant Wikidata relations, to be determined by the Wikidata community, that are used to populate ‟multiple” interwiki connections of the proposed form. Even if the ability to have ‟multiple” interwiki connections is undesired, the Wikidata relations could still be used to connect articles to languages for which a direct equivalent has not yet been registered in Wikidata (either because a corresponding artcile has not yet been linked or because such a corresponding article does not yet exist).
  • More comments:
  • Phabricator tickets:
  • Proposer: 78.50.250.109 23:08, 6 November 2018 (UTC)

Discussion

mw.toolbar zurück

  • Problem: The mw.toolbar was removed
  • Who would benefit: All active authors
  • Proposed solution: Restore the toolbar
  • More comments:
  • Phabricator tickets: task T30856
  • Proposer: Itti (talk) 14:20, 6 November 2018 (UTC)

Discussion

The following discussion is closed.

Die Toolbar wird von vielen aktiven Autoren benötigt, übergreifend in vielen Sprachen, zumal durch die Toolbar Sonderzeichen einfach und unkompliziert eingesetzt werden können. Diese Änderung ist nicht hilfreich und sollte rückgängig gemacht werden.

The toolbar is needed by many active authors, globally in many languages, also because special characters are accessible in an easy, uncomplicated way. This modification is not helpful and should be reverted.

— Itti, 6 November 2018
--Itti (talk) 14:20, 6 November 2018 (UTC)
Ich unterstütze das massiv. Die Behauptung, nur eine ganz kleine Anzahl aktiver User nutze Toolbar und Sonderzeichen, ist ganz offensichtlich falsch, wie sich an einer ganzen Reihe Threads in der deutschsprachigen Wikipedia erkennen lässt. Im Gegenteil sind durchweg aktive User mit vielen Edits mit diesem Ärger konfrontiert und haben sich in starken Worten dagegen ausgesprochen. Insbesondere für die übersichtliche Sonderzeichenliste gibt es in den Einstellungen keinen vernünftigen Ersatz. Die Toolbar sollte umgehend wieder unterstützt werden.Mautpreller (talk) 14:47, 6 November 2018 (UTC)
wo ist sie hin? --Atamari (talk) 14:50, 6 November 2018 (UTC)
Mal wieder eine tolle Leistung der WMF. --DaB. (talk) 15:12, 6 November 2018 (UTC)
How are we ever going to gain new authors if you anger the existing ones? --voyager (talk) 15:17, 6 November 2018 (UTC)
[3] «« Man77 »» [de] 15:25, 6 November 2018 (UTC)
I used that toolbar whilst writing every new article, and I want it back. There is no understandable reason for removing it. Please undo that annoying action as soon as possible. Thank you very much in advance. --Maimaid (talk) 16:06, 6 November 2018 (UTC)
The other toolbar ("Erweiterte Bearbeiten-Werkzeugleiste") is overly big, requires more clicks and is not a good replacement. --Neitram (talk) 16:09, 6 November 2018 (UTC)

Just for context, these people are mostly coming from de:Wikipedia:Fragen_zur_Wikipedia#haben_Hamster_die_Bearbeitungssymbole_verschluckt?. —TheDJ (talkcontribs) 15:37, 6 November 2018 (UTC)

And de:Wikipedia Diskussion:Kurier#Nutzer des 2006er Wikitext-Editors müssen auf eine neuere Version umsteigen. There are at least two more threads in German Wikipedia about this subject. About 95 per cent writing there don't like the toolbar removal at all.Mautpreller (talk) 15:50, 6 November 2018 (UTC)
That is not unsurprising. People who are not affected have no reason to contribute in such discussions ;) —TheDJ (talkcontribs) 16:03, 6 November 2018 (UTC)
Meaning that there are a lot of high-volume accounts who were gravely affected. Not a "tiny fraction of editors" or "very few active editors" as is untruthfully claimed here. There is a growing feeling that long-time and productive editors are literally contempted by WMF tech experts.Mautpreller (talk) 16:14, 6 November 2018 (UTC)

Die mit der Änderung hinweggefegten de:Wikipedia:Helferlein/Extra-Editbuttons mit der Möglichkeit zur Individualisierung sind für meine Arbeit obligatorisch. So lange es keinen adäquaten Ersatz gibt, ist die Deaktivierung derselben für mich völlig unverständlich. Ich halte es für ein Muss (!), dass jeder von der Änderung betroffene User entsprechend vorab informiert und folgend einen einfachen Lösungsweg an die Hand gegeben wird. Es dürfte kein einziger (!) Autor so vor den Kopf gestoßen werden, wie es heute auf de.wp augenscheinlich einer ganzen Reihe von produktiven Accounts ging. Anders gesagt: Die Änderung ist umgehend rückgängig zu machen. --JD {æ} 16:03, 6 November 2018 (UTC)

per Neitram. This affects the work of a good part of the most active authors in on de.wp. --Zinnmann (talk) 16:23, 6 November 2018 (UTC)
These people do also come from here, here, here and here. And that's just from de:WP. Most of them are very experienced users profoundly discouraged by the abrupt disappearance of their tools. They'd like this editing help, for which there is no functionally or ergonomically equivalent alternative in "modern" toolbars, just to be back. Whatever technical issues there might be, frustrating the few remaining, higly active editors by depriving them of their preferred tools is not the way to go. --Eloquenzministerium (talk) 16:29, 6 November 2018 (UTC)

For the records, the voting phase starts on November 16th. --AKlapper (WMF) (talk) 16:51, 6 November 2018 (UTC)

@User:AKlapper (WMF): I don't care. This problem is urgent and can't wait ten days. Chaddy (talk) 17:39, 6 November 2018 (UTC)
User:Chaddy, wishlist items usually take, on average, a full year to be implemented. If this "can't wait ten days", then it can't wait until July 2019, which is the very earliest that the wishlist team would do anything about it.
On the other hand, anyone on this list, including User:Itti, could install the replacement today. Why wait for the wishlist? Whatamidoing (WMF) (talk) 18:27, 6 November 2018 (UTC)

I've removed all the +1's as it may mislead others into thinking we're in the voting phase. Comments are most welcome but please save the mass endorsement for the voting phase which starts November 16. Thanks! MusikAnimal (WMF) (talk) 17:07, 6 November 2018 (UTC)

I don't agree. The massive support for this community wish should remain visible, no matter whether the voting phase is opened or not.Mautpreller (talk) 17:10, 6 November 2018 (UTC)
Is that the next move in your great strategy to get rid of highly productive authors? --voyager (talk) 17:17, 6 November 2018 (UTC)
I entirely agree. @MusikAnimal (WMF): I would kindly ask you to immediately restore those signatures.--Hildeoc (talk) 17:22, 6 November 2018 (UTC)
Sorry about that. It is problematic because it makes it appear like a voting-style survey (which it will be on November 16), and others may start to do the same in other proposals. This should be reserved for "discussion", hence the heading. I did not remove anything but the +1's. Comments were retained. Thanks for your cooperation and understanding! MusikAnimal (WMF) (talk) 17:25, 6 November 2018 (UTC)
I reverted your manipulation. That is inapprehensible! Chaddy (talk) 17:47, 6 November 2018 (UTC)
I promise I'm not trying to obscure the support for restoring the toolbar. I am merely managing the survey, and if we see all those +1's, it's going to spread to other proposals and cause havoc. When we get to the voting phase, I'll personally restore all +1's (and make them {{support}}). Okay? :) MusikAnimal (WMF) (talk) 17:48, 6 November 2018 (UTC)
No, not in 10 days. This has to be visible NOW! Chaddy (talk) 17:51, 6 November 2018 (UTC)
I'm afraid that is not how it works :( We have an established schedule and process. Your cooperation is greatly appreciated :) Managing the survey is a huge effort, and letting early voting in makes it incredibly tedious to control. Rest assured I'm not trying to hide the vast disappointment that the toolbar was removed (which Communtiy Tech had nothing to do with). MusikAnimal (WMF) (talk) 17:53, 6 November 2018 (UTC)
I did not delete half of this page here, so I don't think I have to be told to cooperate...
But ok, then could you please just restore the deleted signatures without the "+1" in front of it and maybe add a short annotation, so that nobody can mix them up with votings? I think this would be a fair compromise. Chaddy (talk) 18:03, 6 November 2018 (UTC)
Sure, allow me to put something together. I'm not going to present it as individual bullet points, but we can list the usernames of those who endorse it. I'm going to do that now! Give me 10 minutes or so :) MusikAnimal (WMF) (talk) 18:11, 6 November 2018 (UTC)
Thank you! Chaddy (talk) 18:17, 6 November 2018 (UTC)

Removing of the small edit tool bar below the edit window is a great damage. Please undo this immediately! Chaddy (talk) 17:27, 6 November 2018 (UTC)

Moin, ich habe eine Pingliste angelegt. Alle +1 supports finden sich dort und bekommen am 16. November eine Erinnerung. Wer noch eine Erinnerung möchte, einfach eintragen. Danke für euren Support! --Itti (talk) 17:27, 6 November 2018 (UTC)

The removal is a severe pain to contributers from not German speaking countries even if they are native or fluent speakers of German, since the tool bar provided Umlaute and Eszett, among others. Since I am an expat, knowledge transfer from the English speaking world to the German WP became the core of what I am doing in WP, and since I obviously don't have a German keyboard, I rely heavily on that little toolbar. --Stilfehler (talk) 17:49, 6 November 2018 (UTC)

Sorry, what is this unqualified edit? Is this next level of zensus? I am very disappointed with this edit. --2001:16B8:1180:A600:FDDE:4EBD:E6F6:29BB 17:56, 6 November 2018 (UTC)
I've explained it above. Do not worry! The popularity of this proposal is abundantly clear. I'm going to add back all the votes once the voting phase starts :) MusikAnimal (WMF) (talk) 18:00, 6 November 2018 (UTC)
Which will be in ten days. But the problem is urgent and can't wait that long. Chaddy (talk) 18:04, 6 November 2018 (UTC)
The premature votes won't make this wish happen any sooner, on our end. Community Tech strictly goes by our schedule. For a more urgent response, you could try creating a Phabricator ticket to reach out to the responsible parties, or commenting at phab:T30856. I don't know what else to tell you :( MusikAnimal (WMF) (talk) 18:09, 6 November 2018 (UTC)

I am deeply disturbed by the removal of a significant portion of contributions by @MusikAnimal (WMF):. Those +1 entries showed clearly, that there is a widespread dissatisfaction with the removal decision and sweeping it under the rug is grossly manipulative. Would it have been beneficial to the readability of the debate if every one of them had basically said the same in his own words? Yes, we are not in the voting phase, but neither are we in a phase where it is appropriate to remove the opinions of a significant number of authors opposing this misguided WMF-decision.

Not just a bit infuriated --Eloquenzministerium (talk) 18:05, 6 November 2018 (UTC)

This section is called "Discussion". I don't see how writing "+1" discusses the proposal. --AKlapper (WMF) (talk) 18:08, 6 November 2018 (UTC)
Really? Since when do you use the internet? Chaddy (talk) 18:17, 6 November 2018 (UTC)
My point was that I don't see a "discussion" when people repeatedly only write "+1". Your question seems to be unrelated to the topic. --AKlapper (WMF) (talk) 18:31, 6 November 2018 (UTC)
But it is. Using "+1" is a normal behavior in internet slang to express approval. You can interpret it as an abbreviation for "I agree" or "Yes, this is also my opinion" or else. Thus it is often more than just a voting. Chaddy (talk) 00:45, 7 November 2018 (UTC)

The foundation is trying to make another big mistake like the image filter. Get back the tool bars back immediatly. Just undo the latest change. Dont wait. You have not asked us before, you have not warned the users, you just behave like Donald. --Eingangskontrolle (talk) 18:09, 6 November 2018 (UTC)

As I previously explained, the +1 contributions are contributions, not votes, avoiding to clutter the discussion needlessly with basically the same text over and over. Should you not add them back, do you really believe that a mass message to those, whose voices have just been cut out, explaining what happened here and inviting them to further elaborate on their point of view would be a desirable course of action? --Eloquenzministerium (talk) 18:19, 6 November 2018 (UTC)
I feel like you all might be mislead into thinking the +1's will make this happen sooner. Going by our schedule, Community Tech can't do anything until the survey is over. We were not involved with removing the toolbar, and we are not trying to censor your frustration. A request for a more urgent response should be made on Phabricator, or perhaps just comment at phab:T30856. MusikAnimal (WMF) (talk) 18:24, 6 November 2018 (UTC)
  • Where can you provide ‘−1’? It would be extremely unfortunate to force Community Tech team to work on supporting an extremely old and unnecessary editing interface just to appease some German contributors. This is, frankly, not a matter for Community Wishlist Survey. stjn[ru] 18:36, 6 November 2018 (UTC)
    Our team still needs to discuss, so I can't say for sure, but if we do get to this, it'd likely be creating a gadget or something similar to accomplish the same functionality (with full community consultation to make sure it meets their needs). But again we can't do it until the survey is over. Everyone here seems to want this back now, so in that sense maybe the Survey isn't the right place. MusikAnimal (WMF) (talk) 18:41, 6 November 2018 (UTC)
Are we talking about the same thing?
mw.toolbar CharInsert
   
What people are asking to have installed (top of the editing window) What people seem to want (usually underneath the editing window)

I think we need to be clear about what we're talking about. If dewiki has a bug that's hiding CharInsert, then bringing back mw.toolbar is not going to do what you want.

Whatamidoing (WMF) (talk) 18:37, 6 November 2018 (UTC)

Moin, yes, both. I made a fix, a few minutes ago, so the bottom list is more or less back, but that is not realy good. A lot of editors need this help and it would be great, if you coult improve this. Thanks! --Itti (talk) 18:46, 6 November 2018 (UTC)
Thanks for fixing the CharInsert bug for dewiki. If you want the blue-gray toolbar, too, why don't you just install it as a gadget? That's something that you can do. Whatamidoing (WMF) (talk) 18:59, 6 November 2018 (UTC)
I simply don't understand you, Whatamidoing. It is mainly the visible list of special characters directly below the editing window, very clearly disposed, visible without any click, with the possibility to choose typical characters for example for Spanish or Scandinavian or Romanian languages.Mautpreller (talk) 18:52, 6 November 2018 (UTC)
That's what I thought the problem was. Those special characters are not mw.toolbar. Mw.toolbar is only the blue-gray buttons. Whatamidoing (WMF) (talk) 18:57, 6 November 2018 (UTC)
I don't know the explicit list of characters that you want, but what you describe sounds like CharInsert. This is enabled as a gadget on the English Wikipedia, so it should be fairly straightforward for interface admins on your wiki to add it, now. The extension itself is enabled on dewiki, as evidenced by de:Spezial:Version. MusikAnimal (WMF) (talk) 18:58, 6 November 2018 (UTC)
I'd like to see this. But what I want is what this tool does, as Default.Mautpreller (talk) 19:16, 6 November 2018 (UTC)
If you have JS code already, you can just create a gadget for it and make it on by default. I don't have rights to do this for you, but check the history of de:MediaWiki:Gadgets-definition. These editors should know how to set it up. Hope this helps, MusikAnimal (WMF) (talk) 19:32, 6 November 2018 (UTC)

To be clear, for me, no, I want the toolbar described on the left, that allow me to customize buttons, for instance to add templates I decide are useful for me (or bits of text I use on a regular basis). Not the piece of shit of vector toolbar (or so-called "Enhanced editing toolbar") which is 98% useless and not accessible (I don't want to make n clicks to get what I need). Rhadamante (talk) 19:26, 6 November 2018 (UTC)

Exactly. Its nice, that the charinsert-problem, that occured at the same time mw.toolbar was removed, is kind of fixed now thanks to Itti. However, the default 11-button-toolbar was highly customisable via the popular monobook.js from PDD and that's what we want to work again without any fiddling around. --Eloquenzministerium (talk) 19:34, 6 November 2018 (UTC)
Now I tried CharInsert on English Wikipedia. It is much worse than the old special characters list because it neither considers the conventions of punctuation and typography in European languages nor permits to choose "Scandinavian" or "Romanian" or "French" special characters. You always have to resort to "Latin", that does not help in the least. Moreover, I'd still like to have the accustomed buttons for signature, link, and so on. My problem is not so much the design but the usability. The "enhanced editing toolbar" is very disturbing since you cannot simply see what you are doing in the wikitext (esp. setting of links). But this is less important than the special characters list. This is virtually unusable in the "enhanced editing toolbar" and with CharInsert it is still much worse than before.Mautpreller (talk) 19:36, 6 November 2018 (UTC)
Charinsert (as I understand it) has nothing to do with the old toolbar. From mw:Contributors/Projects/Removal of the 2006 wikitext editor#Alternatives it would seem you can bring back the toolbar right now. You just need an interface admin to do it for you. French Wikipedia apparently has done this. Try turning on the "ForceMonobookToolbar" preference in fr:Spécial:Préférences. Does that accomplish what you want? MusikAnimal (WMF) (talk) 19:42, 6 November 2018 (UTC)
Also the Charinsert config is community-defined at en:MediaWiki:Gadget-charinsert-core.js. So you should be able to configure it however your wiki desires. MusikAnimal (WMF) (talk) 19:46, 6 November 2018 (UTC)
@MusikAnimal (WMF): It offers the possibility to rewrite entirely my edit bar, since the old code does not work, event with the ForceMonobookToolbar. It's very annoying, but it's something. But I don't see this possibility on Commons, where I did most of my contributions these last few months... Rhadamante (talk) 22:08, 6 November 2018 (UTC)
  • Normal editing interface also allows customisation, see mw:Extension:WikiEditor/Toolbar customization. Last open panel for you is remembered, so there’s no basis to say that you have to ‘make n clicks to get what you need’. stjn[ru] 19:43, 6 November 2018 (UTC)
Wiki loves strategies to scare off users... --DaizY (talk) 19:49, 6 November 2018 (UTC)
MusikAnimal, I don't think you understand me. So I try to put it as straightforward as possible. With the accustomed preferences (I did not even know that it was an "editor") I got two things: the "toolbar" with the 11 grey buttons above and the list of special characters below. This was very comfortable. Suddenly I saw that none of both features appeared any more. A bug? No, obviously a feature. It was suddenly impossible to do an edit with, say, Scandinavian letters or German quotation marks. It was also impossible to sign an edit as accustomed. This happened at the same time and I understand that the reason why the special character list disappeared is that the toolbar was disabled. I am still convinced that that is the reason.
I am not interested in information technology, software development or things like that. These things are simply tools for me, services that help me to write articles as a volunteer. I am not interested in inserting any lines in a js.page, customizing any tool or anything like that. I need a simple way to use characters and symbols in different languages, no more but also no less. This is made extremely difficult by this change.
When I had finally understood what happened, I tried to change my preferences to "enhanced editing toolbar". However, this is bad, it makes my editing more difficult, which is mainly due to the badly disposed special characters list. Then I saw that de:User:PerfektesChaos offered a solution for the special characters list. I inserted this in my js.page and now this worked again and very fine (much, much better than CharInsert on the English Wikipedia). But it is not the right way to force any user to insert lines he doesn't understand in a page that he doesn't understand. That should be a simple standard preference!
What I ask myself: Why is it necessary to annoy volunteers with such changes that make a lot of things worse for editing? Why do I have to look for people who program things that do nothing else than bringing back usability that in the first place had been destroyed by MediaWiki Developers?Mautpreller (talk) 20:09, 6 November 2018 (UTC)
@Mautpreller: I apologize that I don't know all the answers to your questions. I believe the old toolbar was removed due to maintenance burden and the fact the code was very outdated. The impending removal evidently has been announced since at least May 2017, and also repeatedly in Tech News since then (though apparently it was set back quite a bit). I agree the fact you can't insert special characters is bad. I'm going to guess that part has been resolved, based on Itti's comments (but let me know otherwise). Anyway, I'd love to help you bring your toolbar back, since it seems this is something we can do right now. Did you try the gadget on French Wikipedia? Is that what you all are looking for? Again I do not have rights to set it up, but perhaps Itti can do the editing and I can help guide them. MusikAnimal (WMF) (talk) 20:56, 6 November 2018 (UTC)
Please let me know, when I can help, if rights are lacking, but I am not a computer scientist and unable to write programs. Regards --Itti (talk) 21:06, 6 November 2018 (UTC)
Ok thanks. I'm going to continue discussion on your talk page, Itti. MusikAnimal (WMF) (talk) 21:08, 6 November 2018 (UTC)
@MusikAnimal: No, this part has been resolved thanks to this tool. But this should be a standard preference, not something you have to insert in a js-page. Itti's edit did bring back a special characters toolbar, but it is much worse than the old one. Only the PerfektesChaos tool restored the full functionality. A gadget by another user brought also back the toolbar so now the damages caused by the change are repaired by means of individual troubleshooting (for which I am grateful to these users). For me. But not for a lot of other users who will have to do the same procedure as I. I can't believe that this is the purpose of software development.Mautpreller (talk) 21:15, 6 November 2018 (UTC)
Yes it looks like DaB. is in the middle of deploying the old toolbar. This can be made the default, so that it will come back for everyone. I'm going to let DaB. do their thing before checking back and seeing if there's anything I can do to help. I am sorry for all the trouble. I can't speak for the responsible parties regarding the loss of the 2006 toolbar, etc., because I was not involved, but I do know they meant no harm :) I'm glad to hear we're getting it sorted out without having to wait through the whole survey (initially I was under the impression we'd have to write a gadget from scratch). So hang tight, and I'll help ensure this is resolved ASAP. MusikAnimal (WMF) (talk) 21:27, 6 November 2018 (UTC)

(BK)

Mautprellers point is very well taken. I've customized my toolbar days befor it vanished to further fine-tune it to my needs. That also is far from uncommon in de:WP as we have an excellent and well maintained all-in-one-framework by PDD to do so. Taking that away by surprise, as it was only discussed in places where non-nerds just don't hang out, was a Bad Move™. You should keep in mind; Wikipedia continues not to collapse mostly thanks to a surprisingly small group of highly experienced users. Hampering their ability to work with the tools that have been available to them for years (the only ones back then) and painstakingly fine-tuned to their specific needs, is not exactly the way to stop the decline in participation.
Let's deal: We'll forget all the Bad and the Ugly about the VE and you keep the UI the way it was and still is very much appreciated by no less than 45 users on this list[4], who either contributed here, at least tried until evicted or added their name to be informed of the beginning of the voting process within eight hours of the start of this request.
Applying the typical ratio of 1 to 10 between users complaining vs. those equally annoyed, but not bothering to voice their opinion in this galaxy far away from their primary goal of writing articles in peace, that's quite a lot.
Lets end with a little poem, offering one more solution:

Die Lösung (frei nach Brecht)

Die Arbyterschaft
Hat sich das Vertrauen der WMF verscherzt
Und kann es nur durch verdoppelte Arbyte
Mit komplett untauglichen Werkzeugen zurückerobern.
Wäre es da nicht einfacher,
Die WMF löste diese Gemeinschaft auf und
Wählte sich eine andere?


The solution (inspired by Brecht)

The community
Has failed its duty to trust the WMF
And may only by doubling its efforts
With completely inadequate tools get it back.
Wouldn't it be easier,
If the WMF dismissed this community and
Elected a new one?


--Eloquenzministerium (talk) 21:33, 6 November 2018 (UTC)

Once again: We are not talking about a new wish, be are talking about something the WMF has done without anyone whishing. And we experiance staff members misusing their possiblities to censor again and again. --Eingangskontrolle (talk) 09:22, 7 November 2018 (UTC)

Yes, Whatamidoing (WMF), we had better be clear. What I am missing is not mw.toolbar, it is the Edittools toolbar that looked like:
Standard Ä ä Ö ö ß Ü ü • „“ ’ ‚‘ “” ‘’ «» ‹› »« ›‹ – • + − · × ÷ ≈ ≠ ± ≤ ≥ ² ³ ½ * † ⚭ # * ‰ § € ¢ £ ¥ $ ¿ ¡ ∞ • … → ↔ ← •   [] [[]] | {{}} ~~~~ • ° ′ ″
and I used it all the time, especially to insert the „“ apostrophes and the – dash, which are not on the keyboard. It was configured here. --Neitram (talk) 09:52, 7 November 2018 (UTC)

A similar issue is also ongoing in French Wiktionary. After I read this thread, I made some tests and the panel with phonetic signs is broken, visible but the javascript used to include on click, and nothing happen now. So I tried Wikicode editor 2017 but plenty signs are missing, including the curved apostrophe used in French Wiktionary ’ and the IPA sign ʁ, used in French language transcription. So, now, it's more complicated to add pronounciation or to write a decent page in French Wiktionary. -- Noé (talk) 10:29, 7 November 2018 (UTC)

I am missing both, toolbar and Edittools. This change is maybe hiting only a few users, but it hits the power users of Wikipedia. --J. Patrick Fischer (talk) 13:28, 7 November 2018 (UTC)
Few users is a big underestimation. At bgwiki 2/3 of the active editors were completely blocked for a day, the rest were busy to find javascript workarounds. We had an editor with 100k+ edits and 12 years of experience who was unable to sign in discussions. --Nk (talk) 16:25, 7 November 2018 (UTC)
Few users are affected by the removal of the 2006 wikitext editor (=the blue-gray toolbar). Some whole communities are affected by old gadgets that make the EditTools character inserter. So, for example, the French Wiktionary needs to fix their gadget, but the French Wikipedia's gadget had no difficulty; the German Wikipedia's CharInsert/EditTools gadget was broken, but the German Wikivoyage's is still working. Other than wishing for global gadgets – which is much too big of a project for the Community Wishlist, unfortunately – I don't see any good solution to the ongoing problem of communities installing local gadgets that they can't support and maintain. I am, unfortunately, expecting this problem to become more and more significant during the next couple of years.
Noé, the 2017WTE and the visual editor share a special characters line, and you should add whatever's commonly used to it. This is separate from the need to fix the broken gadget, but it should still be done. See mw:VisualEditor/Special characters for instructions on how to do that. Whatamidoing (WMF) (talk) 17:58, 7 November 2018 (UTC)
I don't think we have the full information about all the related problems. In our case (bgwiki) it was exactly about "the blue-gray toolbar", as its removal blocked even most basic operations (adding links, etc.) for dozens of regular users. It took us about a day to restore it within a gadget (compared to "only" few hours to fix EditTools). I can only imagine the impact on the really small wikis without own local technical support. --Nk (talk) 18:32, 7 November 2018 (UTC)
Is the (native) Bulgarian keyboard one of the layouts without square brackets? I know a few keyboards don't include tildes (~), which makes it difficult for some editors to sign their comments.
Congratulations on getting the gadget installed. If you're not already subscribed to m:Tech/News, then I recommend reading it. Whatamidoing (WMF) (talk) 00:43, 8 November 2018 (UTC)

First of all thanks to whoever added the previously censored names of endorsers back to this thread. It might be a good ideas to add the names of those, who escaped the censorship attempt by writing more than +1 to underline the massive support for this proposition.

Bienvenue aux amis du Wiktionary français and welcome to our bulgarian colleagues, who had to work in emergency-mode, very much like the de:WP, to come up with a duct-tape and baling-wire-solution in order to fix this irreponsible move. Over time, more projects will probably find their way here to voice a justified opposition to this inappropriate course of action.

 
We need to talk…

In order to avoid this kind of mishap in the future, I would like to amend the proposal as follows (Deutsche Fassung im Problemhamster-Abschnitt bei FzW): There needs to be a binding rule in the appropriate place to enforce a public discussion of UI-modifications, in particular removals of functions. It has to be an explanation in the local language comprehensible by the average user, that details all the practical consequences of the planned change. By default, this post has to be made at the Villagepump, in case of de:WP, that's de:WP:FZW, with an additional mention in de:WP:Kurier right column. Each language version should be free to redirect such requests for comment to locally fitting places. Should there be no consensus, there must be enough time and ressources to solve the issue at hand appropriately before committing the change. --Eloquenzministerium (talk) 04:49, 8 November 2018 (UTC)

Hi all, the purpose of the Community Wishlist Survey is to generate and vote on proposals for technical projects that the Community Tech team can work on next year. This page has turned into a vehicle for protest of an unrelated product change, which is not appropriate for the Community Wishlist Survey. I've moved this proposal to the Archive. All of you are welcome to post new proposals that ask for a technical feature or fix that the Community Tech team can work on. Please let me know if you have questions about how to participate in the Wishlist Survey. -- DannyH (WMF) (talk) 05:53, 8 November 2018 (UTC)
Another employee is trying to bend the truth and to censor. You (WMF) have changed something without a wish from the community. You just have to undo this. --Bahnmoeller (talk) 08:05, 8 November 2018 (UTC)
The following discussion is closed.

It has been explained time and time again, that this is NOT the place for your grievances. I have moved it to a more appropriate forum, since people seem intent on keeping this on meta.wp, i have chose WM:FORUMTheDJ (talkcontribs) 08:34, 8 November 2018 (UTC)

Are you kidding us? Chaddy (talk) 19:37, 8 November 2018 (UTC)
TheDJ and DannyH (WMF): Please undo this. Really, this is a very bad idea. You inflict great damage on Wikimedia if you autocraticly close and archive this discussion. You should not provoke a conflict with German Wikipedia community. Did the Foundation learn nothing out of earlier incidents like the upload filters, superprotect and so on? Chaddy (talk) 19:40, 8 November 2018 (UTC)

Normalize file extensions & cases

  Withdrawn by proposer (too many proposals)

  • Problem: Today you can have five (or more) totally different files called File:Foo.jpg Foo.JPG, File:FOO.jpg Foo.Jpg and Foo.jpeg on Wikimedia Commons. This confuses people and sometimes results in people adding images into an article that they didn't intend to insert. Also when downloading these files it may cause trouble since some operating systems / files systems don't distinguish between upper and lower case file names.
  • Who would benefit: Wikimedians adding picture to articles and Wikimedia Commons Users categorizing/managing files
  • Proposed solution:
  1. Disallow the upload of files with a filename equal to any existing except for the case and synonym file-extensions (jpg <-> jpeg).
  2. Create a list of all existing such pairs to allow the community to rename them.
  3. Maybe: Automatically rename the file extensions to one format (lowser-case and jpg instead or jpeg) when people upload files with the upload wizard.

Discussion

Recursive search in categories (deepcat) should not fail hard for big categories

  Withdrawn by proposer (too many proposals)

  • Problem: Since this year it is possible to search for articles/pages/files in a given category including all it's subcategory. This has limits for categories with too many pages or subcategories – this is understandable and ok. However if these limits are hit because the category is to big nothing is returned. Instead the search should become more shallow.
  • Who would benefit:
  • Proposed solution: When the limits are hit reduce the number of subcategory-levels that are searched. Instead of seaching 5 levels deep, search then only 4, 3, 2 or 1 level of subcategories deep.
  • More comments:
  • Phabricator tickets:
  • Proposer: MichaelSchoenitzer (talk) 01:04, 8 November 2018 (UTC)

Discussion

Permettre que tout Wikipedia puisse fonctionner en mode visuel

 N Outside the scope of Community Tech Original title: Permettre que tout Wikipedia puisse fonctionner en mode visuel

  • Problem:
    English (translation): Contributor who only write in visual mode and does not understand anything to computing code is often blocked when contributing or using discussion page.

    French (original): Le contributeur qui n'écrit qu'en mode visuel et ne comprend rien au code informatique, est souvent coincé lors de ses contributions ou en page de discussion.
  • Who would benefit:
    English (translation): Hopeless in code people.

    French (original): Les nuls en code.
  • Proposed solution: ?
  • More comments:
    English (translation): For instance in visual mode, how to put a reference inside a reference? How to link a word inside Book template or in infobox? How to complete or edit infobox which don’t display all rubrics which are visible while reading? The same happens to edit a Commons page: everything is coded, I spend one hour to append one line (which don’t erase all other ones), doing one thousand tries + Show preview. Why everything are displayed as code? Currently, unwillingly, I have been switched from visual mode to a coded page, hardly readable where I can’t do what I want. On current page, how to search for an article title to link a word of text I’m writing? And all pages from Help rubric are in computer code too, so they don’t help: we don’t understand anything. Proposed codes at the bottom of the page where I’m writing are like hieroglyphs for people like me.

    French (original): Par exemple en mode visuel, comment mettre une référence dans une référence ? comment mettre un lien sur un mot dans le modèle "Ouvrage" ou dans l'infobox ? Comment compléter ou modifier l'infobox qui n'affiche pas toutes les rubriques pourtant existantes en lecture ? Pareil pour modifier une page de wikicommons : tout est codé, j'y passe une heure pour rajouter une ligne (qui n'annulent pas toutes les autres), en faisant mille essais + Show preview. Pourquoi tout s'affiche-t-il en code ? Actuellement même, sans rien demander, j'ai été basculée du mode visuel sur une page codée difficilement lisible où je ne peux pas faire ce que je veux. Sur la page actuelle, comment rechercher un lien d'un article à placer sur un mot du texte que j'écris ? Et toutes les pages de la rubrique Aide sont aussi en code informatique donc n'aident pas : on n'y comprend rien. Les codes proposés en bas de cette page où j'écris sont des hiéroglyphes pour les gens comme moi.
  • Phabricator tickets:
  • Proposer: Mylenos (talk) 19:10, 5 November 2018 (UTC)

Discussion

Articles for deletion process

 N Proposes a social/community policy change rather than a technical feature Original title: PAS

  • Problem:
    English (translation): More objectivity in Article for deletion process (AfD). Some people do little more than comment with “idem” or unsourced statements.

    French (original): Plus d'objectivité pour les PAS, certains se contentent du commentaire "idem" ou d'affirmations non sourcées.
  • Who would benefit:
    English (translation): Contributors concerned about a less subjective equity on AfD.

    French (original): Les contributeurs soucieux d'une équité moins subjective sur les PAS.
  • Proposed solution:
    English (translation): While AfD, notify people who participate in project to which the article is part of, even if they haven’t contributed to the page.

    French (original): Lors de la PAS envoyer un avis de PAS aux participants du projet correspondant à la page même s'ils n'ont pas participé à la page en PAS.
  • More comments:
  • Phabricator tickets:
  • Proposer: Amage9 (talk) 13:22, 4 November 2018 (UTC)

Discussion

@Amage9: Salut, est-ce que tu peux expliquer "PAS" stp? C'est "Pages à supprimer"? --AKlapper (WMF) (talk) 13:51, 6 November 2018 (UTC)

@AKlapper: Oui c'est bien Page à supprimer.--Amage9 (talk) 14:46, 6 November 2018 (UTC)

As far as I can tell, this is about reducing subjectivity at discussions about article deletion. This is not a technical problem so unfortunately Community Tech can't help :( As such I am archiving this. Thanks for the proposal, nonetheless! MusikAnimal (WMF) (talk) 19:31, 8 November 2018 (UTC)

Add most common tags in available tag list

 N Outside the scope of Community Tech

Original title: Ajouter les balises les plus courantes dans la liste des balises disponibles

  • Problem:
    English (translation): I wish several example tags among most common ones were added in list of available tags, at the bottom of Wikipedia edit page. For instance: <ref>{{Web link|title=|url=|site=|visited on=}}</ref> tag, or <ref>{{Article|newspaper=|writer=|title=|subtitle=|publisher=|place=|date=|read online=}}</ref> tag, or <ref>{{Book|writer=|title=|subtitle=|publisher=|place=|date=|isbn=|total pages=|page=|read online=}}</ref> tag, etc. (markup which are tedious to write down). Ideally, we could personalize by ourselves the tags we often need, and they would append to already existing tag list.

    French (original): Je souhaite que l’on ajoute de nombreux modèles de balises parmi les plus courantes dans la liste des balises disponibles, en bas de la page « Modification d’un article de Wikipedia ». Par exemple la balise <ref>{{Lien web|titre=|url=|site=|consulté le=}}</ref>, ou la balise <ref>{{Article|périodique=|auteur=|titre=|sous-titre=|éditeur=|lieu=|date=|lire en ligne=}}</ref>, ou l’an balise <ref>{{Ouvrage|auteur=|titre=|sous-titre=|éditeur=|lieu=|date=|isbn=|pages totales=|page=|lire en ligne=}}</ref>, etc. (balises qui sont fastidieuses à rédiger). Il serait même idéal qu’on puisse préparer soi-même les balises personnalisées dont on a besoin souvent, et qui s’ajouteraient à la liste des balises déjà existantes.
  • Who would benefit:
  • Proposed solution:
  • Phabricator tickets:

Discussion

  • You need to ask your local wiki about this. This is not something CommTech needs to help with. --Izno (talk) 01:36, 6 November 2018 (UTC)
  • We need more clarification but I suspect they're talking about adding things to the current list of tags at the bottom of the edit page (e.g. see [5]). This is configurable by local admins at fr:MediaWiki:Edittools. MusikAnimal (WMF) (talk) 19:42, 8 November 2018 (UTC)
    Eh, I'm going to take a stab in the dark and say that is what this is about. I'm going to archive as out of scope, but if I'm wrong, please revise the proposal and move it to the Editing category. MusikAnimal (WMF) (talk) 19:45, 8 November 2018 (UTC)

Force contributors to write an edit summary

 N Proposes a social/community policy change rather than a technical feature

Original title: Obliger les contributeurs à écrire un résumé de leur contribution

  • Problem:
    English (translation): I wish to write an edit summary was mandatory before submitting it. This would let have a better global view on article edits, and above all it would force contributors to justify their edit pedagogically, avoiding savage reverts without explanation.

    French (original): Je souhaite qu’il soit obligatoire d’écrire un résumé d’une contribution avant de la valider. Cela permettrait d’avoir une meilleure vision globale des contributions d’un article, et surtout cela obligerait les contributeurs à justifier leur contribution de manière pédagogique, en évitant les suppressions sauvages faites sans explication.
  • Who would benefit:
  • Proposed solution:
  • Phabricator tickets:

Discussion

  • This is not something CommTech can help with. You need to talk with your local wiki about whether contributions should have an edit summary forced on users (hint: they probably won't take your suggestion). --Izno (talk) 01:35, 6 November 2018 (UTC)
  • Indeed, this is more of a social change than a technical one. If your wiki does decide it wants to enforce edit summary usage, you could use fr:Special:AbuseFilter to do it, or author a simple gadget. MusikAnimal (WMF) (talk) 19:49, 8 November 2018 (UTC)

Allow non one-to-one correspondence relationship in wikidata and display them in interlanguage link

  Withdrawn by proposer (too many proposals)

  • Problem: In the following cases, wikidata cannot provide inter language link information:
    • When there are multiple articles (written in different scripts or such) exists in same wiki project, thus cannot be linked into same wikidata entry due to current limitations
    • When one wiki created an article for broader concept however another wiki only created article for smaller subdivided concepts and thus they cannot be linked together directly
    • When one wiki created an article for concept A, and then another wiki created an article for concept A', where each of them are related and the detail of the subject of the other article are more or less introduced in the page, however they cannot be linked into same wikidata entry as both A and A' have their separate wikidata entry
  • Who would benefit:

All wiki users that use interlanguage links

  • Proposed solution:
    • Enable input of multiple values for same language in each wikidata entry
    • When there are wikidata statement that claim close relationship between two different wikidata items, or when there are explicit properties for wikidata items saying it should be the case, display interlanguage link from other wikidata items in wiki UIs
  • More comments:

In case it's not clear enough, the proposal cover the following situation:

    • Enable linking multiple pages for same language for the same wikidata item (possibly with statement about nature of each of those links)
    • Enable display of inter-language link from multiple different wikidata items for any given wiki page
    • Enable relating information of different wikidata entries
  • Phabricator tickets: T54564 and many others
  • Proposer: C933103 (talk) 13:16, 30 October 2018 (UTC) [Please adopt this proposal if you can.]

Discussion

  • I think it would be better (than to allow linking multiple articles on a wiki to the same item) to (1) label pairs or groups of items as not having one-to-one relationships; (2) establish a way to link redirects on the relevant wikis to those items. In general, Wikidata items are supposed to represent singular concepts; (to use the typical example) it wouldn't really make sense to link both qqq:Bonnie Parker and qqq:Clyde Barrow to Bonnie and Clyde (Q219937), because items already exist for Bonnie Parker (Q2319886) and Clyde Barrow (Q3320282). Having three separate items, with one item to represent the pair, makes it much easier to represent data for each of those things in Wikidata (e.g. dates of birth; what those items actually represent – human (Q5) and duo (Q10648343)), at the expense of requiring redirects for interwiki links. Jc86035 (talk) 15:36, 30 October 2018 (UTC)
    • If you are talking about the first sub-point, then that is referring to situations when there are multiple articles created on same wiki for exact same concept, unlike what you describe which would fit the other sub points more. I am not saying that a single approach should be adopted for all these situations but that different approaches should be developed to resolve all these different problemsC933103 (talk) 20:12, 30 October 2018 (UTC)
      • @C933103: I forgot about the permanent duplicated items. For those the current solution is clearly not as useful, but I would think it would be best to only allow some number of sitelinks for wikis with multiple versions (e.g. hak-Hant:台灣 and hak-Latn:Thòi-vân), with that number being the amount of language variants. Jc86035 (talk) 11:40, 31 October 2018 (UTC)
    • Bonnie and Clyde is not a typical example but an exceptionally clear case. Life isn't that easy. We have en:Concentrated solar power with very few interwiki links and de:Sonnenwärmekraftwerk (solar thermal power) with lots of interwiki links. Both articles are mainly about the same (concentrating) types but the latter also includes non-concentrating designs, which are of low importance and mentioned in the English article only under ==See also==. So it's not the very same concept, but nevertheless, all those articles should be interwiki-linked. --Rainald62 (talk) 20:46, 30 October 2018 (UTC)
      • @Rainald62: In that case I would think the solution (with the current software) would still be to create redirects like w:en:Thermal solar power station and link them to the other item, if both concepts are covered within the same item. However, I have proposed d:Wikidata:Property proposal/also display sitelinks for, which would probably be helpful (I have no idea why this property doesn't exist yet). Jc86035 (talk) 11:40, 31 October 2018 (UTC)
      • I think merging en:Concentrated solar power and de:Sonnenwärmekraftwerk into a new item, and marking them with two different colors could be a solution. --Leiem (talk) 15:43, 1 November 2018 (UTC)
        • What about when, for example, if a random small Wikipedia created article for both items already? Do you think it's better to merge both of them together, or do you think it is better to keep them as separate while items in both wikidata items get linked across? Both methods would be helped by improvement requested in this proposal. C933103 (talk) 05:08, 3 November 2018 (UTC)
    • Unlocking the ability to link a Wikipedia redirect to a Wikidata item would really help, but I understand that such a change does not have consensus at Wikidata. enwiki has been forced to implement a workaround, which works when the Wikidata label matches a redirect to the correct topic, but it causes bad links when the label matches an unrelated topic or a disambiguation page or a redirect to either of those. Certes (talk) 15:42, 8 November 2018 (UTC)
      @Certes: The RfC on allowing sitelinks to redirects was recently closed with consensus to allow sitelinks to redirects (see d:Wikidata:Project chat#Inclusion of redirects, the post-RfC thread). Jc86035 (talk) 16:11, 8 November 2018 (UTC)

Tool for property creation

  Withdrawn by proposer (too many proposals)

  • Problem: The property creation process it is very cumbersome and it requires a lot of manual work
  • Who would benefit: Mainly property creators, but also property proposers since their proposals would be processed more efficiently.
  • Proposed solution: Improve the template so that it can be filled out as the resulting property. Create a tool to automatically create the property based on the information provided and notify the participants of the discussion.
  • More comments:
  • Phabricator tickets:
  • Proposer: Micru (talk) 10:43, 7 November 2018 (UTC)

Discussion

Use map for Nearby

  Merged with Community Wishlist Survey 2019/Reading/Show nearby or related articles in maps

  • Problem: Special:Nearby is not really useful in its current form – it displays a list with some articles, but the user can neither broaden the area nor select a completely other place (or select any place if the browser doesn’t have the necessary API).
  • Who would benefit: Users not having the Android or iOS app who want to use Nearby + users of other Wikimedia project with no app: Wikidata, Wikivoyage, etc.
  • Proposed solution: Use a map on Special:Nearby (or let the user chose between the list and map format).
  • More comments:
  • Phabricator tickets:
  • Proposer: Original proposal in 2017 by Tacsipacsi. Ayack (talk) 18:05, 8 November 2018 (UTC)

Discussion

  • This sounds a lot like Community Wishlist Survey 2019/Reading/Show nearby or related articles in maps the other way round. --AKlapper (WMF) (talk) 12:51, 9 November 2018 (UTC)
    @AKlapper (WMF): Indeed, I haven't seen it before. This one seems more "concrete" to me (especially since it's not mine initially) but I can withdraw it if Mike Peel wan't to keep his own. Ayack (talk) 15:15, 9 November 2018 (UTC)
    @Ayack: I wouldn't want to pick one of the two, as both would be useful, and they are quite related. Maybe we could merge? I could add "Ideally this functionality could also be used in w:Special:Nearby to show a map of nearby objects rather than a list" somewhere in the other proposal? I'd prefer to merge that way as I think showing the feature in embedded maps would be much more visible (and hence more likely to be widely supported) than showing the feature only on a special page. Thanks. Mike Peel (talk) 15:46, 9 November 2018 (UTC)
    @Mike Peel: Sounds fine for me. I let you merge it and I withdraw this one. Thanks. Ayack (talk) 17:13, 9 November 2018 (UTC)

Video player should allow playback at multiple speeds

  Withdrawn by proposer (too many proposals)

  • Problem: Videos can only be played at one speed. For skimming information, faster is nice. For watching things that move too fast to see (or typing in Commons:Timed Text subtitles) slower would be nice.
  • Who would benefit: Anyone who wants to view a video at another speed without downloading it.
  • Proposed solution: Allow speed to be set as a multiple of standard speed.
  • More comments: This might fit well with an ability to edit subtitling online through the Commons interface, which could improve accessibility.
  • Phabricator tickets: task T174393
  • Proposer: HLHJ (talk) 02:23, 31 October 2018 (UTC)

Discussion

I would like to withdraw this proposal as it has met with no interest and will just clutter the vote. Also, I have a better third idea, if I'm allowed that... HLHJ (talk) 17:04, 10 November 2018 (UTC)

I was interested, but had nothing to add. Anomie (talk) 01:21, 11 November 2018 (UTC)

Lightroom to Commons upload

  Withdrawn by proposer (too many proposals)

  • Problem: To improve file handling of images to commons, to create a direct export from Lightroom to Commons
  • Who would benefit: Photographers and users of Lightroom
  • Proposed solution: Export software patch or addon for lightroom
  • More comments:
  • Phabricator tickets:
  • Proposer: :JarrahTree (talk) 10:55, 10 November 2018 (UTC)

Discussion

@JarrahTree: Something like LrMediaWiki? Thanks. Mike Peel (talk) 12:56, 10 November 2018 (UTC)

thanks for the link Mike. :JarrahTree (talk) 04:44, 11 November 2018 (UTC)

Allow the style of map tiles to be specified when using maplink or mapframe

  Withdrawn by proposer (too many proposals)

  • Problem: The WMF produces two different styles of map tiles - one featuring labels and one without (although this does include some labels at the highest zoom levels). Maplinks and mapframes use the style with labels. It should be possible to specify the style of the map tiles when creating a maplink or mapframe map - just as you can now specify the language used for the labels.
  • Who would benefit: Editors looking for a clean basemap to place data (e.g. ExternalData from OSM) on top of. Readers would experience a cleaner, nicer map.
  • Proposed solution: Allow the style of the map tiles to be specified.
  • More comments: Wikivoyage already allows different styles of map tiles (and overlays!) to be swapped on the fly.
  • Phabricator tickets:
  • Proposer:

Discussion

Map marker improvements

  Withdrawn by proposer (too many proposals)

  • Problem: There should be a way to use "marker clusters" - when zoomed out, closely adjacent markers are placed into groups; clicking the group zooms in and expands the group into individual markers. Additionally, the current marker design can be clumsy - allowing multiple styles would enable editors to pick the appropriate style for the task at hand.
  • Who would benefit:
  • Proposed solution: Finish deploying marker clusters and provide a way for editors to disable it when it might be inappropriate. Provide a way for the community to add/use different styles of markers.
  • More comments:
  • Phabricator tickets:
    • Should we use the marker cluster plugin with `<mapframe>` and `<maplink>` ? (T136455)
    • Customize map markers in Kartographer (T131618)
  • Proposer:

Discussion

Map zoom and positioning improvements

  Withdrawn by proposer (too many proposals)

 
Ugh...
  • Problem: Map positioning and zooming functionality is broken in some situations.
  • Who would benefit: Editors would save time by not needing to establish and specify coordinates and get better and more consistent results.
  • Proposed solution: Fix the bugs listed below.
  • More comments:
  • Phabricator tickets:
    • Remove map offset when quitting full screen mode (when screen > 1024px) (T161065)
    • On the mobile site, <mapframe> autozoom doesn't work when data is drawn on top of the basemap and the sections of the page are autocollapsed (T192250)
    • Automatic zoom and positioning doesn't work for geomasks (T178370)
    • Autopositioning and autozooming behaviour of geomasks is different from that of geoshapes and geolines when using multiple Wikidata IDs (T160889)
  • Proposer:

Discussion

Consolidate full-page view caption and attribution UIs

  Withdrawn by proposer (too many proposals)

  • Problem: There are three (!) separate pieces of UI that all essentially do the same thing: display caption and attribution information when viewing full-page media content. These are Media Viewer - used on the desktop site, a Media Viewer clone - used on the mobile site, and Kartographer's full-page view - used when viewing maps. A particular problem is the very poor handling of captions by the image and maps viewers on the mobile site.
  • Who would benefit: Readers would get more consistent experiences when viewing media content. Developers wouldn't have to maintain three different designs of wheel.
  • Proposed solution: Merge the two image viewers and adapt the relevant components to the map viewer.
  • More comments:
  • Phabricator tickets: T65504 & T197735
  • Proposer:

Discussion

Sectional page protection

  • Problem: For protections, the admin have no other option than protecting the whole article while vandalism or disruptive editing is usually limited to only a small part of the article.
  • Who would benefit: Admins and the community
  • Proposed solution: Finding an easy solution that makes it possible to protect only a specific section or sections of an article. For example en:Jack Kevorkian shows that most unwelcome editing is in the lead and the infobox (calling this born and bred American an Armenian). The limited protection of this article will prevent unwelcome editing in these sections while leaving the rest of the article open for editing.
  • More comments:
  • Phabricator tickets: T121172
  • Proposer: The Banner (talk) 14:04, 6 November 2018 (UTC)

Discussion

  • This is probably out of CommTech scope given how much work would be required for it. --Izno (talk) 19:06, 6 November 2018 (UTC)
    • Honestly, I have no idea how difficult this is. But I have learned in life that the stupidest question is the one you do not ask. The Banner (talk) 19:53, 6 November 2018 (UTC)
  • If a vandal can't edit one section, they can vandalize others, or, worst case, just surround the protected section with comments, hiding it and replacing it with their own content. "Section" is just an element in wikitext to HTML translation, they're too fluid to be practically protectable. MaxSem (WMF) (talk) 06:18, 7 November 2018 (UTC)
  • Hmm, if I get the argumentation correctly, it could also be used as an argument to propose per-sentence protection levels, I'd say? I don't think this scales. :) --AKlapper (WMF) (talk) 12:48, 9 November 2018 (UTC)
    • No, per paragraph/infobox/table is good enough. The Banner (talk) 17:18, 11 November 2018 (UTC)

Archived

Sorry, this is just technically not possible to do reliably. MaxSem (WMF) (talk) 18:42, 13 November 2018 (UTC)

Move references to Wikidata

 N Proposes a social change rather than a technical feature

  • Problem: References in citations are a mere hack. They are not a free text and they do not belong to the article's body. In fact, they are fairly structrured, language independent (the citation is a citation in any language: you just need to control/change the format - which should be done automatically anyway) and consist a piece of information on their own (hence: the standalone bibliographies, bibliographical indices, research desks at libraries etc. exist).
    What is most important, the references as we know them cannot be easily copied between projects / language versions because of different formats of reference citing (stemming from the hack nature). I don't find a reason for keeping redundant references in articles and projects and having them in the main text of the articles (or even worse, in wikicode of templates, infoboxes etc.).
  • Proposed solution: We should try to merge the set of scattered references, have a single database of them and provide all the projects' writers and readers with a single, unified repository of references. Single repository should reduce the redundant work and give a single stop for users (just like Wikimedia Commons is for images, but this one should be much easier to create). This repository would allow the editors to just references to these objects on their local projects, like Polish Wikipedia or French Wiktionary.
As it happens, Wikimedia have already a database/datawarehouse/structured data project: Wikidata. References should be uploaded there as particular items, so they can be reused, easily searched and copied with cut&paste. This needs to be done ASAP, as the current use of references is purely nonsensical. At the moment, the hackish nature of citations generates a dramatic waste of resources in e.g. manhours, makes the re-use difficult and creates an artificial barreer for new editors (who IMHO expect a reference as an object in 2018).
  • Who would benefit: anyone editing Wikipedia and sister projects, Wikidata, people looking just for references, in future: automatic content generators
  • More comments:
  • Phabricator tickets:
  • Proposer: aegis maelstrom δ 09:49, 10 November 2018 (UTC)

Discussion

  • @Aegis Maelstrom: I included some similar things in my proposal, although I felt it was far too soon to propose actually moving all references to Wikidata. I want this to happen, but there are all sorts of issues (many social) with getting Wikipedia editors to create Wikidata items in order to write articles, including issues with connecting the right author, publisher or publication to the item (especially if the item doesn't exist, or if there are multiple items with the same label – although this could be partly solved by creating new properties for "publisher string" and "publication string"), and with convincing the 100,000 regular Wikipedia editors that they should all partake in doing this – you would have to figure out how to edit Wikidata just to fix a source, and some people just don't need or want that in their lives. The software, data and infrastructure would have to be amazing for it to work at all (inline item search, creation and editing in all three of the existing wikitext editors and in VisualEditor, all publisher items correctly classified and separated from their publications, automatic fixes to items that are blank except for the URL). I'm not sure how realistically achievable it would be, given the vast number of sources used, the smaller but still quite large number of references which aren't formatted correctly, and the even smaller but fairly large number of references which shouldn't even be being used as sources. And you would have to be able to handle page numbers (within articles, presumably), and articles which use alternate citation styles (an extreme example). Jc86035 (talk) 18:17, 11 November 2018 (UTC)
    Hi @Jc86035:, I am aware it will not be supereasy, especially because of the social factor but let's face it: the current way of doing citations is ugly and we cannot be hostages of some small minority who will be willing to do everything in a wikicode. Firstly OFC I would make it a possibility, and yes, the proper solution on WikiData needs to be prepared. This is why I propose to do it in a systematic way (as all the other partial solutions, like translators of citation templates between e.g. language versions of wikis are yet another layer of hacks at best). Badly formatted references are a problem on their own but they are a late phase of migration; in the end I presume there still would be _some_ indices/subtexts in the articles, as not all of them are citations. I have learned about this Wikidata project but it is still quite initial. Anyways, I think this issue is important, needs to be highlighted and solved with proper resources. aegis maelstrom δ 19:19, 11 November 2018 (UTC)
    @Aegis Maelstrom: (I've linked this page from my proposal in a footnote.) After thinking about it a little, I think this (or at least the moving-the-data part) could probably be done within a few months, as long as most Wikipedia editors are on board with it. The things that still seem concerning to me are the pace of software development (which would be a prerequisite to avoid disrupting everyone's workflows massively) and whether Wikipedia editors would actually want it. Jc86035 (talk) 18:16, 12 November 2018 (UTC)

Archived

Unfortunately, our team will not be able to work on this proposal as it's mostly about wikis' content policies. Thanks for participating in our survey. MaxSem (WMF) (talk) 20:21, 13 November 2018 (UTC)

Changing the BASEPAGENAME of multiple sub-pages

  Proposes an existing feature

  • Problem: It is impossible to edit the BASEPAGENAME of multiple sub-pages with current features, I would have to rename each sub-page directly one-by-one to the corrected BASEPAGENAME.
  • Who would benefit: Editors
  • Proposed solution: Introduce a feature that does the above.
  • More comments:
  • Phabricator tickets:
  • Proposer: Aumars (talk) 15:05, 11 November 2018 (UTC)

Discussion

  • It sounds like you may be proposing something that already exists: if your account has the "move-subpages" right, a checkbox "Move subpages (up to 100)" is available on the move form to move a page and all its subpages. On Wikimedia sites this right is generally restricted to sysops, although various wikis also grant it to "pagemover"-type groups. Anomie (talk) 15:56, 11 November 2018 (UTC)
    @Aumars: Indeed as Anomie says, this feature is available in MediaWiki, but limited to privileged users as it could be abused. If you feel your wiki could benefit from non-admins having this capability, you could seek local consensus to add a "page mover" user group or something similar, that would give such users the "move-subpages" permission. I'm going to archive this proposal as invalid, but if we've we misunderstood you, let us know and we'll move it back to the survey. Thanks for participating! MusikAnimal (WMF) (talk) 20:30, 13 November 2018 (UTC)

no nowiki in Visual Editor

  • Who would benefit: everyone who uses the Visual Editor
  • Proposed solution: it should not be inserted

Discussion

@Peter Gröbner: Do you have specific steps which would allow someone else (for example a developer) to reproduce the problem? If so, please see mw:How to report a bug. There are already a good number of (mostly fixed) bug reports about nowiki at https://phabricator.wikimedia.org/maniphest/query/uSh..A.pIiWK/#R but there might be more situations that have not been known yet. Thanks in advance! --AKlapper (WMF) (talk) 13:22, 30 October 2018 (UTC)

Just mark a part of an unlinked word in the German wiktionary and then link it. Whole the word should be blue, but since there is <nowiki/> just the marked letters become blue. That's all. --Peter Gröbner (talk) 15:20, 30 October 2018 (UTC)
@AKlapper (WMF): Da du ja auch in der deutschsprachigen Wikipedia aktiv bist, schreibe ich dir jetzt auf deutsch, da ich mich dann vielleicht präziser ausdrücken kann: Ich wollte in der Änderung wikt:de:Special:Diff/6679031 den Plural Minen visuell mit Mine verlinken. Durch das automatisch erzeugte <nowiki/> werden aber nur die ersten vier Buchstaben Teil des Links, was unschön aussieht und der im Wiktionary gewohnten Praxis widerspricht. Gruß, Peter Gröbner (talk) 15:24, 30 October 2018 (UTC)
PS: Ich bin ein großer Freund der Visuellen Bearbeitung und benutze sie, wo immer es geht. Allerdings bin ich auch nach meiner Erfahrung derzeit der einzige ständige Mitarbeiter im deutschsprachigen Wiktionary, der (auch) visuell arbeitet. Die Unmöglichkeit der Erzeugung von Links der Gestalt [[Wort]]zusatz zwingt mich aber oft dazu, zur Quellcodebearbeitung zu wechseln. Verlinke ich das ganze Wort rein visuell, wird in obigem Fall der Pipelink [[Wort|Wortzusatz]] erzeugt. Gruß, Peter Gröbner (talk) 15:40, 30 October 2018 (UTC)
I think this is discussed in task T128060. Kaldari (talk) 05:18, 31 October 2018 (UTC)
Thank you for the link. I think I will be going on producing pipelinks like [[Wort|Wortzusatz]] which can be shortened to [[Wort]]zusatz if anyone likes to do. Greetings Peter Gröbner (talk) 07:42, 2 November 2018 (UTC)
Summary: This is what happens if you type the trailing characters outside of the blue "cartouche" (i.e., visibly outside the blue link area). This is desirable if you want to link the first bit of a word, but not the rest. (For example, in an article discussing prefixes: `Cisplatin and Transplatin are examples of cis–trans isomerism`). If you type them inside the blue area, then you will not see a nowiki tag (and your label will be piped).
I think this should be withdrawn from the wishlist, because it is working as designed. Whatamidoing (WMF) (talk) 20:33, 2 November 2018 (UTC)
I had understood the difference before, yet I think that unnecessary pipelinks are not well appreciated in the wiktionary. Nevertheless I will use them in the future and refer to this discussion if criticized. Greetings and thanks, Peter Gröbner (talk) 06:44, 3 November 2018 (UTC)
  • This proposal has been archived since the proposer received a satisfactory solution in the discussion. AEzell (WMF) (talk) 21:57, 13 November 2018 (UTC)

Enable two-factor authentication for all wikis

  Withdrawn by proposer (duplicate of Available 2FA for All CONCERNED Editors)

  • Problem: Security is at risk for all users, especially where unauthorized attempts are made to log into users accounts without their knowledge.
  • Who would benefit: All users and staff who edit Wiki(p/m)edia websites.
  • Proposed solution: To implement two factor authentication consisting of a code sent via a secondary method such as a verified email, SMS to cellphone or a preselected key to make login security stronger.
  • More comments:
  • Phabricator tickets:
  • Proposer: DaneGeld (talk) 17:20, 10 November 2018 (UTC)

Discussion

@Izno: - You're absolutely right, it is. I put it here under miscellaneous cause all the other categories didn't look right for it. It's not a bot, it's not a gadget, it's a change to the MW software which IMO doesn't fit in the other categories! But I'll support that one instead :) This one is withdrawn. DaneGeld (talk) 19:28, 10 November 2018 (UTC)

SVG editor - a new editor for graphics - with a visual mode and a textual mode

 N This proposal is too big

  • Problem: Currently there is no online SVG editor in the complete WikiMedia system.
  • Who would benefit:
    • Firstly the editors of SVG graphics, which will be able to work mobile on simple graphics or online on complex graphics.
    • Secondly all users of the Wikipedia, because most probably there will be much more new SVG graphics created.
  • Proposed solution:
    • Create a new editor for SVG graphics, which provides a visual mode as well as a textual mode and an additional preview mode.
    • Building concept - firstly create rapidly a simple functional version of this editor and secondly enhance it continuously in further versions.
    • Advert this SVG editor to all editors, to let the user community of this editor rise rapidly and in the course of time even more and more.
  • More comments: In my opinion it is already urgent to build this SVG editor.
  • Phabricator tickets:
  • Proposer: Sonne7 (talk) 16:39, 4 November 2018 (UTC)

Discussion

I have a lot of reservations about creating editors for every single type of content within MediaWiki. It's a huge amount of maintenance overhead and requires a very wide scope of knowledge upon the developers. Why is there no online editor that could easily upload to Wikipedia/Commons ? —TheDJ (talkcontribs) 10:07, 6 November 2018 (UTC)

Do you know such an online SVG editor? If so, please tell me, that I can check its suitability for the WP/C and its features - thank you in advance. -- Best regards, Sonne7 (talk) 18:43, 6 November 2018 (UTC)
@Sonne7: Well Google brings up http://www.clker.com/inc/svgedit/svg-editor.html for instance. —TheDJ (talkcontribs) 08:41, 7 November 2018 (UTC)
@Sonne7: mw:Extension:SVGEdit exists (no idea in which state it is, though), and phab:T40271 is about reviewing that extension. Would that be a potential path forward to this proposal? --AKlapper (WMF) (talk) 14:40, 7 November 2018 (UTC)
@TheDJ & @AKlapper (WMF): Thanks for the two variants with the links to them - interestingly both SVG editors are really the same tool, only in different versions.
  • The 1st is the Google version, it has a better detailed layout on the screen, but a very bad functionality, i.e. selection, grouping and zooming does not work properly and additional the local saving of the created SVG image does not work (therefore the saving is only possible via cut&paste from the content in the SVG code view to an other text editor on my local PC).
  • The 2nd is the 'mw:Extension:SVGEdit', which is mainly only a reference to the Github version (https://svg-edit.github.io/svgedit/releases/latest/editor/svg-editor.html), which lacks in the detailed screen layout, but the minimal needed functionality (circle, rectangle, selection, grouping, copying, etc.) seems to me to be mostly working correctly, including particularly the local saving of the created SVG image.
Therefore I would prefer to use the mostly working Github version (I could not find the number of this version) as the generally base for the development of the full working online SVG editor and partially using the detailed screen layout from the Google version (although I found no number of this version) as source for the enhancing of the screen layout for the development of the full working version.
Hope that a (nearly) full working online SVG editor will be available in the near future, to get the possibility to work online or even mobile on SVG graphics for the Wikipedia. -- Best regards, Sonne7 (talk) 08:37, 8 November 2018 (UTC)

Archived

Sorry, this project is too big for our team that would also need to work on 9 other proposals. Thanks for participation in our survey. MaxSem (WMF) (talk) 22:10, 13 November 2018 (UTC)

Avoid generating artifacts in article content versions

 N Proposes a policy/cultural change rather than a technical one

  • Problem: The different editors, Visual editor (VE), tag editor (TE), users, or bots behave differently as to (non-functional) spacing between tags.
  • Who would benefit: All moderators, and peer reviewers
  • Proposed solution: Please decide on a single strategy on "== style ==" or "==style==" constructs regardless on what the author typed, or the VE or TE or bot decided to generate.

    The VE sometimes decides to generate additional non-functional spacing e.g. between subsequential categories (some users type categories into one large sequence of categories on one single line instead of on multiple lines). The VE splits a table into multi-line | constructs instead of one-row || columns. The VE sometimes adds or removes leading or trailing spaces before or after table cell || or parameter | separators. All this leads to artifacts in the stored version of the wiki text. I honestly believe we require to standardise non-functional spacing (that has zero effect on the rendering; it only concerns internal code) much like e.g. Microsoft Visual Basic does. Duplicate and trailing spaces could be removed as well before storing tag text.

  • More comments: Additional advantages: The version side-by-side difference view would be much smaller. No more artifacts would appear. Peer reviewers and moderators would no longer be distracted by non-functional spacing.
  • Phabricator tickets:
  • Proposer: Geert Van Pamel (WMBE) (talk) 16:51, 4 November 2018 (UTC)

Discussion

  • The One True Way isn't going to get any support. You might consider other proposals to put forth. --Izno (talk) 01:28, 6 November 2018 (UTC)
  • Can editing tools simply avoid adding or removing any optional items, leaving the page with whatever spacing it had before (even if inconsistent), so we can see the real changes more clearly? Certes (talk) 23:35, 6 November 2018 (UTC)
    They try, typically. --Izno (talk) 00:34, 7 November 2018 (UTC)

Archived

Our team wouldn't be able to work on this proposal as it's primarily about setting community standards while we're a technical team first of all. Thanks for participating in our survey. MaxSem (WMF) (talk) 22:12, 13 November 2018 (UTC)

Voice to text editor

 N This feature already exists

  • Problem: Contributing for those on small devices like smart phones and for those sight impediments
  • Who would benefit: Smart phone users, sight impared
  • Proposed solution: create a tool that enable a person to turn voice into text, that stores the wording on subpage of the article so that them or other contributors can add the content to the page after checking spelling, grammar. This would encourage people using smart devices to contribute more to wikipedia.
  • More comments: It can be recorded as an audio file with the text conversion being done in the background when server time is available rather than increase system demands, by having a two process it'd help avoid it being used for vandalism. it also enables attribution to the individual contributors
  • Phabricator tickets:
  • Proposer: Gnangarra (talk) 00:44, 9 November 2018 (UTC)

Discussion

@Gnangarra: Sounds similar to Community Wishlist Survey 2019/Editing/Make Wikipedia more accessible to the visually impaired? --AKlapper (WMF) (talk) 12:57, 9 November 2018 (UTC)

  • this is for a broader use to also improve the ability of mobile, smart device users with poor keyboards to be able to contribute. When read the other one later I realised the similarities in themes but this has smaller focus as an input tool for a broader reach, wider use and different impact. I know there a good easily accessible braile readers for vision impaired people. I know those are propriety software with purpose built hardware. this only software orientated with built in specifics solely needed to contribute to wikipedia. Gnangarra (talk) 13:07, 9 November 2018 (UTC)

Most mobile devices already have voice-to-text built in to the keyboard, which is likely going to be much better than anything we will be able to build. ESanders (WMF) (talk) 13:33, 13 November 2018 (UTC)

Archived

Both Android and iOS already have voice input, while adding it to other platforms (as well as adding support for languages not already supported) would be a too big project for us. Thanks for participating in our survey. MaxSem (WMF) (talk) 22:17, 13 November 2018 (UTC)

Communication plattform between devs and editors is needed

  • Problem: The communication between "the devs", i.e. WMF, WMDE e.a., and the core of the wikiverse, the power editors, has to be restored. As can bee seen with the desaster created with the deprecation of the toolbars and other edit helps here, there was a nearly complete lack of meaningful communication between the devs, that wanted to get rid of some old piece of software, and the core editors in some wikipedias, that relied heavily on this piece of software. The devs were fine with there announcements in some techie parts of the wikiverse (Phabricator, Tech News), but that's no place normal users will ever go, let alone understand the usual nerdy gibberish used by the regulars there. Once the devs made their change, the backlash set in and a lot of normal editors were very angry about this unresponsible sudden death of the much needed tools. Especially as it was nowhere announced, where normal editors go.
  • Who would benefit: The Wikiverse, as the core and backbone are the power editors that have to be kept onboard.
  • Proposed solution: Create a Meeting Point, were any proposed change to the UI/UX has to approved beforehand by the editors, and were the devs have to use normal understandable language, not geek-talk.
  • More comments:
  • Phabricator tickets:
  • Proposer: Grüße vom Sänger ♫(Reden) 13:51, 8 November 2018 (UTC)

Discussion

  • @Sänger: What would "approved by the editors" mean? Would one wiki be able to prevent a software change on all other wikis? Would there be a request for comment on Meta for every software change? (I think it would be reasonable if limited to user-facing changes to non-beta software, but that would still be several RfCs per month.)

    Of the tens of thousands of regular enwiki editors (as an example), many never touch the noticeboards/RfCs and focus on writing articles, so even if there were such a communication platform there would still be a vast majority of editors who wouldn't know about something until it breaks (it's probably impossible to create a noticeboard where "normal editors" go, since the "normal editor" probably doesn't regularly look at noticeboards). Maybe a better solution would be to have WMF staff send notifications directly to users affected by certain breaking changes, if the privacy policy allows it (talk page messages probably wouldn't be possible because user preferences aren't public). Jc86035 (talk) 16:26, 8 November 2018 (UTC)

  • As you can see in my example, with the disastrous ditching of a heavily used tool without proper consultation of the users of this tool, by simply assuming something in the detached ivory tower called WMF, the current procedure is severely broken. Software changes are discussed mainly in some dev-only venues, in a language nobody but hardcore nerds properly understand, and this is designed to create evil. The software is there to support the content, not the other way around. Those dealing with content are to be supported, and their working surroundings need be designed according to their wishes. Of course you will never reach out to each and every power editor, but software developers are mainly maintainers of the Wikiverse, and they have to search active for feed-back and support for their ideas, in a language ordinary editors are able to comprehend. If there is no support for the idea from the non-devs, it's a dead idea. Of course security and such are not what we are talking about, but the daily tools used by the power editors. Grüße vom Sänger ♫(Reden) 17:04, 8 November 2018 (UTC)
  • Sänger Hello. Thanks for submitting a proposal. The meeting point you mention in the proposal - do you see that as something on a particular wiki or on multiple wikis or outside wikis? -- NKohli (WMF) (talk) 20:38, 8 November 2018 (UTC)
  • It could be a central venue like here, but the devs (Or some special department at the WMF, there is more then enough money in the heavy coffers of the WMF to maintain proper contact with the bosses, the community. That's more important then new gadgets or shiny bling.) should have the duty to make any such far reaching change for the usability like the one mentioned here aware in every wiki in a language that is understood there usually (i.e. propably not english) and a manner, that non-nerd could comprehend what will come. Wikitexteditor 2006 is something nobody outside some inner circle of devs will know about, so that phrase has to be explained. The editors are, after all, the very people the maintenance squad in WMF and WMDE and whatever else should support, as they are the ones that create the very essence of the wikiverse: content. Without content the wikiverse is nothing. Without new gadgets the wikiverse will still grow. Bots are not an answer to content creation, those, who dream about that, should be ditched asap. Grüße vom Sänger ♫(Reden) 20:57, 8 November 2018 (UTC)
  • Okay. I want to point out that the Community Wishlist Survey is for technical projects the Community Tech team can do. This is a social change that is outside the scope of Community Tech. This is something that needs to happen on a bigger scale with the entire community and Wikimedia Foundation's consent. With that in mind, I am inclined to archive this proposal. Thanks for flagging this nonetheless because it surfaces an important need and I will make sure it does not go unnoticed by others at WMF. -- NKohli (WMF) (talk) 22:15, 8 November 2018 (UTC)
  • This is about the implementation and especially consultation of technical projects, one just went terribly wrong because the devs failed in their assessment of the problem completely. This is about Community Tech, i.e. the interaction of the community and the obviously severely detached techs in the WMF. Community Tech should be the team, that is the interface between the community and the techies. They have to provide this venues and go to the projects to explain the proposed changes and ask for input, if anything is proposed top down, instead of the correct way of bottom up in a community driven and lead project. Grüße vom Sänger ♫(Reden) 22:32, 8 November 2018 (UTC)
  • There is no technical work involved here, as far as I understand. We (Community Tech) is already working with the community in our work but it is beyond our power to change the way other teams work. Community Tech can only work on focused technical tasks which have consensus. -- NKohli (WMF) (talk) 01:26, 9 November 2018 (UTC)
  • This has been discussed before: "One place" won't be good enough. Editors can't handle leaving their own wikis. They can't even handle watching a page on their local wikis for tech news or subscribing on their user talk pages. If they can't do that much, they 100% won't be able to handle going to one place for their technical news. (JDL or JR or one or another of those sorts has had this discussion before if someone wants to ping them here.) --Izno (talk) 00:30, 9 November 2018 (UTC)
Sänger: Again, the Community Wishlist Survey is not the place for protests about WMF staff conduct. -- DannyH (WMF) (talk) 22:49, 13 November 2018 (UTC)

Available Text to Speech for all wiki Articles

  • Problem: Available Text to Speech for all wiki Articles (Wikispeech extension). Let the articles talk when Required.

    A 2016 study estimated that a quarter of Wikipedia users, or 125 million per month, need or prefer their text read aloud to them. Making all of the websites which use MediaWiki more accessible to those who find it hard to assimilate written information is therefore incredibly important.

  • Who would benefit: It'll make wiki's more accessible to users with disabilities who may have trouble reading text on their screens.
  • Proposed solution: 1. "Wikispeech" is a text-to-speech tool (in Beta) to make Wikimedia's projects more accessible for people that, for different reasons, have difficulties reading.

    At first make it available for en wikipedia . then asign more developer so that it can have cortana/siri/google assistant like "precise accent" & "natural voice".then make this extension/api integrate with mediawiki software.

And please make the voice more NATURAL like THIS "Cortana,Alexa" or "Google Assistant".

2. Google text to speech api is licenced under apachi 2.0 . Is it possible to ask them to make a github fork with CC/GFDL licence only for official wiki project, cause this proposal also HUMANITARIAN ?.......They have natural-sounding speech with 30 voices, available in multiple languages and variants.

  • More comments:
  • Phabricator tickets:

Discussion

@Ahm masum: Also see Community_Wishlist_Survey_2019/Editing/Make_Wikipedia_more_accessible_to_the_visually_impaired which is very related / maybe could even be merged? --AKlapper (WMF) (talk) 13:19, 13 November 2018 (UTC)

@AKlapper (WMF): PLEASE , DO MERGE. THANKS. --Ahm masum (talk) 14:44, 13 November 2018 (UTC)
I will close this proposal in favor of the other one, if that's okay! Thanks Ahm masum. -- NKohli (WMF) (talk) 22:54, 13 November 2018 (UTC)

Anti-vandalism tool for patrollers and reviewers

 N Proposes a social change that needs wide consensus before it can be developed

  • Problem: The blocking of vandalising users, as well as the deletion of their nonsense articles, requires admins, who are not always available.
    Deutsch: Das Sperren von Vandalierenden Benutzern, sowie das Löschen ihrer Unsinns - Artikel erfordert Administratoren, welche nicht immer zur Verfügung stehen
  • Who would benefit: Users who remove vandalism.
    Deutsch: Benutzern, die Vandalismus entfernen
  • Proposed solution: Rollbackers should be able to suggest IP (and maybe newly registered) users for blocking at on a special page, through which they are blocked until an admin makes a decision or fifteen minutes pass. It should be possible to let the form you fill in when blocking be filled in in advance. There should also be a similar function for deletion. Prior to admin decision should the rollbacker also be able to undo these actions.
    Deutsch: Zurücksetzer sollen über eine Spezialseite unangemeldete (und eventuell neue) Benutzer zur Sperrung vorschlagen können, wodurch diese gesperrt werden, bis ein Administrator eine Entscheidung vornimmt oder 15 Minuten abgelaufen sind. Das Sperrformular soll dabei schon vorausgefüllt werden können. Außerdem soll es eine ähnliche Funktion für das Löschen geben. Vor der Adminentscheidung sollen diese Aktionen auch von den Zurücksetzern rückgängig gemacht werden können.
  • Further comments:
  • Phabricator tickets:

Discussion

I've translated this from the original German, but kept the original below my English translation. /Johan (WMF) (talk) 12:34, 2 November 2018 (UTC)

  • Honischboy Hello. Thanks for your proposal. I want to point out that this wish is a social/community change before a technical one. I don't know if the communities will be happy with giving rollbackers the right to block users who don't normally have that power. it can be misused in several ways - people may repeatedly block someone for 15 minutes or block people when they don't agree with them. I can see this tool be useful but there is also potential for misuse. -- NKohli (WMF) (talk) 23:57, 8 November 2018 (UTC)
FF-11 Per my above comment, this proposal is a big social change and we won't be able to work on it as a Community Tech project. Giving blocking rights to non-admins is something that wikis need to agree to, before we can build it. I am going to have to decline this project. Sorry about that. We can reconsider this wish next year, if there is a prior wiki-consensus and discussion about this feature. Thank you for your time. -- NKohli (WMF) (talk) 23:04, 13 November 2018 (UTC)

A course on Wikipedia similar to ones on Coursera or EdX

 N Not a technical proposal

  • Problem: Learning about the intricacies of Wikipedia is difficult for a new editor and sometimes the process is discouraging and very slow. Navigating Wikipedia policies, guidelines and essays takes time, and mistakes by new editors increases the workload of older editors. Also, learning about Wikipedia can be made more fun, structured and efficient through such an online course for Wikipedia like the ones on Coursera (https://www.coursera.org/) or edX (https://www.edx.org/). A proper course with videos, quizzes, interactive elements, the history of Wikipedia and basic help navigating wikipedia for future editors, how the largest volunteer community in the world works, how things are resolved on controversial topics, so many things can be covered sequentially. The course can cover the whole of Wikipedia as well as WikiMedia, Commons, Wikidata etc and how all the other Wikis are part of the larger Wikipedia universe.
  • Who would benefit: All new editors, prospective editors and for those just curious about wanting to know more about Wikipedia itself. It would also provide an educational platform for teachers across the world to teach their students about Wikipedia in a more thorough and structured way.
  • Proposed solution: A course on Wikipedia on Coursera or Edx.
  • More comments: I know that Wikipedia – The Missing Manual and WP:The Wikipedia Adventure exists. But The Wikipedia Adventure would need to be expanded and updated extensively to cover this idea, it also doesn't cover the other wikis. I understand that there are other more experienced editors who help clear things out when there is a confusion related to how Wikipedia works, Talk pages are there as well as the TeaHouse etc.
  • Phabricator tickets:
  • Proposer: DiplomatTesterMan (talk) 02:58, 10 November 2018 (UTC)

Discussion

  • This doesn't seem like a technical wish. --Izno (talk) 16:10, 10 November 2018 (UTC)
Opps, sorry. I read the intro page more carefully. This isn't technical. I've shifted this to Village Pump. Thanks. DiplomatTesterMan (talk) 11:20, 11 November 2018 (UTC)

Correct date format on Wikidata

  Incorporated into Community Wishlist Survey 2019/Wikidata/Date handling improvements – additional precision and correction of translations in interface

  • Problem: Wikidata uses DMY for dates in all languages. It’s right in German, OK in English (though many people prefer MDY), but unacceptable in many other languages, like Chinese or Hungarian, which use exclusively YMD dates. For example, Wikidata started on 29 10 2012 on Wikidata, while 2012年10月30日 on zhwiki. (The exact date is not important now, only the format.) It says 29. október 2012 in Hungarian, which should be 2012. október 29. using proper format. This is especially confusing for dates in the first thirty years AD—1. január 2 means 0001-01-02 for most readers, but 0002-01-01 for the software. For day-precision dates, $dateFormats can be used, but other precisions are also problematic. For example, the inception of Hieronymus Bosch’s Christ Carrying the Cross is 1500s in Hungarian, because it’s impossible to translate it in the current environment: it should be 1500-as évek, 1510-es évek, 1520-as évek, …, 1900-as évek, …, 1990-es évek, 2000-es évek, …, 1 000 000-s évek, …, 1 000 000 000-os évek etc. (the vowel is different, or even omitted; it can be described using an algorithm, but not using just {{PLURAL:}}).
  • Who would benefit: All Wikidata users whose language doesn’t use DMY date format.
  • Proposed solution: Use proper date format for all languages.
  • More comments: It was already proposed last year (by Samat), with moderate support.
  • Phabricator tickets: T63958 (seems to focus on full dates)
  • Proposer: Tacsipacsi (talk) 15:59, 11 November 2018 (UTC)

Discussion

  • @Tacsipacsi: I already requested this in one of my proposals. Perhaps it would be beneficial to merge them, because of the rule that only the top ten proposals will certainly be looked at. Jc86035 (talk) 16:08, 11 November 2018 (UTC)
    • @Jc86035: I searched for “date” and haven’t found such proposal. I think your proposal is too broad, for example, I would support more precise dates, but don’t see calculated properties that important. By creating such a mega-proposal, you make sure it will end in top ten, but also make sure Community Tech will no time for further wishes for sure. They promise to work on the top ten, but in fact not the number counts, but the amount of work, so if smaller wishes win, it’s more likely that they will work on other wishes as well. —Tacsipacsi (talk) 17:10, 11 November 2018 (UTC)
      @Tacsipacsi: It is almost guaranteed that there are going to be very large wishes by others (for example, those to improve Maps and Page Curation and New Pages Feed), so it doesn't really make sense to do small proposals when only ten are to be selected, especially with the Facebook-esque voting system. There's also a good chance (I think) that Wikidata work will be handed off to another team or to WMDE. The "calculated properties" ticket was not added by me and I don't think it's that important. Jc86035 ([[User talk:|talk]]) 17:26, 11 November 2018 (UTC)
      @Jc86035: OK; although I don’t like this giant proposal, I accept it. Please incorporate my proposal in yours. —Tacsipacsi (talk) 19:10, 11 November 2018 (UTC)

@Tacsipacsi: If my proposal is not taken out of the archive by tomorrow, perhaps it would be appropriate to un-archive this one. Jc86035 (talk) 09:43, 15 November 2018 (UTC)

Create a magic word to check category inclusion for previous page version

 N This proposal is unclear

  • Problem: Many times we need a way to know in which category the page is included, for better templates creation.
  • Who would benefit: Everyone who writes templates.
  • Proposed solution: It will be very nice to create a magic word to check if the page is included in particular category. But it is not done, and from good reason, it's very dangerous. A mutual recursion may create a lot of problems. For example, template A adds the page to category B if it is in category C, and template D adds the page to category C if it is in B. So, the right solution for me is to check the previous page revision. So, we should have {{#wasincategory:<category name>}}, which will return logical true iff the page was in the named category in previous revision, does not matter what is the state now. This way the recursion will be broken, and we'll have good answers. For absolutely right answers we can in the worst case to add some space character at the line end, for example, forcing a new revision.
  • More comments: Of course, it will be always false for the creation version.
  • Phabricator tickets: None.

Discussion

While this might avoid recursion you now have to consider the whole version history. Let's say the second revision of an article added such a statement, we are now at the 632th. The 632th revision includes a check which category was included in the 631th revision. To figure that out we have to parse it. But that includes again such a check - to fully parse it we also need the 630th revision, and so on until we parsed all 632 revisions. Sure, you could store the categories somewhere separately to avoid that. How would this work with templates? If you use #wasincategory in a template, which revision is used when? This looks complicated. Do you have an example for an application? --mfb (talk) 03:52, 4 November 2018 (UTC)

Hello and thank you. Well, of course the previous version categories list should be stored physically and not computed each time. What is different with templates? Magic words are parsed in there as in any other place. So it will happen according to the version of the parsed page. Can you give an example where it can cause any problems? And what do you mean in "Do you have an example for an application?"? IKhitron (talk) 11:25, 4 November 2018 (UTC)

Archived

This proposal is too confusing for us to put it up for voting. It completely misses the use cases for this feature, for example. Even if this would have been clarified, a table storing all historical categories for every page would have grown extremely big for very little benefit. MaxSem (WMF) (talk) 01:02, 14 November 2018 (UTC)

Timeline in maps

 N Too big for Community Tech

  • Problem: We do have Kartographer extension implemented now and maps are much better than before. But they still lack one basic dimension - TIME. Especially in articles about historic empires, you don't have single defined boundaries. They change overtime. But there's no efficient way to depict that at present.
  • Who would benefit: Everyone using maps.
  • Proposed solution: Add time dimension. User can navigate via lat, LNG, and zoom, add time and the map will be much better.
  • More comments:

Discussion

@Capankajsmilyo: I think this would work better with the Graph extension. OpenStreetMap is a database of what currently exists and things that have been demolished are deleted entirely, so I don't think this would be suitable for Kartographer. (And then with the Graph extension this would end up being out of scope because it would be a request for Community Tech to create the content.)

The Graph extension is already capable of producing interactive content, although I have never seen it used that way in a live Wikipedia article. Jc86035 (talk) 17:09, 31 October 2018 (UTC)

Wikipedia and wikidata community is capable enough to create the content themselves. We just need the tech capability. Capankajsmilyo (talk) 17:17, 31 October 2018 (UTC)
@Capankajsmilyo: It's already possible to create animated using Extension:Graph, is what I meant. (I originally assumed you wouldn't draw the actual boundaries on the Kartographer map because you could zoom in and see all of the inaccuracies.)
If the areas are drawn using geoshapes and stored on Commons, then I think a timeline would be interesting for this, although probably not for maps with only a few individual geoshapes. (It is already possible to show multiple lines and areas – geolines and geoshapes – in a Kartographer map, and each object can have its own colour and pop-up description.) Jc86035 (talk) 18:26, 31 October 2018 (UTC)
Enwiki currently uses Template:Maplink and <mapframe> to add maps, besides pics from commons and enwiki. Are you saying that we can already add timeline in Template:Maplink or <mapframe> using Graph extension? Capankajsmilyo (talk) 18:39, 31 October 2018 (UTC)
@Capankajsmilyo: I meant that the Graph extension could (probably) make a timeline on its own, not by interacting with Maplink or Mapframe. (I don't really understand the Graph extension because I've never had to use it, but there are interactive demos on the MediaWiki wiki.) Jc86035 (talk) 18:44, 31 October 2018 (UTC)
That is why I suggested to use Kartographer so that it can interact with Maplink and mapframe. Capankajsmilyo (talk) 18:46, 31 October 2018 (UTC)

This sounds as if you want the ability to swap out the background tiles and replace them with a historical map. Wikivoyage can already swap out the tiles and can also overlay things on top of the tiles. I've added an example at my userpage. But when loading a page, it seems to always default to the WMF tiles. So it seems you're asking for the ability to specify an image and use that to create the map background. Gareth (talk) 00:14, 2 November 2018 (UTC)

Let me try to clear the confusion with an example. See the above two images. The are both just lines and coloured background on basic map of India.   Check this out now, it's also a few lines on basic map of India but navigable with latitude, longitude and zoom. I was suggesting of getting the ability to draw lines and overlay Color on map, at different years and then use a simple scroller or other tool to navigate through years. So when I navigate to 375AD, I see the first map Colors and when I scroll to 450AD I see the second one. Now imagine 100s of such boundaries mapped on a single map through 1000s of years. Capankajsmilyo (talk) 02:20, 2 November 2018 (UTC)

Another example, Haryana was formed on 1 November 1966. So these boundaries should disappear when user scroll beyond that year or the scroller should be limited to 1966 and ahead for this one. Just like we can limit the extent of map in Maplink template. Capankajsmilyo (talk) 02:28, 2 November 2018 (UTC)

See mw:Extension:Graph/Interactive_Graph_Tutorial for an example of an interactive graph. Drag the slider to see how world wide fertility rates changed between 1960 and 2013. —TheDJ (talkcontribs) 14:35, 2 November 2018 (UTC)

For historical map data (rendering it on Wikimedia sites aside) there is the Open Historical Map project. It aims to duplicate the OSM structures, but add time attributes to every feature so that the map as it was at any point in history can be retrieved as desired. Sam Wilson 00:48, 14 November 2018 (UTC)

Archived

Unfortunately, this proposal is too big for our team to work on, considering that there will be 9 other proposals next year. Thanks for participating in our survey. MaxSem (WMF) (talk) 00:45, 14 November 2018 (UTC)

Add Admin functionality to mobile sites

  • Problem: Every day more and more users (including admins) use the mobile version (e.g. [6]) of Wikimedia sites. As today, there is no simple way of doing basic admin functions (deleting, blocking) on the mobile site.
  • Who would benefit: All admins, specially those who doesn't have full time access to desktop computers.
  • Proposed solution: Modify the mobile interface to include admin functionality. Changes could include, but are not limited to:
  1. Easier access to Special Pages (including Recent Changes and such) on the "main menu" (three horizontal lines on the left superior corner)
  2. A "block" button somewhere on the User namespace
  3. A "delete" and a "protect" button somewhere on all namespaces
  • More comments:
  • Phabricator tickets:

Discussion

Hi Ninovolador. Thanks for your proposal! I think it will help if you can expand on what admin functionality would you like to see implemented on the mobile site. -- NKohli (WMF) (talk) 18:32, 30 October 2018 (UTC)

Have you tried the Timeless skin? It is mobile friendly and may already be able to provide the requested functionality at least partly. I believe the same group is working on making other desktop skins more mobile friendly as well. Gryllida 22:12, 30 October 2018 (UTC)

Gryllida In fact, the Timeless skin provides what i want. Sadly i have to use it on the desktop site (in my case [7]) as well, but it isn't currently possible to use Timeless skin on the mobile site ([8]). Also, the Timeless skin isn't the most suitable skin for Wikisource on the desktop, as we need as much horizontal space as possible, for proofreading.
NKohli (WMF) I will update my description. --Ninovolador (talk) 12:12, 31 October 2018 (UTC)
Ninovolador you can adjust the timeless skin to hide the sidebar. I would suggest to query its developers about it. Gryllida 08:35, 12 November 2018 (UTC)
Hi Ninovolador: There's currently a product team working on adding Advanced features for mobile contributions; you can see all of their plans and progress on that page. I'm going to archive this proposal, since the features that you're asking for are already being worked on. Please ping me if you have any questions. Thanks for participating in the survey! -- DannyH (WMF) (talk) 01:15, 14 November 2018 (UTC)
DannyH (WMF) I have only one question. I've reviewed the page you linked, but found nothing on adding admin functionalities to the mobile front-end. Do you have information that they are in fact working on that? --Ninovolador (talk) 10:32, 14 November 2018 (UTC)
Ninovolador: You should ask them on their talk page; they'll be happy to learn more about what you need. -- DannyH (WMF) (talk) 20:29, 14 November 2018 (UTC)

Centralised language independent wikiproject for modules and templates

  • Problem: Modules and templates are spread across all language editions of Wikipedia. This leads to lots of issues in their maintenance.
  • Who would benefit: Tech community and other Wikipedians
  • Proposed solution:
    • There should be a central repository over which language wikis can build upon. Just like there is for pictures (Commons).
    • That central repository should be transcludable, like we use modules to build templates.
    • That central repository should be language independent so that language wikis can customise them with their languages and preferences.
    • This could be an additional layer over Phabricator, which is an amazing project in itself.
    • Modules can be migrated to and centralised in commons mediawiki rather than a namespace in various wikipedias.
  • More comments: Previous wish at Community Tech/Central repository for gadgets, templates and Lua modules. I am 100% sure that such a proposal was there on meta before and has several phab tickets, but I'm unable to locate them now.
  • Phabricator tickets: T121470, T66475, T206060, T208437

Discussion

@Capankajsmilyo: This duplicates Centralized templates and modules, which was archived for being out of scope. Jc86035 (talk) 12:50, 31 October 2018 (UTC)

In the last comment, I found "Anyway, if we're just talking about setting up an extension to contain global modules (probably not also templates), and not implementing these modules, then this might be feasible for us", so I created this one. Additionally, I propose it to be a basic structure rather than the full template, as different language wikis behave differently. I think these two are distinctive enough characteristics to make a proposal. Capankajsmilyo (talk) 12:58, 31 October 2018 (UTC)
As written, this proposal still suggests a catch-all place to add global templates and modules. That's okay though, we can reword it. From what I was told talking to other smart people, templates in particular probably is too much work. Modules, which drive the functionality of many templates, is a maybe. Perhaps ערן would be interested in helping reword this proposal? I think "Convert top 5 used Lua modules (across all wikis) to an extension" is a good start. I don't know how the modules would be editable without developer intervention (doesn't have to be WMF devs), but Lua people are in a sense "developers" too, so maybe this is okay? Or we could somehow get them to show up on Commons? The latter sounds a lot like the "shadow namespaces" concept that failed to gain traction. I'm interested to hear Eran's (User:ערן) and Anomie's thoughts. Historically anything "global" has not gone well for us :( MusikAnimal (WMF) (talk) 22:30, 4 November 2018 (UTC)
I'm ambivalent about "Convert top 5 used Lua modules (across all wikis) to an extension". If people want to do that, it's certainly doable, but as noted having to go through Gerrit and the MediaWiki deployment train might be considered "too much" by the people who currently develop modules on-wiki.

Shadow namespaces would likely be the technology behind a real solution to this proposal. I leave it to Community Tech to decide whether taking that on would be in their scope and resources. Personally I'd recommend against making Commons the repository, though, as the community on Commons is geared towards media files and adding a huge new scope seems likely to be rough. Anomie (talk) 15:20, 5 November 2018 (UTC)

It could be very useful for Wiktionaries, for verbs conjugation for example. A similar need was expressed last year, focused on Wiktionary: Share conjugation (among other things) templates on www.wiktionary.org   Noé (talk) 17:16, 1 November 2018 (UTC)

Reposting my comment from the other proposal: I think that this proposal has an important social issue: Who is going to exercise editorial control on the modules and templates? The community that hosts the repository or the communities that use it? An edit to the repository might break pages on another project and that will lead to conflict if there is no regulatory process. If people apply a lot of local opt outs to avoid this problem many benefits of the central repository will be negated and a lot of work will be spent at making the opt outs. Jo-Jo Eumerus (talk, contributions) 09:30, 2 November 2018 (UTC)
Proposals for new projects doesn't seems to be within scope of community tech survey.C933103 (talk) 08:28, 9 November 2018 (UTC)

@Capankajsmilyo: We are going to close this proposal in favor of the very similar Shared Multilingual Templates and Modules available to all wikis. They are both discussing the same problem, but that proposal doesn't mention creating a new Wikiproject, which as C933103 mentions, would be outside the scope of Community Tech. It doesn't necessarily mean that we would follow their proposed solution, but we thought it would be better to choose the proposal that doesn't suggest a specific solution in the title (especially a solution that we wouldn't be likely to accomplish). Ryan Kaldari (WMF) (talk) 01:35, 14 November 2018 (UTC)

Intra-template VisualEditor

 N Outside the scope of Community Tech

  • Problem: When editing in VisualEditor and you click on a parameter-supporting template, you are suddenly faced with the peculiar juxtaposition of wikitext within the VE. This is most frustrating when you are working with Infoboxes (inserting wikilinks, citations, nested infoboxes), Succession Boxes, and reference aggregating templates like {{Refbegin}}. This seems to defeat the whole purpose of the VE, which is to allow editors to edit without having to know the intricacies of wikitext. Currently, it is precisely when the wikitext can be the most complex that VE shuts off and the wikitext returns.
  • Who would benefit: Any editor that uses VE to edit templates
  • Proposed solution: Devise a solution whereby VE can accommodate templates within templates. E.g. having the toolbar present when within a template pane or allow template panes to open on top of other template panes.
  • More comments:

Discussion

  • Personaly I rarely succeed to use the VE for editing template runtime parameters. I switch to the tag editor, where I have more control, and text editing seems to me more easy. Geert Van Pamel (WMBE) (talk) 09:50, 4 November 2018 (UTC)
  • Apparently there's a new extension in beta called TemplateWizard which has, among other things, an auto-complete feature for parameters with the data type "wiki-page-name", allowing users to add wikilinks within a template without having to familiarize themselves with wikitext (see File:TemplateWizard_screenshot_03.png). I believe this is part of what you're looking for? So far it only works in the 2010 wikitext editor, unfortunately. According to this discussion there are currently no plans to add this feature to the Visual Editor, which seems silly to me. Jeroen N (talk) 14:18, 5 November 2018 (UTC)
  • It would be nice if the wikitext would show rendered in the template fields and then it would be possible to edit it with a popup window using VE. No idea if it would be visually too confusing, but it could work.--Micru (talk) 12:03, 10 November 2018 (UTC)
Hi, @Ergo Sum:; we've looked at this wish as part of the preparation for the voting phase, and unfortunately, the blockers for this functionality are above what the team can tackle as part of the wishlist, so we must decline it based on the scope it requires. There's no doubt that this is a great -- and wanted -- functionality, but to make it happen there need to be changes to Parsoid itself (that supports VisualEditor's wikitext parsing) that are not quite trivial and then quite a heavy set of changes to the fundamental way that VisualEditor's template dialog is architected. Unfrotunately, this makes the wish unfeasible and over scope for the team to tackle as part of the wishlist. My recommendation is to revive the Phabricator ticket and see if the VisualEditor and Parsoid teams can suggest timeline for whether this fits in their current work plan. Thank you for participating in the wishlist survey! MSchottlender-WMF (talk) 01:45, 14 November 2018 (UTC)

WikiCite context

  • Problem: current system of ad‑hoc referencing is clumsy, wasteful, and error‑prone
  • Who would benefit: the entire Wikipedia community and academic internet users beyond
  • Proposed solution: prioritize efforts to establish and populate the WikiCite bibliographic database
  • More comments:
    • for background: WikiMedia page, unofficial project landing‑page
    • some, if not most, of the proposals currently listed in this work‑stream would be solved if WikiCite was operational
    • it is imperative, in my view, that all proposals listed on this page be evaluated in light of WikiCite with subsequent resourcing decisions made appropriately
    • see also:[1]
  • Phabricator tickets:
  • Proposer: RobbieIanMorrison (talk) 12:13, 5 November 2018 (UTC)

References

  1. Taraborelli, Dario; Pintscher, Lydia; Mietchen, Daniel; Rodlund, Sarah (2017). WikiCite 2017 report — Version 3. St Petersburg, Florida, USA: Wikimedia Foundation. doi:10.6084/m9.figshare.5648233.  DOI may point to a later version.

Discussion

@RobbieIanMorrison: Could you clarify what "prioritize efforts to establish and populate the WikiCite bibliographic database" means, technically speaking, given the team's scope? --AKlapper (WMF) (talk) 15:35, 5 November 2018 (UTC)

I imagine the Community Tech Team is looking for concrete proposals. Whereas my comment related to context. I'm not involved in WikiCite but from what I've seen, that project should comprehensively address most problems related to bibliographic information and management. It seems to me that it would be a shame to devote effort to firefighting a broken citation system when it is possible to fix the problem in a much deeper way. If the team cannot contribute to WikiCite because it is a "large, long-term development project", then I suggest that most of the citation bugfixes listed here be put on hold and resources deployed elsewhere. Let's keep in mind the big picture. RobbieIanMorrison (talk) 00:31, 7 November 2018 (UTC)
@RobbieIanMorrison: May I suggest something concrete? Because reliable sources have to be independent, I'd really like to see automated linking of sponsors and COIs, similar to that done on PubMed, with this metadata surfaced to editors adding citations and to readers reading them. I've made some COI metadata examples on Wikidata. I've seen way too many Wikipedia articles to fix which cite advertisements formatted to look like journal articles (called "sponsored supplements", and usually under the editorial control of the sponsor). This is a serious and invisible problem on the wikis, and only a source metadatabase can feasibly fix.
I'd also suggest that WikiCite become its own (data) wiki, with fair-use rules allowing them to host abstracts and the full texts of COI statements. This will make it much more useful, and give it a certain independence. It may be that there are good technical reasons from letting it mature further within Wikidata, in which case I would be glad to hear them. HLHJ (talk) 06:35, 10 November 2018 (UTC)
Hi RobbieIanMorrison: Unfortunately, working on WikiCite is beyond the scope of the Community Tech team, so we'll have to decline this proposal. I understand the point that you're making about working on small fixes instead of a big-picture solution. Community Tech doesn't have any particular influence over those larger resource decisions, and if people voted for this proposal, there isn't anything that Community Tech could actually do. If people want specific firefighting fixes, then that's within our scope. I'm going to archive this proposal; let me know if you want to talk more about it. -- DannyH (WMF) (talk) 01:47, 14 November 2018 (UTC)
Hi DannyH (WMF): I am happy with your suggestion to archive my proposal. It was less of a proposal and more of a prompt anyway. Hi HLHJ: I think your suggestion to add COI and advertorial metadata to individual references is excellent. A logical extension would be to track authors using unique identifiers, so other publications by the same author could be interrogated too for conflicts and a wider picture established. The ethical questions would need to be worked through of course. Perhaps the scheme would need to be limited to voluntary ORCID identifiers and similar. Looking forward to progress on all fronts. With best wishes. RobbieIanMorrison (talk) 16:21, 14 November 2018 (UTC)

Collaboration tool

  • Problem: When more people works on one page, they need to talk about some points, make some notices, etc. Now they must use talkpage, but there is problem how to identify the exact part of text. Or they should work with some external service, like google docs where the comment function exists.
  • Who would benefit: Editors, quality checkers, editathoners.
  • Proposed solution: Create some kind of comments for certain part of page, like as here.
  • More comments: This text can be strored in talkpage, but comments should be linked to certain part of text Something like:
    paragraph:1 text_from:256 text_to:288 comment:"Text in the comment for character 256-258 in paragraph (line) 1"

Discussion

Related material: grant proposal for annotation service and a 2017 wikimedia developer summit session as well as the ticket on an inline discussion feature and phab:T89575. With MCR much closer now, there would finally be a more sustainable storage location for this type of wikitext revision derived information. I'd say however that a project like that would be HUGE (think a year or longer) if you want to create it in any sort of sustainable way. Thus likely it is out of the scope of the Community Tech team. It's high on the priority list of several key developers to make systems like these possible in the long term, but it doesn't seem like something that you can slap together in 3 months. —TheDJ (talkcontribs) 08:50, 31 October 2018 (UTC)

This sounds really exciting, however it seems like a big project. I imagine two kinds of scenarios once MCR is ready, one would be annotations, and another one could be forking a version for collaborative live editing with comments, (optional) chat, annotation, etc. and merge it back with the main article once they are finished.--Micru (talk) 11:59, 10 November 2018 (UTC)
Hi JAn Dudík: as TheDJ says, this project is too big for the Community Tech team. However, a separate team is starting to plan for a big talk pages consultation that will start in February. I think this use case is a very interesting one to talk about, as part of that consultation. I'm going to archive this proposal, but please take a look at that consultation page, and let me know if you've got questions. -- DannyH (WMF) (talk) 01:55, 14 November 2018 (UTC)

Create an editor dashboard

  • Problem: Wikimedia projects have no central page from which editors can receive suggestions, guidance, feeds, and notices. I believe such a venue, integrated directly into MediaWiki, could benefit both new and experienced readers, for slightly different reasons.
  • Who would benefit:
Experienced editors: Experienced editors might begin an editing session from one of a number of places, including Special:Watchlist (my personal starting and return-to point), Special:RecentChanges, Special:NewPages, Special:Notifications, or a custom-made dashboard such as Wikipedia:Dashboard or other user-created personal page. Browsing the myriad of special pages takes time and effort, and I haven't yet seen a Wiki-page dashboard that's all that intuitive to use or update.
New editors: New editors receive approximately zero guidance on what tasks are available to them, which pages they might want to edit, or where the relevant help or policy pages they should read are. It's well known that new editors struggle to learn Wikipedia policies, don't find or understand editing processes, and can feel like contributing is an insurmountable task due to the lack of specific, small step, guidance provided to them.
  • Proposed solution: A centralised dashboard useful to both new and experienced editors. It would be customisable, such that power-users could add whichever Special page feeds or other elements they found useful, but have sensible defaults for new editors, prompting them to read certain help pages, contribute to ongoing discussions, or edit pages with maintenance tags. StackOverflow has a nice dashboard (you can see a screenshot, and my brief thoughts, here) which shows, among other things, the progress towards your next user right - something that has an obvious counterpart for some Wikis for rights like Autoconfirmed - as well as the approximate number of views your answers has received - again, presenting approx. pageviews seems within the realms of possibility here. A section for editing a personal to-do list, integrating barnstars more directly (rather than as talk page posts), and a notices area (e.g. Watchlist notices) could also be worthwhile.
I think a dashboard like this could go a long way to improving both new editor retention and providing a powerful tool for experienced editors.

Discussion

  • Actually TheDJ and I were thinking of making this eventually, so this'll probably get done regardless of its wishlist status. Enterprisey (talk) 15:50, 30 October 2018 (UTC)
  • I don't understand what features are being asked to the development team. An editor dashboard page can be easily created by any editor, am I right? --NaBUru38 (talk) 18:31, 7 November 2018 (UTC)
Samwalton9: Unfortunately, this proposal is too broad for the Community Tech team to take on. There are a lot of features included in your description, plus the ability to customize everything. It's just too big for the team, sorry. -- DannyH (WMF) (talk) 01:59, 14 November 2018 (UTC)

Simultaneous editing

  • Problem: It has been a while since the first simultaneous editing system was presented inside MediaWiki, but currently we can't find it anywhere in WM. Edition in courses, edit-a-thons and events would be better with this system, making our work more social, collaborative and interesting.
  • Who would benefit: Editors
  • Proposed solution: Deploying the systems that are already developed.
  • More comments:
  • Phabricator tickets: T3898, T112984, T76548
  • Proposer: Sahaquiel9102 (talk) 20:07, 30 October 2018 (UTC)

Discussion

  • I tend to leave messages at the talk page of the article and ping the author there to encourage them to make the edit if they want to. There I can propose new large additions or corrections also. Gryllida 22:27, 30 October 2018 (UTC)
  • Just a note, it might be helpful to link to the real-time collaboration project page on MediaWiki.org where this work is being documented for further context. CKoerner (WMF) (talk) 16:40, 2 November 2018 (UTC)
  • It looks like this proposal may be a solution. Am I wrong? Pamputt (talk) 21:25, 5 November 2018 (UTC)
  • Way back when, someone got a en:Google Wave working for Wikipedia. I wonder if there's any interest there. --Izno (talk) 02:43, 6 November 2018 (UTC)
    Also related besides the above tasks, T103081. --Izno (talk) 21:00, 7 November 2018 (UTC)
Hi Sahaquiel9102 and all: Unfortunately, this proposal is too big for the Community Tech team to take on. I know that CollabPad has a great demo, but the reason why it hasn't been implemented yet is because it's really big and complicated. :) I'm going to archive this proposal; sorry to disappoint you. -- DannyH (WMF) (talk) 02:09, 14 November 2018 (UTC)

Simultaneous editing with CollabPad

  • Problem: We have a really exciting, highly usable prototype of simultaneous collaborative editing, in the form of CollabPad. This recent hack-a-thon project lets multiple users edit the same page with VisualEditor, communicate via comments, and get a good-enough approximation of the kinds of real-time collaboration that we usually turn to Google Docs or etherpad for. It seems really close to being usable for real wiki work — edit-a-thons, collaborative drafting of new articles, etc. — as long as there is a basic way to save the CollabPad edits back to a conventional revision and provide attribution to everyone who made edits.
    Here's a live example CollabPad, and here's where you can start your own pad. (This server is just for testing purposes, and content could be reset at any time.)
  • Who would benefit: Edit-a-thon organizers and participants, editors of time-sensitive or breaking news topics, student editors working in groups, and more.
  • Proposed solution: Finish up the necessary improvements to allow basic usage of CollabPad for collaborating on new articles at edit-a-thons. (Initially limiting usage to new articles could provide a way to bypass some of the trickier problems like dealing with conventional edits that happen in the middle of a collaborative editing session. Initially limiting the creation of new pads and their export to conventional pages to user with advanced rights, such as the 'event coordinator' right commonly give to edit-a-thon organizers, could bypass some of the abuse-handling issues that would need to be solved for more general usage.)
  • More comments:
  • Phabricator tickets:
  • Proposer: Ragesoss (talk) 17:31, 5 November 2018 (UTC)

Discussion

See also the overlapping proposal "Simultaneous editing"; I thought a more specific one would be useful for exploring this one particular possible solution to the simultaneous editing problem.--Ragesoss (talk) 17:31, 5 November 2018 (UTC)

Hi Ragesoss and all: Unfortunately, this proposal is too big for the Community Tech team to take on. I know that CollabPad has a great demo, but the reason why it hasn't been implemented yet is because it's really big and complicated. :) I'm going to archive this proposal; sorry to disappoint you. -- DannyH (WMF) (talk) 02:09, 14 November 2018 (UTC)

Graduate 2017 wikitext editor and make it a full value editor

  • Problem: We are using and testing the (new) 2017 wikitext editor since 2016. In the past year, nothing really big happened with this tool, although there are many (currently 121) open tickets on Phabricator. With fulfilling these requests and solving the problems (e.g. speed, stability, many CodeMirror-related bugs) we could finally have a modern, fast and VE-look alternative of the old editor. Let's speed it up and finally graduate this project!
  • Who would benefit: everybody who is using (or would like to use) the 2017 wikitext editor.
  • Proposed solution: solve every bug, fulfil requests and ask the community for more great ideas.
  • Phabricator tickets: main ticket is T104479, bugs are listed here.

Discussion

Quick evaluation notes: This is feasible and in-scope for the wishlist. I cannot, of course, make any commitments for any team, but I am certain that the Editing team agrees that it is time to do this. A few notes:

  • "Deployment" in this instance merely means moving the pref setting out of Special:Preferences#mw-prefsection-betafeatures and into the normal editing section at Special:Preferences#mw-prefsection-editing, while preserving each individual editor's own settings. It is a matter of a couple of announcements, changing a few help pages, and throwing the switch on the database.
  • However, phab:T202921 should be done first, because the current method of selecting which editing environment you're using is deeply confusing. (In the current prefs system, you can enable multiple editing environments, and it silently overrides your "wrong" choices.) With the resolution of phab:T30856 this week, and the conversion of all the prefs pages to OOUI earlier this year, there is nothing blocking the redesign of that small section in the editing prefs. This should be a relatively simple project.
  • Once the prefs are re-designed, and the tool is moved into the normal prefs, if any wiki that wants this editing environment to be presented to users as the first choice, they need only send a note to me about it, with a link to a discussion among the community members. But this is IMO a separate project, and should not require any effort from the Community Tech team.

Overall, this should be a quick and easy project. Whatamidoing (WMF) (talk) 18:39, 2 November 2018 (UTC)

Unfortunately, I think this is out of scope for Community Tech. This is an Editing team project, and it needs to be handled by that team. Sorry about that. -- DannyH (WMF) (talk) 02:15, 14 November 2018 (UTC)

Change colours of Machine/Human translation bar in Translation tool

  • Problem: Its very hard to distinguish between machine translation and self translated percentage
  • Who would benefit: Inter Language translators on Wikipedia
  • Proposed solution: I would recommend the change the colour of either machine translation or self translation status bar to red:
  • More comments: While Translating an article into another language a progress bar is shown on the top right corner of the webpage, which shows the percentage of machine translation and human translation. But, due to high contrast modern laptop screens, it is very hard for us to distinguish between these colours (blue & dark blue). So I request you to change at least one of their colours from blue to red or any other colour, so it'll easy to distinguish
  • Phabricator tickets:
  • Proposer: IM3847 (talk) 09:22, 7 November 2018 (UTC)

Discussion

The new version of Content translation provides new mechanisms to encourage users to review the initial machine translated content and no longer shows the progress bar in the translation page that this proposal refers to. In particular, the new version shows a warning at a paragraph level, pointing to the specific paragraphs that need review, which we think will be more effective than providing a general percentage for the whole document. You can check the link above for more information about the new version of the tool, give it a try and provide any feedback in the discussion page. --Pginer-WMF (talk) 12:31, 13 November 2018 (UTC)

Hi IM3847: As Pginer says, the Language team is currently working on solving this problem, so I'm going to archive your proposal. I hope you check out the new version. Thanks for participating in the survey! -- DannyH (WMF) (talk) 02:20, 14 November 2018 (UTC)

Enable Visual Editor for all non-talk-namespaces

  • Problem: A lot of new editors learn editing only/primarily with the Visual Editor. But when they want to edit something in another namespace – for example there own userpage – they cannot use the Visual Editor and are forced to learn Wikitext.
  • Who would benefit: New Editors and Editors who like the Visual Editor
  • Proposed solution: Enable the Visual Editor not only for the article namespace but also for all other namespaces expect for the talk-namespaces (Visual Editor is not ready for them) and Namespaces containing code (Template and Module)
  • More comments:
  • Phabricator tickets:
  • Proposer: MichaelSchoenitzer (talk) 01:09, 8 November 2018 (UTC)

Discussion

Why not talk? It's a wikipage as every other wikipage, so VE could work there as fine as everywhere else. Grüße vom Sänger ♫(Reden) 21:10, 8 November 2018 (UTC)

For strategic reasons:
  • Visual editor lacks some features needed to be useful on talk pages. Adding these properly would mean quite some extra work.
  • There is an alternative for talk pages: flow – many people dislike it, but it still seems to be WMFs solution for this problem.
Both would make this wish less likely the be full filed by the Community Tech team, because it would then be to big and complex. Therefore let's focus on the first step. Let's make an extra wish to enable VE for talk pages. Next year, or if you like already this year. -- MichaelSchoenitzer (talk) 23:23, 8 November 2018 (UTC)
He has already, and it was archived, as appropriate. --Izno (talk) 23:54, 8 November 2018 (UTC)
  • This doesn't work because some pages that aren't classical talk pages work like classical talk pages. --Izno (talk) 23:54, 8 November 2018 (UTC)
Hi MichaelSchoenitzer, I have good news and bad news about this proposal. :) The good news is that the Wikimedia Foundation is starting the planning process for a big global Talk pages consultation which will begin in February. The idea is that we need to step back from LiquidThreads and Flow, and start over with a totally public and transparent consultation. We want to bring together as many people as possible, and come to consensus on the problems with talk pages that we want to solve, the good things about talk pages that we want to keep, and the tradeoffs involved in finding a solution that will work for new and experienced editors. You can read a lot more about it on that project page that I linked. The planning has just started, and we're starting to talk about the structure for this consultation and how it's going to work.
The bad news for right now is that we don't want to include proposals about talk pages in the Wishlist Survey voting. I know that your proposal is explicitly asking for non-talk-namespaces, but there are a lot of places where those namespaces are used for conversation too -- for example, all of the noticeboards in the Wikipedia namespace.
No matter what happens in the Wishlist Survey voting, all of the future talk page work will be determined by the Talk pages consultation happening next year. We don't want people to vote for something, and then find out that we still have to have another process before we make any decisions.
I'm sure this will be disappointing right now; I hope it's also heartening to know that this problem will get a lot of attention next year. Let me know what you think. -- DannyH (WMF) (talk) 02:27, 14 November 2018 (UTC)
@DannyH (WMF): I find this totally incomprehensible. My wish was explicitly not about talk pages yet you decline it for some "let's talk about talk-pages"-project. Will there be space to talk about non-talk-namespaces in this process or will the topic there also get declined since that is about talk-pages only? I see this falling in between the edges and never being handled. -- MichaelSchoenitzer (talk) 11:13, 14 November 2018 (UTC)
Look at my proposal last year: Community_Wishlist_Survey_2017/Archive/Release_VE_on_Talk_pages. It was declined, because any dealing with VE on any pages as default besides article name space is considered beyond the scope of Community Tech. Yes, this is clearly about some tech component the community has to use, but in some warped sense it's not community tech, but the devs decide about their software without community involvement. Grüße vom Sänger ♫(Reden) 12:44, 14 November 2018 (UTC)
MichaelSchoenitzer: Can we make a list of which namespaces you're talking about? We can't do the "project" namespace (Wikipedia:), because it's used as talk pages. We can't do Special. For File and Template, VE is probably not that helpful. So is your proposal to put VE on User and Category pages? If it is, can you clarify that in the proposal? -- DannyH (WMF) (talk) 20:43, 14 November 2018 (UTC)

Link permanence and archiving

  • Problem: Discussions on Wikipedia can be quite hard to track, this is especially true for those that took place at least a little while ago. This problem is partly caused because after a while most discussions are moved to archives, which immediately breaks links to sections. Currently to find the linked section, you'll have to extract the link from the URL and then dig your way through archives with the search function and CTRL+F. Doing this for multiple links is very time consuming and when you look at it again at another occasion you'll have to dive in the archives once again. Simplifying this would be especially useful for non-power users who don't know how to adequately search archives.
  • Who would benefit: Anyone reading discussions
  • Proposed solution: One solution might be when clicking on a link to a section that no longer exists, it no longer redirects to the page but to the search page which includes both the original page as well as the title of the subheading. Of course this would exclude links to articles in the main namespace.
Example: a link to Wikipedia:Test#Unavailable Link would lead to a a Special:Search instance with the parameters Wikipedia:Test + "Unavailable_Link"
  • More comments: This also solves problems of incorrect linking to embedded pages, where the link breaks when a page is unembedded.
  • Phabricator tickets:
  • Proposer: Kippenvlees1 (talk) 00:03, 6 November 2018 (UTC)

Discussion

  • I note that MediaWiki doesn't currently track which anchors are in a page or which anchors are used when linking to a page, so both of those would have to be added to avoid having to re-process every linking page each time any page is edited. I also note that "anchors" are a superset of "section headings", as any HTML element with an "id" attribute can be used as an anchor. Anomie (talk) 00:34, 6 November 2018 (UTC)
Hi Kippenvlees1, I have good news and bad news about this proposal. :) The good news is that the Wikimedia Foundation is starting the planning process for a big global Talk pages consultation which will begin in February. The idea is that we need to step back from LiquidThreads and Flow, and start over with a totally public and transparent consultation. We want to bring together as many people as possible, and come to consensus on the problems with talk pages that we want to solve, the good things about talk pages that we want to keep, and the tradeoffs involved in finding a solution that will work for new and experienced editors. You can read a lot more about it on that project page that I linked. The planning has just started, and we're starting to talk about the structure for this consultation and how it's going to work.
The bad news for right now is that we don't want to include proposals about talk pages in the Wishlist Survey voting. No matter what happens in the Wishlist Survey voting, all of the future talk page work will be determined by the Talk pages consultation happening next year. We don't want people to vote for something, and then find out that we still have to have another process before we make any decisions.
But -- these proposals and the discussions that people are having here are important, and I've added a section on the Talk pages consultation page which lists each of the related proposals, so that they can be a part of the public record during this planning stage. We'd like to include all of you in the consultation -- and in the planning, if you're interested. There's a lot to talk about and figure out.
I'm sure this will be disappointing right now; I hope it's also heartening to know that this problem will get a lot of attention next year. Let me know what you think. -- DannyH (WMF) (talk) 02:51, 14 November 2018 (UTC)

Smarter decision-making

  • Problem: Important mundane decisions that require discussion on Wikipedia often have a specific time limit, after which the majority solution can be carried out. Also, these decisions often involve more than one article. For instance, to merge two articles together, the appropriate template must be placed in both discussion pages, and if a consensus has been reached after one week the editor who placed the templates is free to carry out the merge. This often leads to forgotten proposals that are never carried out, because: 1) the same discussion takes place twice, in two separate places (each article) and with different participants, which causes confusion, and 2) if the proposal receives no objection, there's nothing to remind the original editor to take further action.
  • Who would benefit: Any Wikipedia editor who regularly goes through many articles that require deep changes, especially those articles that don't attract much interest.
  • Proposed solution: Automate the entire process. Create a page where editors can enter the desired action and all relevant articles (one or more) in order to post notices on all discussion pages. In that notice, include a link to a single discussion page dedicated to that proposal. No matter what happens in the meantime, when the deadline for discussion is reached, send an automatic reminder to take action.
  • More comments: In loving memory of all the wise proposals I placed throughout the years and left to their fate.
  • Phabricator tickets:
  • Proposer: Joalbertine (talk) 19:41, 6 November 2018 (UTC)

Discussion

@Joalbertine: Would this be basically resolved by having an option to "remind me of this discussion / article in X days again" (that would be phab:T2582), or would something else be needed? --AKlapper (WMF) (talk) 03:40, 7 November 2018 (UTC)

It would resolve part of the problem - the issue of forgetting to check back a week later. In my opinion, the kind of system that I described would be much more efficient, because all it would require from the user is to state which articles are the matter and what they would like to do with them. Everything else can and should be completely automatic. --Joalbertine (talk) 13:34, 8 November 2018 (UTC)
Hi Joalbertine: Unfortunately, I think that this is outside the Community Tech team's scope. This would require a lot of changes to community practices; it's mostly a social change, with some technical work on the side. It's just not right for this team, sorry. -- DannyH (WMF) (talk) 02:55, 14 November 2018 (UTC)
I don't see it as a social change at all, just creating the technical tools required for efficient communication within the accepted social practices. The only change would be posting messages that are mandatory by machine and not by human users. As to the separate discussion pages, I find it very hard to believe that anyone sees them as a deliberate social feature, rather than a blunder. We are talking about the same proposal, affecting the same group of articles, being discussed simultaneously in multiple groups consisting of editors who previously worked on each article, with no space to communicate with each other, rather than everybody talking together from the first place. That's insane. I do agree that a resolution can have a profound social impact, but only in the sense that it would make communication so much smoother and easier to understand. --Joalbertine (talk) 14:10, 15 November 2018 (UTC)

Display a password strength bar

  • Problem: Although a second factor of authentication is great, securing the first factor (the password) is perfectly adequate for most users. Although this proposal would not stop users from using single character passwords, it would incentive them to choose a more secure password. Prompts like reminding users not to reuse passwords would also work well.
  • Who would benefit: Everyone, as the security of Wikimedia projects would be improved. This way, we are teaching people about online security while preventing unauthorized access to accounts at the same time. The English Wikipedia has also asked for this to be implemented, as shown on this Village Pump discussion.
  • Proposed solution: A simple password strength bar!
  • Proposer: Daylen (talk) 05:06, 30 October 2018 (UTC)

Discussion

  • If this is approved, I really hope we don't end up encouraging passwords that are hard for humans to remember, but easy for computers to guess. (Please don't recommend using capitals, symbols, or numbers, or avoiding use of several simple dictionary words.) --Yair rand (talk) 21:31, 30 October 2018 (UTC)
  • Since you mentioned the password length, I thought I'd let you know that the Anti-Harassment Tools team will be working to enforce longer passwords. You can see more details in this Phab task. AEzell (WMF) (talk) 22:21, 30 October 2018 (UTC)
    • I don't like enforcing them for new accounts AEzell (WMF) in my view a non-binding strength meter is sufficient. For existing accounts perhaps show a warning and ask users to change password. Gryllida 22:41, 30 October 2018 (UTC)
      • We received this work from the Security Engineering team. Gryllida, you could comment on that Phabricator task if you have a user there. I can pass along this feedback as well but I'm not a decision maker on whether we do it or not. AEzell (WMF) (talk) 23:10, 30 October 2018 (UTC)
Hi Daylen: The work that we do on passwords is determined by our Security Engineering team. They've got some plans to make passwords stronger on our sites. We'll have to decline this proposal as being outside the scope of the Community Tech team. Sorry about that, thanks for participating in the survey. -- DannyH (WMF) (talk) 02:58, 14 November 2018 (UTC)
@DannyH (WMF): This proposal is for a non-binding password strength bar, not a requirement for a minimum password length or strength. Under this proposal, it would be up to each community to decide whether to display the bar and what the requirements (if any) are. I realize that these are global accounts, but I still believe that giving each community a choice is the best option. I also don't understand how this is outside of the scope, as 2FA for all accounts has been suggested in previous community wishlist surveys. Cheers, Daylen (talk) 05:06, 17 November 2018 (UTC)
Daylen: Providing the option for 2FA is still on the survey and doing pretty well, so we may be talking about changes to the system there as well. Our Security Engineering team is doing a lot of work to increase security on the wikis right now, and we're trying to keep CommTech out of their way, while they make changes. Sorry, I know it's disappointing to have your proposal declined. -- DannyH (WMF) (talk) 19:24, 17 November 2018 (UTC)

Allow update of stored edit-summary

 N Declined as it opens up a potential venue for harassment - cannot be addressed until there is a good solution to tackle that

  • Problem: Correcting a saved edit-summary line should be allowed, by the recent user, even if for less than an hour later. A misleading typo or personal attack could be corrected, after the user re-thinks the edit-summary line.
  • Who would benefit: Everyone, especially if asked to redact a veiled insult within the edit-summary text.
  • Proposed solution: Perhaps have a "[mod]" modify-button in the history-page, at end of each revision remark, while the time-period is active for updates to an edit-summary line. However, do not change page contents, nor alter the revision date of the saved revision.
  • More comments:
  • Phabricator tickets:
  • Proposer: Wikid77 (talk) 15:23, 8 November 2018 (UTC)

Discussion

  • Let's find a method to do this. -Wikid77 (talk) 15:23, 8 November 2018 (UTC)
  • Hi Wikid77. The problem with this wish is that we don't have a system in place for tracking changes to edit summaries. Like all other content on the wikis, we need to be able to track changes (keep history) for edit summaries. Otherwise people can abuse the edit summary. They may initially use it to abuse someone and then change the content. We will have no way to see what they wrote originally if we don't store all history. See discussion on task T15937#2606108 for more information. -- NKohli (WMF) (talk) 20:34, 8 November 2018 (UTC)
We don't want to save the prior edit-summary, but rather redact the text and put another edit-summary text. Example: someone saves a revision with "to discuss call me at phone xxx-xxxx" and then a patroller asks to redact phone number, so the overwrite revision could be a dummy-edit with summary "overwrote prior edit-summary" but omit the phone-number as truly a redacted summary line, in the prior revision (or some other numbered revision). I guess this feature could be called "redact edit-summary" to clarify as no storage of the previous edit-summary, but just store a dummy same-content revision to log who re-saved the redacted edit-summary text (and when it was re-saved). -Wikid77 (talk) 05:44, 9 November 2018 (UTC)
  • This is something discussed I discussed with some of my other fellow editors offline and we treated it as a joke but here it is, but I don't know the submitter. Thus is something like flow, which allow posts to be edited. Pros will be per above which there isn't a need to use a dummy edit to indicate any changed or you forgotten about it. Cons are aplenty, this can turn into an entire namespace called edit summary namespace where we need protection, patrolling, revdel of edited summary, and etc which I personally will not look forward to. A dummy minor edit seems fine for me.--Cohaf (talk) 20:43, 8 November 2018 (UTC)
    • Storing a new dummy-edit revision, to log the overwrite of a redacted-summary revision sounds like a good method, as a record of who redacted the edit-summary text of the (troublesome) revision and when it was redacted. If the software demands a content change, then perhaps add a blank space at end of last line in the page, to avoid putting a significant space within a top template's literal parameters. -Wikid77 (talk) 05:44, 9 November 2018 (UTC)
      • You actually missed my point, if you wish to change an edit summary, just do a dummy edit and Mark it as a minor edit with the summary being what is supposed to change and then ask for suppression (if it is oversight issues) or a revision delete of the edit summary (usually RD2,RD3). This current system works well and I don't see why there is a need to change. --Cohaf (talk) 10:32, 9 November 2018 (UTC)

Wikid77 We discussed this wish in our team meeting today and everyone had deep concerns about this proposal. There is a lot of scope for misuse of this feature. A user can put down offensive comments against another user in an edit summary and then a short while later, change it. If an admin doesn't see it, the user won't be banned. This can be very problematic and opens up an avenue for harassment. We are sorry but this project is probably not a good idea. I understand the value of this project but there are too many potential concerns with it. Thanks for submitting the proposal. I am sorry for the inconvenience. -- NKohli (WMF) (talk) 03:51, 14 November 2018 (UTC)

Translate Infobox via WikiTranslation

 N Language team is already working on this

  • Problem: Infobox aren't getting translated in the translation tool, it shows a plugin error
  • Who would benefit: Multi Language editors and Translators
  • Proposed solution: Translation tool should also translate Infobox into the required language without any error
  • More comments: I'm one of the users in English Wikipedia, who translates articles from English to Telugu, while doing so I figured out that infoboxes cannot be translated and should be added manually after the complete translation is done
  • Phabricator tickets:
  • Proposer: IM3847 (talk) 06:58, 8 November 2018 (UTC)

Discussion

  • Pinging Pginer-WMF, who may know whether this is already on the Language Team's roadmap. Pau, what are you folks planning for Infoboxes? —JMatazzoni (WMF) (talk) 18:46, 8 November 2018 (UTC)
    • The Language team is currently working on Content translation version 2 which will improve the mapping of templates in general, and infoboxes in particular (we recommend giving it a try and report issues found in this regard at the talk page). Will this make all infoboxes to be successfully transferred across any language? Unfortunately, not. Templates are created independently on each wiki and they are not built to be easy to transfer across different wikis. For Content Translation to successfully transfer a template across languages it requires some template metadata to be available: equivalent templates to be connected in Wikidata, and templateData information for the parameters. Some possible initiatives that can help in this context to solve the underlying problems are: support global templates (technical), encourage communities to use Wikidata-based templates , or complete the existing templates with the missing templateData. The later are community efforts, where the technical solutions to do them exist but could be improved to encourage/facilitate these processes. These initiatives have not been planned yet as far as I know. --Pginer-WMF (talk) 10:58, 9 November 2018 (UTC)
In general, infoboxes are templates. The 1st thing we need is sorted fields that come up with translation only. As there are differences like missing fields that do not exist in one language, the CXT needs to offer to fill them. Another problem in translating templates are double used fields like geographic coordinates: In one language, longitude is a separate field, in the other language both coordinates are the same filed, but separated whit a special character. It is up to the developers to make this character to be defined as a separator. Another problem are measured like gallons to liter or miles to kilometers. And all in all what is displayed text to be translated. And never forget to solve it by transferring infoboxes to Wikidata. --Hans Haase (talk) 13:05, 11 November 2018 (UTC)
  • Hi IM3847. It looks like the Language team is already working to make your wish a reality, so I'm withdrawing this proposal. Thanks for your participation. —JMatazzoni (WMF) (talk) 16:31, 14 November 2018 (UTC)

Improved style and internationalized labels in Wikimedia Maps

 N The elements of this wish either duplicate another wish or are out of scope

  • Problem: Work started last year needs to be completed, a new map style was developed but not released, and international map labels are tied to OpenStreetMap only
  • Who would benefit: All wikimedia projects using maps, OpenStreetMap community (which asks to not translate / transliterate names if not used in the real world)
  • Proposed solution: Complete and deploy Paul Norman's work for map styles (because the current one has its shortfalls) collecting feedback from the user community, integrate better Wikidata with OpenStreetMap in the WMaps infrastructure by switching the data source for map labels to Wikidata and adding Wikidata IDs in the vector tiles source.
  • More comments: Adopts some ideas from "Wikimedia Maps Improvements" proposal
  • Phabricator tickets: T193198, T156682, T159205
  • Proposer: Sabas88 (talk) 15:09, 9 November 2018 (UTC)

Discussion

Thanks for your participation Sabas88. We're withdrawing this wish for two reasons. The first is that the vector tile conversion in T156682 was requested by a different wish, Maps Improvements: Vector Structure, Disputed Borders, Cleaner Style (T156682 is a subtask of the ticket named in that wish, T153282. That leaves the two Wikidata proposals named here. These changes would be popular I'm sure but unfortunately would require architectural changes to Kartographer that are just beyond the scope of what we can handle in a Community Wishlist proposal. —JMatazzoni (WMF) (talk) 16:44, 14 November 2018 (UTC)

@JMatazzoni (WMF): so what will happen when the OSM community starts removing the transliterations introduced by wikipedians in OSM where these don't match with reality? --Sabas88 (talk) 16:53, 14 November 2018 (UTC)
  Support I'm in favor of this proposal and beg you, @JMatazzoni (WMF):, to reconsider the withdrawal. I'd like to emphasise once again, that OSM collects endonyms, and strongly suggests to avoid transliteration. You say yourself these changes are popular. I'm wondering why proposals related to maps are pushed back recently, given such a potent organization like WMF (unfortunately I could not talk directly to Katherine when she was at DINacon). --Geonick (talk) 23:11, 18 November 2018 (UTC)

Template:Authority control accessable in the Mobile app using 3D touch

  • Who would benefit: Mobile readers
  • Proposed solution: Add an icon and use something like 3D touch.
  • More comments: I can see 3D touch could be used for customizing how you navigate e.g. that as we today can see current articles on a map and also nearby locations. I think 3D touch could be "set up" according to the users prefered interests i.e.
    • find all objects depicting this article
    • use Wikidata properties
      • 3D Touch to get a link to Spotify for the artist I read about
      • 3D Touch to get an family tree option to display the person in the articles in a family tree
      • 3D Touch to get Scholia for the person/institution in the article
      • 3D Touch to see pictures with depicting the person in the article....
      • 3D Touch to see paintings depicting the person in the article from my prefered museums....
      • .....
  • Phabricator tickets:

Discussion

  • @Salgo60: I like this proposal, but maybe using a long press might be better (not even all currently produced iPhones have 3D Touch). Where would the user be pressing? I'm guessing there would be different behaviour when pressing on links as opposed to pressing somewhere else on the current page? Jc86035 (talk) 15:23, 30 October 2018 (UTC)
    • @Jc86035: today the Wikipedia Iphone app has 3D touch for links ==> that I get more links and if you swipe up you see an option for the maps.... I see this as an excellent way of hiding functions you dont use so much.... so why not a 3D press anywhere on the article with no links will display options for categories/Authority control/link Wikicommons pictures/WD External properties..??? - demo video of 3D touch and swipe - Salgo60 (talk) 15:44, 30 October 2018 (UTC)
      • Oh, I didn't know it already utilized 3D Touch. I think it would be useful but it would still potentially be unusable for a lot of iOS users. Jc86035 (talk) 15:46, 30 October 2018 (UTC)
  • Note that 3D touch is being discontinued by Apple. Kaldari (talk) 05:01, 31 October 2018 (UTC)
  • @Salgo60: Since 3D touch is being discontinued, closing this proposal. Ryan Kaldari (WMF) (talk) 18:12, 14 November 2018 (UTC)

Namespace for image sets

  • Problem: Categorizing image sets is inconvenient.
  • Who would benefit: Everyone who uses categories to find images (because category pages would become clearer), especially users who look for images consistent among each other
  • Proposed solution: Own namespace Set. When there are many images of the same kind in a category, it should be possible to bundle them. But the result should ideally be a group of thumbnails, and not just another subcategory link. I described the problem and possible solutions on Commons:Image sets.

    The following example shows in a simplified way how Category:Penrose tilings would look with Sets between Subcategories and Media:

Discussion

@Watchduck: Aren't these sets (sub)categories again? --AKlapper (WMF) (talk) 15:41, 5 November 2018 (UTC)

They would be specialized categories. A set would typically be in a category (designating its subject) and might be in a bigger set (of more images in the same style). But a category could not be in a set. The Own namespace section on Commons shows a second example: Set:Octahedron with direction colors is in Category:Octahedron (the subject) and part of Set:Octahedral Platonic solids with direction colors. (The root set is Set:Polyhedra with direction colors.) Watchduck (talk) 18:02, 5 November 2018 (UTC)
@Watchduck: If a set is a "specialized category" and "a set would typically be in a category", to me it still sounds as if a set is sub-category. :) --AKlapper (WMF) (talk) 03:47, 7 November 2018 (UTC)
Did you look at Own namespace? Maybe it becomes clearer in OOP terms:
The class Set extends the class Category. It inherits most of its behaviour, but has special features and restrictions on top of that.
There is the main feature that a set is shown as a collection of thumbnails, and not just as a link (see example in the collapsed box above).
And there is the restriction that a category can not be in a set.
For comparison: The class Pickup extends the class Car. So a set is a special kind of category, just like a pickup is a special kind of car.
The semantic difference between a set and a subcategory is that the subcategory narrows down the topic, while a set just bundles many files of the same kind.
Technically Set would be closer to Category, but semantically it would be closer to File — just that it is a bundle of files and not just one.
(For the sake of simplicity I sometimes wrote is instead of would be.) Watchduck (talk) 21:28, 7 November 2018 (UTC)

Archived

We decided not to move forward with this proposal because it's mostly about creating a new namespace and this is something the Commons community should decide for themselves. If they reach consensus on this matter, they can just request it and we will create it, you don't have to make it a wish in our survey for that. MaxSem (WMF) (talk) 20:34, 14 November 2018 (UTC)

Internal transcoder to webm

 N This feature already exists

  • Problem: We already are years behind as an educational power house, as a great part of the population that have broadband internet access seek educational content via YouTube, as videos are very powerful tools when we are talking about didactic.
And everybody that tried to upload videos at Commons know how painful this task is. My workflow to keep a reasonable quality and speedy is to upload at YouTube, and import via video2commons. Image a newcomer trying to accomplish the same task.
We have this giant filter, the upload, removing this barrier, we will probably see more and more contributions in video. "Build it, they will come".
  • Who would benefit: Video creators, consequently the whole community, to not say humankind.
  • Proposed solution: Create a internal transcoder to webm, internal to Upload Wizard.
  • More comments: We should started investing in video years ago, we could have already 360° videos showing GLAMs around the word, videos with more than one audio language, allowing full courses at Wikiversity in several languages, i.e., ...
  • Phabricator tickets:

Discussion

What do you mean by this? We both allow webm uploads and transcode other formats to it. MaxSem (WMF) (talk) 21:14, 31 October 2018 (UTC)

R.T.Argenton, does the above satisfy your request? MaxSem (WMF) (talk) 08:28, 1 November 2018 (UTC)

Archived

As mentioned above, this already exists. Thanks for participating in our survey. MaxSem (WMF) (talk) 20:35, 14 November 2018 (UTC)

Support for the IIIF Image API on Wikimedia Commons

 N This proposal is too big

  • Problem: IIIF was created to allow the sharing and interoperability of high quality zoomable images. This idea proposes that Wikimedia Commons hosts a IIIF Image Server and makes their image content available using the IIIF Image API. This would allow Wikimedia Commons to use off the shelf open source image viewers like Leaflet or Open Sea Dragon and also allow users to reuse these images in external IIIF tools and be embedded in other websites. These IIIF Images could be wrapped in a manifest provided by Wikimedia Commons or users could create their own manifests using this IIIF Image service. A prototype for this service already exists and is discussed below. Wikimedia Commons provides access to zoomable images using IIPServer but this is currently in a labs environment and is often unavailable.
  • Who would benefit: All Commons users who would like to zoom into large images.
  • Proposed solution: Support the IIIF Image API by hosting a IIIF image server on the production Wiki infrastructure
  • More comments: This would allow WikiCommons to use any of the IIIF compatible viewers to view this content and also allow users to build manifests with this content. Since 2015 there has been a IIIF Image server in the Wiki labs based on IIP image. Details of the discussion can be found at: https://phabricator.wikimedia.org/T89552. Although this has been a good proof of concept, it hasn’t made it to the production infrastructure so is often inaccessible.
  • Phabricator tickets: https://phabricator.wikimedia.org/T89552
  • Proposer: Glenrobson (talk) 16:03, 9 November 2018 (UTC) with Andy Mabbett, Tom Crane

Archived

Unfortunately, our team won't be able to work on this proposal because it's too big and we need to fulfill 10 wishes per year, ideally. Thanks for participating in our survey. MaxSem (WMF) (talk) 20:38, 14 November 2018 (UTC)

Expandir os artigos com mais traduções.

 N Proposes a social/policy change rather than a technical change

  • Problema: Expandir os artigos com mais traduções.
  • Quem se beneficiaria: Os leitores das Wikipedias em outras línguas.
  • Proposta de solução: Difundir para mais colaboradores a ideia do Tradutor de Conteúdo.
  • Mais comentários:
  • Etiquetas no Phabricator:
  • Proponente: Sabiusaugustus (talk) 02:38, 4 November 2018 (UTC)

Discussão

Sabiusaugustus: This doesn't sound like a technical proposal. It's not something that requires software development, anyone actually writing code for a new tool. This means that this technical wishlist probably isn't the right place for this. Am I misreading you? /Johan (WMF) (talk) 23:46, 5 November 2018 (UTC)

Archiving this proposal per above comment. Thanks for participating in the survey. -- NKohli (WMF) (talk) 21:27, 14 November 2018 (UTC)

Make Wikidata more intuitive to use

 N Proposal is unclear

  • Problema: La edición de los datos en Wikidata es poco amigable y engorrosa, sobre todo si la comparamos con la forma existente en un principio (hace varios años). Siempre he sido partidario de una forma intuitiva de edición.
  • A quiénes beneficiaría:
  • Solución propuesta:
  • Más comentarios:
  • Informes de Phabricator:
  • Proponente: --Fev (talk) 22:30, 4 November 2018 (UTC)

Discusión

  • What is a change you think would help fix this? --Izno (talk) 01:43, 6 November 2018 (UTC)
  • @Fev: Also, could you link to an example? --AKlapper (WMF) (talk) 13:32, 6 November 2018 (UTC)

I will archive this proposal as the proposal is not clear and we have not received a response from the proposer to the above comments so far. Thanks for participating in the survey. -- NKohli (WMF) (talk) 21:31, 14 November 2018 (UTC)

Modul embedded pentru membru al Academiei de științe a Moldovei

 N Does not propose a technical change

  • Problem: An infobox for the members of the Academy of Sciences of Moldova (titulars, correspondents, honorary). An embedded module similar to that for the members of the Romanian Academy will be nice (modules = .. Member of the Academy of Sciences of Moldova).

((ro) Să se realizeze pentru membrii (titulari, corespondenți, de onoare) ai Academiei de Științe a Moldovei, un modul embedded pentru infocasete similar cu membrii Academiei Române (module=..Membru Academia de Științe a Moldovei) )

  • Who would benefit:
  • Proposed solution:
  • More comments:
  • Phabricator tickets:

Discussion

PheonixRo: Sorry for replying in English, I don't speak Romanian. I think you need to give more details – I must admit I'm not really sure what you mean. This sounds like a local template problem, which can be solved by any editor who regularly edits templates, and maybe not something that requires software development? /Johan (WMF) (talk) 12:00, 2 November 2018 (UTC)

I agree with this comment. This does not look like a proposal that needs much, if any, help at all. --Izno (talk) 01:33, 14 November 2018 (UTC)

  Comment @PheonixRo: I Machine Translated the proposal and kept the original Romanian.

Dropped a note till they come back at PheonixRo. —Omotecho (talk) 03:34, 13 November 2018 (UTC) 03:09, 13 November 2018 (UTC)

PheonixRo Hello. Adding infoboxes is out of scope for Community Tech. They need community consensus and is handled by the community of the wiki in question. Hence I will need to archive the proposal. Thanks for participating. -- NKohli (WMF) (talk) 21:49, 14 November 2018 (UTC)

Describing the geometry and logic of geographical objects on Wikidata

  • Problem: All I can see is that geograpical objects are described as a point. There are no more shapes than this. There are matters of geometry (which are solved by CAD solutions) and beside this matters of logic as well (which are GIS): A borderline should end up in another border. A river has a direction how the water is flowing. A river can have a joint into another river. A railway line would not have a joint into a river.
  • Who would benefit: The mankind reading articles about geographical objects.
  • Proposed solution: There should be an open team with unpaid developers or an extended team with additional paid developers (a) to discuss and perform solutions to embed geographical shapes and (b) define a language and objects to be used by users easily. (c) The should be some converters for data from/into other projects like WikiMaps or OSM. (d) An alternative or additional feature could be a link to objects defined there.
  • More comments:
  • Phabricator tickets:
  • Proposer: Slaney (talk) 15:23, 31 October 2018 (UTC)

Discussion

  • Wikidata has the property geoshape (P3896) that is capable of modeling shapes. ChristianKl (talk) 10:31, 4 November 2018 (UTC)
  • It is also possible, if geoshapes can be obtained from external federated SPARQL services, for these also to be displayed by a WDQS query. Jheald (talk) 19:53, 5 November 2018 (UTC)

Ah ok, I see https://www.wikidata.org/wiki/Wikidata:Property_proposal/geoshape (2017). When was it introduced into Germany community? Where can I find an document about its elements? And a manual how to use it? Are there any converters to make use of data of other much more developed projects? -- Slaney (talk) 07:08, 10 November 2018 (UTC)

Slaney: Great, I'm glad you got the answer you were looking for. I'm archiving this proposal. -- DannyH (WMF) (talk) 22:16, 14 November 2018 (UTC)
DannyH (WMF) What about my questions? Could you please give me this information? -- Slaney (talk) 02:34, 15 November 2018 (UTC)
Slaney: I'm sorry, I thought you were asking ChristianKl and Jheald about those. -- DannyH (WMF) (talk) 16:14, 15 November 2018 (UTC)
I propose that GIS with some professional standard should be reached. This means, forexample the polystring of a river should have a direction. And so on. -- Slaney (talk) 08:38, 18 November 2018 (UTC)
https://meta.wikimedia.org/wiki/KML_files is the existing page for information but I don't think there's a lot of existing documentation. ChristianKl❫ 11:26, 18 November 2018 (UTC)

Obliger les contributeurs à créer un compte pour contribuer

 N Proposes a social/technical change instead of a technical change Original title: Obliger les contributeurs à créer un compte pour contribuer

  • Problem:
    English (translation): I wish for it to be mandatory to create an account in order to contribute to the various Wikimedia projects. That would without a doubt deter many vandals from damaging articles.

    French (original): Je souhaite qu’il soit obligatoire de créer un compte pour contribuer sur les différentes interfaces de Wikimedia. Cela dissuaderait sans doute beaucoup de vandales de détériorer les articles.
  • Who would benefit:
  • Proposed solution:
  • Phabricator tickets:

Discussion

Tubamirum This is a community decision and outside the control of Community Tech team. I'm sorry this proposal needs to be archived. -- NKohli (WMF) (talk) 22:16, 14 November 2018 (UTC)

Copy references to another property

  • Problem: If I am entering data, for example in a lighthouse, I have to put the height, the opening date, the scope, the registration number, the location, etc. I take everything from the same source, but I have to provide the reference in each of the properties.
  • Who would benefit: It would benefit reliability and data collection with references from other Wikipedians.
  • Proposed solution: In commons there is a button to copy to all the photos entered the values ​​of a photo. Here it would be the same, a button that allows to enter the data of that reference (url, date of access, website, etc.) to other properties.
  • More comments:
  • Phabricator tickets:
  • Proposer: Vanbasten 23 (talk) 11:20, 4 November 2018 (UTC)

Discussion

Moin Moin Vanbasten 23, look into the gadgets there is a point "Copy source". Maybe that's what you're looking for. Regards --Crazy1880 (talk) 11:24, 4 November 2018 (UTC)

I asked a programmer of the Foundation two years ago in Wikimania because it was not done and it seems that they worked on it ... :DDD Thanks and sorry. --Vanbasten 23 (talk) 11:36, 4 November 2018 (UTC)
Great, it looks like your wish has been granted! Thanks for participating in the survey. -- DannyH (WMF) (talk) 22:17, 14 November 2018 (UTC)

ВикиСправочник

 N Proposes a social/policy change rather than a technical one

  • Проблема: English: Problem: In many language variants of Wikipedia there is a rule “Wikipedia is not a dictionary” [1], [2]. With reference to it, many articles of the "vocabulary" type are cut off. But reference to Wiktionary is not a panacea, since it is only a philological dictionary, and Wikis species (Wikispecies) are biological, and Wikidata is only a content. But there is a huge array of articles containing important, but not all relevant information. A “gray zone” is formed (where galaxies and asteroids fall; characters of books, cartoons and films; songs; schools; doctors, engineers, actors, players; insects, etc., etc.). And this leads to a fork: somewhere, even if there is a source confirming the information, the article for “insignificance” is deleted. And in some (for example, in Botanicles like Cebuan and in a number of Wikipedias that do not practice bot filling), the “article” is written in a single line on a similar topic.

The presence of such an array of articles in the “gray zone” distracts editors and administrators from writing and improving articles. They are forced to "fight" for leaving / deleting these articles. Do surveys about it. Suffer and readers who would like to read the article (learn specific characteristics) in Wikimedia projects about the subject / event / character from the "gray zone". And there is no article.

Who will win: Editors, administrators, readers Suggested solution: Since “Wikipedia is not a dictionary,” then Wikimedia needs a “dictionary,” or rather a Wiki Directory or Wiki Glossary. All articles from the “gray zone” will go there (asteroids, transuranic elements, characters, actors, etc.). The main difference between Wikispravochnik and Wikipedia will be in the size of the article (as now there is a difference in paper dictionaries / directories and encyclopedias): the main sources are statements and write the main thing about the subject of the article - for this purpose, 5,000 / 10,000 / 15,000 bytes will suffice (Maximum 30,000). If they can write more then let them write in Wikipedia. Additional comments: 1) There will be another additional platform where newcomers will be more comfortable to adapt by creating articles on topics relevant to them 2) If desired, Wikimedia will be able to send everything that turns normal Wikipedia into Botopedia (for example, Cebuena and Varai) and save them as encyclopedias even at the expense of the wiki-reference book "in Varaysk"

Original:Во многих языковых вариантах Википедии есть правило "Википедия - не словарь" [9], [10]. Со ссылкой на него отсекаются многие статьи "словарного" типа. Но отсылка к Викисловарю (Wiktionary) не является панацеей, так как он лишь является лишь филологическим словарём, а Викивиды (Wikispecies) - биологическим, а Викиданные (Wikidata) лишь содержанием. Но есть огромный массив статей содержащих важную, но не для всех значимую информацию. Образуется "серая зона" (куда попадают галактики и астероиды; персонажи книг, мультфильмов и фильмов; песни; школы; доктора, инженеры, актеры, игроки; насекомые и так далее и тому подобное). И это приводит к развилке: где то даже при наличии источника подтверждающего информацию статью за "незначимостью" удаляют. А в некоторых (например в Ботопедиях типа Себуанской и ряде Википедий не практикующих заливки ботом статей) на аналогичную тему написана "статья" в одну строчку.

Наличие такого массива статей в "серой зоне" отвлекает редакторов и администраторов от написания и улучшения статей. Они вынуждены "воевать" за оставление/удаление этих статей. Заниматься опросами об этом. Страдают и читатели, которые хотели бы прочитать статью (узнать конкретные характеристики) в проектах Викимедиа о предмете/событии/ персонаже из "серой зоны". А статьи нет.

  • Кто выиграет: Редакторы, администраторы, читатели
  • Предлагаемое решение: Раз "Википедия - не словарь", то Викимедиа нужен "словарь", точнее Вики-Справочник или Вики-Глоссарий. Туда и уйдут все статьи из "серой зоны" (и астероиды, и трансурановые элементы, и персонажи, и актеры и прочее). Основное отличие между Викисправочником и Википедией будет в размере статьи (как и сейчас разница есть в бумажных словарях/справочниках и энциклопедиях): главное это источники утверждений и написать главное о предмете статьи - для этого хватит 5.000/10.000/15.000 байт (Максимум 30.000). Если могут больше написать то пусть пишут в Википедии.
  • Дополнительные комментарии: 1) Будет ещё одна дополнительная площадка где новичкам будет более комфортно адаптироваться создавая статьи на значимые для них темы 2)При желании Викимедии туда можно будет отправить всё то, что превращает нормальные Википедии в Ботопедии (например Себуанскую и Варайскую) и спасти их как энциклопедии пусть и за счет Вики-справочника "на варайском"
  • Ссылка на задачу в Фабрикаторе:
  • Предложил: Авгур (talk) 14:31, 4 November 2018 (UTC)

Обсуждение

  • Are you familiar with Wiktionary, one of Wikipedia's sister wikis? --Izno (talk) 01:31, 6 November 2018 (UTC)
  • Да, но я пишу "Викисловарь (Wiktionary) не является спасением, так как он лишь является лишь филологическим словарём, а Викивиды (Wikispecies) - биологическим словарем, а Викиданные (Wikidata) лишь содержанием того, что есть в Вики-Медиа". А, что делать если я (или новичок) хочу писать про астероиды..., про каждого из "покемонов"..., мелкие улицы в маленьких городах..., памятники... То есть про то чему не место в лингвистическом (=Викисловарь) и биологических (=Викивиды) словарях, а для Википедии информация есть, но её мало? Что делать? Неужели уходить в Викию? Но это потеря значимого контента и участников... (Гугл-перевод en: Yes, but I write "Wiktionary (Wiktionary) is not a salvation, since it is only a philological dictionary, and Wikis species (Wikispecies) are a biological dictionary, and Wikidata is only a content of what is in Wikis Media." And what to do if I (or a novice) want to write about asteroids ..., about each of the "Pokemon" ..., small streets in small cities ..., monuments ... That is, about that which has no place in linguistic (=Wiktionary) and biological (= Wikispecies) dictionaries, and for Wikipedia there is information, but it is not enough? What to do? Is it possible to go to Wikia? But this is the loss of meaningful content and participants ...) Авгур (talk) 21:23, 6 November 2018 (UTC)
There is also https://www.wikibooks.org/. This proposal seems to cover a bit of everything...? https://www.wikimedia.org/ lists the existing sister projects. Creating new sister projects is out of scope for the Community-Tech team, I'm afraid. --AKlapper (WMF) (talk) 03:25, 7 November 2018 (UTC)
На русском Wikibooks называется Вики-Учебник. Но это не то. В том и дело, что в wikimedia нет проекта где вкратце, но можно было бы прочитать про все значимые для людей темы как предполагает Первый столп (WP:5P1) из Пяти столпов (Five pillars). Жаль, если данное предложение не будет реализовано. Но проблему было необходимо обозначить. Я надеюсь что предложение не пропадет, а лишь окажется в архиве... И возможно в будущем к нему можно будет вернутся пусть и на иной площадке. (Гугл-перевод en: In Russian, Wikibooks is called Вики-Учебник. But it is not that. The fact of the matter is that in wikimedia there is no project where in brief, but one could read about all topics important to people as suggested by the Первый столп (WP: 5P1) of the Пяти столпов (Five pillars). It is a pity if this proposal is not implemented. But the problem was necessary to identify. I hope that the proposal will not disappear, but will only be in the archive ... And perhaps in the future it will be possible to return to it, albeit at a different площадке.) Авгур (talk) 18:06, 7 November 2018 (UTC)

Авгур I am sorry but this project is out of scope for Community Tech team. It will need community consensus before we can do any technical work here. These a Hence I will have to reject this proposal. Sorry about that. If there is community-consensus to do this, we can take this project on in future when we have decided the technical work involved. -- NKohli (WMF) (talk) 22:42, 14 November 2018 (UTC)

Вы пишете о поиске консенсуса в сообществе. Какую площадку для поднятия этого вопроса вы считаете уместной? Возможно данная площадка (ваш опрос не вполне подходит) и мне жаль, что я вас озадачил. Но я был обязан обозначить проблему. (Гугл-перевод en: You write about finding consensus in the community. What is the appropriate platform for raising this issue? Perhaps this site (your survey does not quite fit) and I am sorry that I puzzled you. But I was obliged to identify the problem.) Авгур (talk) 20:43, 15 November 2018 (UTC)
@Авгур: The best place to propose this would be at Proposals for new projects. Good luck! Ryan Kaldari (WMF) (talk) 20:45, 19 November 2018 (UTC)

Wikipedia-eigenen Kurz-URL-Dienst

 N Merged with Create URL Shortener extension for Wikimedia wikis

  • Problem: Wiki links are not permanent (unstable) and under some circumstances very long (Wikipedia own short url service) / de: Wiki-Links sind nicht permanent ("instabil") und unter Umständen sehr lang (Wikipedia-eigenen Kurz-URL-Dienst)
  • Who would benefit / Wem würde dieser Wunsch helfen: Readers and Wikipedians / de: Leser und Wikipedianern
  • Proposed solution / Lösungsvorschlag: for every Wikipedia article, image, etc a permanent short link is automatically created and is displayed at the end of the article. The link also persists if a rename takes place. (If articles get merged, both permanent links get displayed at the end of the article. Only when an article gets completely deleted, the permanent link also becomes invalid. Examples below: "long and renamable"; "short and permanent". / de: zu jedem Wikipedia-Artikel, jedem Wikimedia-Bild usw. wird automatisch ein Permanet-Short-Link erzeugt und ganz am Ende des Artikels angezeigt, der auch bestehen bleibt, wenn eine Umbenennung erfolgt.

(Werden Artikel zusammen geführt, werden am Ende des Artikel beide Permanent-Links angezeigt. Erst wenn ein Artikel komplett gelöscht wird, wird auch der Permanent-Link ungültig.)


Beispiel für Wikipedia:

lang und umbenennbar ("instabil"):

* https://de.wikipedia.org/wiki/Gesetz_%C3%BCber_das_Verfahren_in_Familiensachen_und_in_den_Angelegenheiten_der_freiwilligen_Gerichtsbarkeit


kurz und permanent ("stabil"):

* https://wo.srt/12!3ABC46x


Beispiel für Wikimedia Commons:


lang und umbenennbar ("instabil"):

* https://commons.wikimedia.org/wiki/File:20161111_xl_P1090340-1986-2016-Dokumentation-30-Jahre-SFV-drei-gruendungsmitglieder-zu-besuch-vlnr.-Bernd-Brinkmeier--Gruendungsmitglieder--Klaus-Greven--Wolf-von-Fabeck--Dedo-von-Krosigk--sowie-Alfons-Schulte.jpg


kurz und permanent ("stabil"):

* https://cwo.srt/12$abc45X

(Einen Ansatz muss es im Hintergrund schon geben!? siehe hier (zu meinem Beispiel): https://commons.wikimedia.org/?curid=55175785 Dies wird aber leider nicht automatisch angezeigt.)

--Molgreen (talk) 05:35, 10 November 2018 (UTC)

Discussion

  • This seems like a not-great project for Wikimedia. En.WP already bans shorteners regardless because the only interesting use case for shorteners is to obscure the link of interest. Which is more useful for trolls and vandals than it is for legitimate users. --Izno (talk) 01:27, 10 November 2018 (UTC)


thank you, Izno for your contribution. I have adapted my proposal:
exactly this danger I see too: deshallb my suggestions:
* only wiki-internal short-links can be generated
* The links can only be created manually by "viewers" and "admins"
* if something changes at the destination, the link has to be re-sighted
  • Or a completely different suggestion:
for each Wikipedia article / Wikimedia image, etc., a permanent short link is automatically generated, which also remains when renamed. (see above)

--Molgreen (talk) 04:54, 10 November 2018 (UTC)

In Wikidata, we want a URL shortener for completely different reasons: the most important one, as far as I’m aware, is that URLs to queries on the Wikidata Query Service are a pain to share because they’re so long and contain special characters, so a URL shortener would be very useful to be able to share queries more easily. (In fact, a URL shortener is already integrated into the Query Service UI, but since it’s not a Wikimedia-specific one, it’s blocked on all wikis, making it less useful.) See phabricator:T44085 and the (many) related tasks for some discussion on this. --Lucas Werkmeister (talk) 13:39, 10 November 2018 (UTC)
Only if the article remains connected to that specific item--of course, not a guarantee. --Izno (talk) 16:27, 10 November 2018 (UTC)
A one-to-one relationship and a guarantee would be important to me --Molgreen 16:59, 10 November 2018 (UTC)
  • Thank you for the feedback.

Then I really hope that the stable URLs will be easy(!) to find in Wikipedia articles and commons files in the future.

Question: should I withdraw the proposal better?

--Molgreen 14:19, 10 November 2018 (UTC) Molgreen There is another proposal in the survey - Create URL Shortener extension for Wikimedia wikis that is very similar to what you are asking for, I think. Does that sound correct? I will archive your proposal in favor of the other one but please let me know if that is not correct. -- NKohli (WMF) (talk) 22:52, 14 November 2018 (UTC)

Hi NKohli (WMF), yes I agree
another question: should the following links have the same destination?
if so, I would adapt that here:
because the following page is empty ("More comments: Requests for comment/URL shortener service for Wikimedia"):

--Molgreen 19:27, 16 November 2018 (UTC)

@Molgreen: You seem correct. The https://foundation.wikimedia.org website is outside our work area and it is discouraged to use that wiki. I think the proposer mistakenly added that link. I will ask them to fix it. Thanks for bringing this to my attention. -- NKohli (WMF) (talk) 20:02, 16 November 2018 (UTC)


Make references/sources of protected items visible for users without a account

  • Problem: In Wikidata there are items (like for example coutries etc) which are protected. Reference/sources for such items are only visible for users with a wiki-account. If some statements are used for example in Wikipedia and a user tries to comprehend the source then this is only possible if he/she makes an account. This may an argument not to use Wikidata statements in other wiki projects.
  • Who would benefit: Other wiki projects but also wikidata itself as reliable source especially for sourced statements.
  • Proposed solution: Make the references/soruces of pretected items accesible for non registered users in read-only modus.
  • More comments:
  • Phabricator tickets: T186006
  • Proposer: Datawiki30 (talk) 20:37, 7 November 2018 (UTC)

Discussion

  • This is a bug that was being worked on as of 2 weeks ago. I've added the task. --Izno (talk) 21:21, 7 November 2018 (UTC)

Copy Statements for Similar Items

 N Superseded by Freely editable input mask

  • Problem: Creating multiple New Items for Journal Articles from the same Journal can be time consuming?
  • Who would benefit: Anyone who is trying to create a lot of items with similar or the same statements.
  • Proposed solution: A tool, gadget or option to copy multiple statements from one item to others instantly.
  • More comments: Apologies if this has already been asked!
  • Phabricator tickets:
  • Proposer: --Wallacegromit1 (talk) 03:20, 4 November 2018 (UTC)

Discussion

@Wallacegromit1: Such a user script already exists: d:User:Matěj Suchánek/moveClaim.js. Also, if you are creating lots of items about journal articles you might want to use something like QuickStatements instead of making them manually. Jc86035 (talk) 07:01, 4 November 2018 (UTC)

@Jc86035: Thanks You! --Wallacegromit1 (talk) 09:35, 4 November 2018 (UTC)

Wallacegromit1 I will close this proposal as there is a user script linked already by Jc86035. There is also another wish - Freely editable input mask which proposes a similar feature. I hope nobody minds. Please ping me if you have any concerns/questions. Thank you for submitting this proposal. -- NKohli (WMF) (talk) 23:26, 14 November 2018 (UTC)

Actively work to incorporate Wiktionary into Pleco

  • Problem: Should be added not just in the paid version but also the free version.
  • Who would benefit: Chinese-English Wiktionary entries will probably get more attention from people interested in Chinese over the course of the coming years and decades which would benefit not only Chinese-English entries but all of Wiktionary; Chinese language students currently unfamiliar with wiktionary will have a platform to exchange ideas about the meaning of Chinese words (rather than be forced accept dictionary definitions some of which may not be very good); the Pleco app will become a more powerful tool and Mike Love will make money
  • Proposed solution:
  • More comments: The current format of free Pleco wouldn't really work with wiktionary, but there are rumors that there is a revamping of Pleco in the works with the intent to include wiktionary in some fashion.
  • Phabricator tickets:
  • Proposer: Geographyinitiative (talk) 01:34, 4 November 2018 (UTC)

Discussion

@Geographyinitiative: This sounds like a potential consumer of the Lexicographical data project which is being worked on? It looks like Pleco is not free software and its source code is not available in public (please correct me if I am wrong!), so once the Lexicographical Data project has made more progress, integration would have to be done by Pleco developers. That also means that there is not much that the Community Tech team can do here. --AKlapper (WMF) (talk) 02:19, 4 November 2018 (UTC)

I have archived it, because it is not possible for us to help, due to closed-source software. Quiddity (WMF) (talk) 00:23, 15 November 2018 (UTC)

Structured Wikiquote