Jump to content

Community Wishlist Survey 2019/Archive

Add links
From Meta, a Wikimedia project coordination wiki

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

  • 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)[reply]
    @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)[reply]

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

NoN 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) [reply]

Reinstate all Chinese Wikipedia's CheckUsers' permissions

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

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


@AKlapper (WMF): https://meta.wikimedia.org/wiki/Special:Log?type=rights&user=WMFOffice&wpdate=2018-03-31 --Krenair (talk • contribs) 12:48, 30 October 2018 (UTC)[reply]
Anyway this appears to be completely nontechnical. --Krenair (talk • contribs) 12:49, 30 October 2018 (UTC)[reply]
@AKlapper (WMF): Wikipedia talk:用戶查核#Notification of Wikimedia Foundation actions regarding local CheckUser. — regards, Revi 12:50, 30 October 2018 (UTC)[reply]
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)[reply]
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)[reply]
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 (talk • contribs) 14:56, 30 October 2018 (UTC)[reply]
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)[reply]

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

Stack trace of errors (error handling) by parser functions

NoN 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

NoN 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) [reply]

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

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

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

@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)[reply]

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

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

@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)[reply]
@Theklan: Sorry, I can't because I already have three active proposals. Jc86035 (talk) 05:45, 31 October 2018 (UTC)[reply]

Require Editors to Have Accounts and Login Before Editing

NoN 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) [reply]

Provenance

NoN 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)[reply]

Thank you for asking. I think I mean both. Orphée (talk) 15:47, 30 October 2018 (UTC)[reply]
@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)[reply]
Thanks anyway for your answer and solution. Orphée (talk) 18:39, 30 October 2018 (UTC)[reply]
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)[reply]

Centralized templates and modules

NoN 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:

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)[reply]
  • 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)[reply]
    • @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)[reply]
  • 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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]

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

  • 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)[reply]
    • 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)[reply]
      • 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)[reply]

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

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 (talk • contribs) 14:20, 30 October 2018 (UTC)[reply]

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

Allow viewing of own deleted contributions on Special:DeletedContibutions

NoN 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)[reply]

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

@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)[reply]
Yes, we ran this past our legal team. MaxSem (WMF) (talk) 23:05, 31 October 2018 (UTC)[reply]

Vote for your admins

NoN 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:

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

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

Vote for undo action

NoN 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:

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

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

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:

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:

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)[reply]
@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)[reply]
Sure, archive it. No problem with that from my side.--JTCEPB (talk) 01:37, 31 October 2018 (UTC)[reply]

OSM map on dewiki

NoN 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)[reply]

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

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)[reply]
@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)[reply]
@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)[reply]

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

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

Discussion

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

Discussion

Central repository for gadgets, templates and Lua modules

NoN 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

NoN 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)[reply]

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

@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)[reply]
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)[reply]
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)[reply]

Limiter la durée des mandats

NoN 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)[reply]
  • 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)[reply]

  • 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) ][reply]

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

Searches with Pronoun

NoN 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.[reply]

Discussion

turtles like pronouns a lot — The preceding unsigned comment was added by 206.57.199.209 (talk) 19:26, 5 November 2018 (UTC) [reply]

Implement widespread autoarchiving

NoN 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)[reply]

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

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

Add a search and ranking system to structured discussions

NoN 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)[reply]

@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)[reply]
@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)[reply]
I renamed the proposal and made changes to bring precisions. Prométhée (talk) 08:26, 2 November 2018 (UTC)[reply]

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

Release VE on Talk pages

NoN 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)[reply]

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

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

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

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

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

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

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

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

NoN 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)[reply]

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

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]

NoN 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)[reply]

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

@Galobtter: Some good points. I've amended the proposal to address your comments. — Insertcleverphrasehere (or here) 09:13, 30 October 2018 (UTC)[reply]
(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 (talk • contribs) 09:22, 30 October 2018 (UTC)[reply]
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)[reply]
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 (talk • contribs) 09:41, 30 October 2018 (UTC)[reply]
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)[reply]

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

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)[reply]
Probably another thing would be making it work in mobile.. Galobtter (talk) 06:15, 31 October 2018 (UTC)[reply]
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)[reply]

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

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

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

Wikimedia Workshop/Seminar/Conference for the Visually-Impaired

NoN 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)[reply]

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 (talk • contribs) 11:51, 5 November 2018 (UTC)[reply]

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

Solution to the ‟Bonnie and Clyde” problem

NoN 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)[reply]

Discussion

mw.toolbar zurück

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)[reply]
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)[reply]
wo ist sie hin? --Atamari (talk) 14:50, 6 November 2018 (UTC)[reply]
Mal wieder eine tolle Leistung der WMF. --DaB. (talk) 15:12, 6 November 2018 (UTC)[reply]
How are we ever going to gain new authors if you anger the existing ones? --voyager (talk) 15:17, 6 November 2018 (UTC)[reply]
[3] «« Man77 »» [de] 15:25, 6 November 2018 (UTC)[reply]
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)[reply]
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)[reply]

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

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)[reply]
That is not unsurprising. People who are not affected have no reason to contribute in such discussions ;) —TheDJ (talk • contribs) 16:03, 6 November 2018 (UTC)[reply]
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)[reply]

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

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

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

@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)[reply]
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)[reply]

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

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)[reply]
Is that the next move in your great strategy to get rid of highly productive authors? --voyager (talk) 17:17, 6 November 2018 (UTC)[reply]
I entirely agree. @MusikAnimal (WMF): I would kindly ask you to immediately restore those signatures.--Hildeoc (talk) 17:22, 6 November 2018 (UTC)[reply]
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)[reply]
I reverted your manipulation. That is inapprehensible! Chaddy (talk) 17:47, 6 November 2018 (UTC)[reply]
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)[reply]
No, not in 10 days. This has to be visible NOW! Chaddy (talk) 17:51, 6 November 2018 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
Thank you! Chaddy (talk) 18:17, 6 November 2018 (UTC)[reply]

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

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

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

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

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

This section is called "Discussion". I don't see how writing "+1" discusses the proposal. --AKlapper (WMF) (talk) 18:08, 6 November 2018 (UTC)[reply]
Really? Since when do you use the internet? Chaddy (talk) 18:17, 6 November 2018 (UTC)[reply]
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)[reply]
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)[reply]

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

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)[reply]
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)[reply]
  • 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)[reply]
    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)[reply]
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)[reply]

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

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

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)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
Wiki loves strategies to scare off users... --DaizY (talk) 19:49, 6 November 2018 (UTC)[reply]
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)[reply]
@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)[reply]
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)[reply]
Ok thanks. I'm going to continue discussion on your talk page, Itti. MusikAnimal (WMF) (talk) 21:08, 6 November 2018 (UTC)[reply]
@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)[reply]
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)[reply]

(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)[reply]

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

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

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

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

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

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)[reply]
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)[reply]
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:FORUM —TheDJ (talk • contribs) 08:34, 8 November 2018 (UTC)[reply]

Are you kidding us? Chaddy (talk) 19:37, 8 November 2018 (UTC)[reply]
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)[reply]

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

Discussion

Permettre que tout Wikipedia puisse fonctionner en mode visuel

NoN 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)[reply]

Discussion

Articles for deletion process

NoN 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)[reply]

Discussion

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

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

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

Add most common tags in available tag list

NoN 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

Force contributors to write an edit summary

NoN 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

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.][reply]

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)[reply]
    • 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)[reply]
      • @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)[reply]
    • 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)[reply]
    • 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)[reply]
      @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)[reply]

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

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

Discussion

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

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

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

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

Discussion

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

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

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: Gareth (talk) 08:36, 10 November 2018 (UTC)[reply]

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: Gareth (talk) 08:37, 10 November 2018 (UTC)[reply]

Discussion

Map zoom and positioning improvements

Withdrawn by proposer (too many proposals)

Map
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: Gareth (talk) 08:34, 10 November 2018 (UTC)[reply]

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: Gareth (talk) 08:35, 10 November 2018 (UTC)[reply]

Discussion

Sectional page protection

NoN Technically infeasible

  • 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)[reply]

Discussion

Archived

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

Move references to Wikidata

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

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)[reply]
    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)[reply]
    @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)[reply]

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

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

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)[reply]
    @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)[reply]

no nowiki in Visual Editor

YesY Solved

  • 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)[reply]

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)[reply]
@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)[reply]
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)[reply]
I think this is discussed in task T128060. Kaldari (talk) 05:18, 31 October 2018 (UTC)[reply]
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)[reply]
<