Wikimedia Meta-Wiki

Community Wishlist Survey 2019/Archive

< Community Wishlist Survey 2019

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

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

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

Discussion

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

Reinstate all Chinese Wikipedia's CheckUsers' permissions

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

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

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

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

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

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

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

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

  • More comments:
  • Phabricator tickets:

Discussion

Option to insert cite in VE without ref tags

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

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

Discussion

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

 N Proposes a social rather than a technical change.

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

Archived

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

Provenance

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

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

Discussion

@Orf3us: Do you mean that this data (owned by (P127)) should be shown in infoboxes, or that a new Wikidata property should be created? Jc86035 (talk) 15:14, 30 October 2018 (UTC)[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

 N Outside the scope of Community Tech

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

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

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

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

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

  • More comments:

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

 N Too problematic from a legal point of view

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

Discussion

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

 N Proposes a policy change rather than a technical feature

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

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

 N Proposes a policy change rather than a technical feature

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

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

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

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

 N Outside the scope of Community Tech

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

Discussion

Simplicity

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

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

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

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

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

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

 N Outside the scope of Community Tech

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

Discussion

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

 N Outside the scope of Community Tech

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

Discussion

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

 N Outside the scope of Community Tech

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

Discussion

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

 N Outside the scope of Community Tech

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

Discussion

You seem to be asking for the feature currently called "Structured Discussions", which has a long and somewhat controversial history. Anomie (talk) 14:23, 30 October 2018 (UTC)[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]

 N Outside the scope of Community Tech

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

 N Outside the scope of Community Tech

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

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

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

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

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

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

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

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

Discussion

Articles for deletion process

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

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

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

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

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

 N Outside the scope of Community Tech

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

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

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

Discussion

Force contributors to write an edit summary

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

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

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

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

Discussion

  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)

 
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

 N 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

 N Proposes a social change rather than a technical feature

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

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

 Y 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]
Summary: This is what happens if you type the trailing characters outside of the blue "cartouche" (i.e., visibly outside the blue link area). This is desirable if you want to link the first bit of a word, but not the rest. (For example, in an article discussing prefixes: `Cisplatin and Transplatin are examples of cis–trans isomerism`). If you type them inside the blue area, then you will not see a nowiki tag (and your label will be piped).
I think this should be withdrawn from the wishlist, because it is working as designed. Whatamidoing (WMF) (talk) 20:33, 2 November 2018 (UTC)[reply]
I had understood the difference before, yet I think that unnecessary pipelinks are not well appreciated in the wiktionary. Nevertheless I will use them in the future and refer to this discussion if criticized. Greetings and thanks, Peter Gröbner (talk) 06:44, 3 November 2018 (UTC)[reply]

Enable two-factor authentication for all wikis

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

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

Discussion

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

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

 N This proposal is too big

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

Discussion

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

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

Archived

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

Avoid generating artifacts in article content versions

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

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

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

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

Discussion

Archived

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

Voice to text editor

 N This feature already exists

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

Discussion

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

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

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

Archived

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

Communication plattform between devs and editors is needed

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

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

Discussion

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

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

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

Available Text to Speech for all wiki Articles

 N Merged with Community Wishlist Survey 2019/Editing/Make Wikipedia more accessible to the visually impaired

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

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

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

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

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

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

  • More comments:
  • Phabricator tickets:

Discussion

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

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

Anti-vandalism tool for patrollers and reviewers

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

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

Discussion

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

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

A course on Wikipedia similar to ones on Coursera or EdX

 N Not a technical proposal

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

Discussion

Opps, sorry. I read the intro page more carefully. This isn't technical. I've shifted this to Village Pump. Thanks. DiplomatTesterMan (talk) 11:20, 11 November 2018 (UTC)[reply]

Correct date format on Wikidata

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

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

Discussion

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

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

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

 N This proposal is unclear

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

Discussion

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

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

Archived

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

Timeline in maps

 N Too big for Community Tech

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

Discussion

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

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

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

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

 
 

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

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

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

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

Archived

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

Add Admin functionality to mobile sites

 N Already under development

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

Discussion

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

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

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

Centralised language independent wikiproject for modules and templates

 N This problem is covered better by Shared Multilingual Templates and Modules available to all wikis

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

Discussion

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

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

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

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

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

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

Intra-template VisualEditor

 N Outside the scope of Community Tech

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

Discussion

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

WikiCite context

 N Outside the scope of Community Tech

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

References

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

Discussion

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

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

Collaboration tool

 N Too big and outside the scope of Community Tech

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

Discussion

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

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

Create an editor dashboard

 N Too broad for the Community Tech

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

Discussion

Samwalton9: Unfortunately, this proposal is too broad for the Community Tech team to take on. There are a lot of features included in your description, plus the ability to customize everything. It's just too big for the team, sorry. -- DannyH (WMF) (talk) 01:59, 14 November 2018 (UTC)[reply]
@Samwalton9: It seems that Extension:GrowthExperiments is a good base on which eventually add new features. Actually it addresses some points included in this proposal, implementing the initial page that provides help to newbies and advises some easy edits to make. ZandDev (talk) 01:57, 18 February 2023 (UTC)[reply]

Simultaneous editing

 N Too big for the Community Tech

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

Discussion

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

Simultaneous editing with CollabPad

 N This proposal duplicates Simultaneous editing

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

Discussion

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

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

Graduate 2017 wikitext editor and make it a full value editor

 N Outside the scope of Community Tech

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

Discussion

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

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

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

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

Change colours of Machine/Human translation bar in Translation tool

 N On roadmap of another team

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

Discussion

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

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

Enable Visual Editor for all non-talk-namespaces

 N Needs further discussion and proposer did not respond

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

Discussion

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

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

 N Needs further discussion

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

Discussion

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

Smarter decision-making

 N Outside the scope of Community Tech

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

Discussion

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

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

Display a password strength bar

 N The work on this proposal is outside the scope of Community Tech, as it falls on the Security Engineering team

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

Discussion

Hi Daylen: The work that we do on passwords is determined by our Security Engineering team. They've got some plans to make passwords stronger on our sites. We'll have to decline this proposal as being outside the scope of the Community Tech team. Sorry about that, thanks for participating in the survey. -- DannyH (WMF) (talk) 02:58, 14 November 2018 (UTC)[reply]
@DannyH (WMF): This proposal is for a non-binding password strength bar, not a requirement for a minimum password length or strength. Under this proposal, it would be up to each community to decide whether to display the bar and what the requirements (if any) are. I realize that these are global accounts, but I still believe that giving each community a choice is the best option. I also don't understand how this is outside of the scope, as 2FA for all accounts has been suggested in previous community wishlist surveys. Cheers, Daylen (talk) 05:06, 17 November 2018 (UTC)[reply]
Daylen: Providing the option for 2FA is still on the survey and doing pretty well, so we may be talking about changes to the system there as well. Our Security Engineering team is doing a lot of work to increase security on the wikis right now, and we're trying to keep CommTech out of their way, while they make changes. Sorry, I know it's disappointing to have your proposal declined. -- DannyH (WMF) (talk) 19:24, 17 November 2018 (UTC)[reply]

Allow update of stored edit-summary

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

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

Discussion

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

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

Translate Infobox via WikiTranslation

 N Language team is already working on this

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

Discussion

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

Improved style and internationalized labels in Wikimedia Maps

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

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

Discussion

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

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

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

 N This proposal is based on a resource that is being discontinued

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

Discussion

Namespace for image sets

 N Requires community consensus

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

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

Discussion

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

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

Archived

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

Internal transcoder to webm

 N This feature already exists

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

Discussion

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

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

Archived

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

Support for the IIIF Image API on Wikimedia Commons

 N This proposal is too big

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

Archived

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

Expandir os artigos com mais traduções.

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

Discussão

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

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

Make Wikidata more intuitive to use

 N Proposal is unclear

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

Discusión

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

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

 N Does not propose a technical change

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

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

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

Discussion

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

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

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

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

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

Describing the geometry and logic of geographical objects on Wikidata

 Y Solved

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

Discussion

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

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

Obliger les contributeurs à créer un compte pour contribuer

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

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

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

Discussion

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

Copy references to another property

 Y Solved

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

Discussion

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

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

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

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

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

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

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

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

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

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

Обсуждение

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

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

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

Wikipedia-eigenen Kurz-URL-Dienst

 N Merged with Create URL Shortener extension for Wikimedia wikis

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

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


Beispiel für Wikipedia:

lang und umbenennbar ("instabil"):

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


kurz und permanent ("stabil"):

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


Beispiel für Wikimedia Commons:


lang und umbenennbar ("instabil"):

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


kurz und permanent ("stabil"):

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

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

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

Discussion

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


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

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

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

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

Question: should I withdraw the proposal better?

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

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

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

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


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

 N This is already a bug tracked in Phabricator

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

Discussion

Bug closed as fixed on Dec 13, 2018. ZandDev (talk) 20:37, 19 February 2023 (UTC)[reply]

Copy Statements for Similar Items

 N Superseded by Freely editable input mask

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

Discussion

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

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

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

Actively work to incorporate Wiktionary into Pleco

 N Technically infeasible

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

Discussion

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

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

Structured Wikiquote

 N Proposals for new projects are out of scope for this survey

  • Problem: Wikiquote exists as a "compendium of sourced quotations from notable people and creative works in every language". While the compendium is quite large, it is not very useful. It is difficult, if not impossible to query quotations. You cannot even link to a specific quotation on a page. The categorization of a quotation can be dififcult as well. Should this be on the page for the person that said it or on the page for the work it is in or on the page for event it relates to? Also, it is impossible to get reference querieis from Wikidata other than getting the entire page of quotations. Say you want quotes from Abraham Lincoln (Q91) bur only related to 1860 United States presidential election (Q698842) that would be nearly impossible to get without getting the entire page and parsing through the quotations. Also, it is extremely difficult to get a single quotation in a different language.
  • Who would benefit: Anyone who reads or wants to use the data contained in Wikiquote. Editors of Wikiquote would bennefit as it would be easier to catalog quoatations. Translators of quotations would also bennefit as it would be much easier to see which quotations need to be translated and which translationsa are available.
  • Proposed solution: Structured Wikiquote. Combine all of the Wikiquote communities into a single Wikiquote site that runs on Wikibase. Each quoatation would be a new item as described in the development plan. Some properties would allow linking to Wikidata items, or could allow for linking to other items on Wikiquote.
  • More comments: We could preserve the existing "Pages" by converting these into item queiries. For instance, the page on Abraham Lincoln could be a query that would list all of the quotes, grouped by the date / event propertes. This would also allow these pages to be rendered in the user's prefered language. But I would prefer to have the quote item in the mainspace, but maybe the existing pages can be in a new namespace (with a automatic redirect) or could automatically redirect to a special page with a dynamic query or something.
  • Phabricator tickets: T71753
  • Proposer: U+1F360 (talk) 01:55, 8 November 2018 (UTC)[reply]

Discussion

I hope this can happen some day, it is a really interesting idea! For reference: Structured Wikiquote and d:Wikidata:Wikiquote.--Micru (talk) 15:10, 10 November 2018 (UTC)[reply]

Archived

Unfortunately, this proposal is out of scope for this survey, you should probably post it to Proposals for new projects. Thanks for participating in our survey. MaxSem (WMF) (talk) 00:58, 14 November 2018 (UTC)[reply]

I don't think it is a proposal for new project instead it's more like renovating an existing project? C933103 (talk) 14:47, 14 November 2018 (UTC)[reply]
C933103, even if so - that would have involved a lot of changes which means that we won't work on this without consensus from the particular wiki's community. MaxSem (WMF) (talk) 05:37, 15 November 2018 (UTC)[reply]

Two windows view for editors

  • Problem: In Wikisource exists proofread extension, which have some bugs, but some editors use it. But not all books have scan on Commons, and for small communities is almost impossible to re-scan all those books which are in various archives and libraries. Possibility of viewing source text and wikisource page together in one display would be fine.
  • Who would benefit: Wikisource editors
  • Proposed solution: Make extension for viewing wikisource page together with external scanned page
  • More comments: Some browsers (like Vivaldi) are able to display more pages in one tab - so called stacked tabs
  • Phabricator tickets:

Discussion

What would the proposed solution do that can't be duplicated by just opening two browser windows and arranging them in your screen side-by-side (or using that feature of Vivaldi)? Anomie (talk) 12:21, 1 November 2018 (UTC)[reply]

This feature is only in Vivaldi, so extension will be useful for users of other browsers.
Two browsers in one screen is possible, but when user have open other programs, is it little problematic, when wants to have other tabs in browser opened, or other programs in computer.
This solution will be for every browser without limitations for other work. JAn Dudík (talk) 13:02, 2 November 2018 (UTC)[reply]

@JAn Dudík: When the scan is not on Commons, where would that "external scanned page" be located instead? --AKlapper (WMF) (talk) 12:55, 2 November 2018 (UTC)[reply]

archive.org, kramerius.cz, libraries etc. JAn Dudík (talk)
In that case I would have had the same question as Anomie already. Personally I'm not convinced that a website should solve problems that a web browser or an operating system which can draw more than one application window on a screen can solve... --AKlapper (WMF) (talk) 22:38, 3 November 2018 (UTC)[reply]
Sorry JAn Dudík, I personally don't understand your problem with proofread page extension. In brief I stand that you the external scan images in one side view. But could please explain why you scan book not uploaded in commons or locals?? If a small community not able to scan , but how you get the scan for side view, what you are demanding? Thank you. Jayantanth (talk) 20:51, 4 November 2018 (UTC)[reply]
@Jayantanth: We aren't scanning these texts, these texts are already scanned on some external website. e.g. Q2041543 (Q2041543) consists of 28 volumes, about 1000 pages each - why scan again when free scan exists on archive.org?
For safety issues, this tool should be restricted for certain websites (url patterns), confugurable per wiki. JAn Dudík (talk) 20:26, 5 November 2018 (UTC)[reply]

This will be best solved by uploading scans to Commons and using the standard Wikisource systems. For external sites, a browser or OS that supports tiled windows is best. I'll archive this proposal; hope that's okay. Sam Wilson 00:35, 15 November 2018 (UTC)[reply]

Note also that it's not required to re-scan works, but just upload those scans from elsewhere to Commons. Sam Wilson 00:37, 15 November 2018 (UTC)[reply]

 N This feature already exists

  • Problem: Red links are unconnected, although the item that holds more info is often already out there on Wikidata (and therefor on other wiki's)
  • Who would benefit: The reader
  • Proposed solution: Connect a red linkt title somehow to wikidata, and give the reader some info (for example from Reasonator) when clicked
  • More comments:
  • Phabricator tickets:

Discussion

  • This seems like a very useful proposal. It could also fix the problem where multiple articles (and items) get made about the same subject. During the Wiki Techstorm i made a small prototype of how something like this could be used to display hovercards for red links, just like what we have now for blue links. See here. Husky (talk) 18:04, 30 October 2018 (UTC)[reply]
  • I think this is the same proposal as Community Wishlist Survey 2019/Wikidata/Add to unexisting page a link to some Wikidata item. — putnik 00:42, 31 October 2018 (UTC)[reply]
  • As long as this doesn't somehow discourage page creation at the redlink. The purpose of redlinks is to alert editors "here's an article you could create". If they clicked it and it looked like there was already something there, it may discourage actually creating the new article. --Jayron32 (talk) 11:55, 31 October 2018 (UTC)[reply]
  • The interlanguage-template would solve some of this issue indeed. Interesting idea. But I'm afraid that such a template will not be allowed by the NL-wiki community, usually they are very conservative and someone will step up against the idea of empty pages with only a "useless" template and speedy delete half of the wiki from there. Therefor I need a solution that will keep the red link red. Sorry for that. Edoderoo (talk) 19:48, 1 November 2018 (UTC)[reply]
    @Edoderoo: I moved your comment here, as things on the talk pages are likely to never be seen. Sorry for the confusion! I'm going to rework the automation to redirect talk pages to the proposal page. MusikAnimal (WMF) (talk) 21:00, 1 November 2018 (UTC)[reply]
  • There used to be a template that did this but I think it died on enwiki due to Wikidata opposition. This is entirely a question of policy within individual Wikipedia's and not an issue for the Community Wishlist that is supposed to contain technical requests. ChristianKl (talk) 17:57, 2 November 2018 (UTC)[reply]
    • I am not sure what sort of discussion ot have had and what templates was there, however I think a major problem with using a template is that the page will no longer be a red link. My understanding is that this request is requesting another method that would link those pages from/to wikidata while still maintaining them as red link. C933103 (talk) 18:28, 2 November 2018 (UTC)[reply]
      • You are right. Right now, when clicking a red link, you get a page explaining it doesn't exist, and a like to create the page. This should stay, but it can also add a link (or table, widget, etc) to connect it to an existing wikdata-item. When the page gets created later by another user, it can be linked easier. Edoderoo (talk) 19:38, 2 November 2018 (UTC)[reply]
        • EnWiki is opposed to anything that links to a Wikidata item directly in a way that's visible to users. ChristianKl (talk) 11:17, 4 November 2018 (UTC)[reply]
          @ChristianKl and Edoderoo: Not necessarily. I think neither Wikidata opponents nor Wikidata proponents constitute a majority, even among the minority of editors who participate in requests for comment and the like. Most of the opposition has been based on vandalism and incorrect data (and there has so far been no proposal to use JavaScript/CSS to actually hide the sidebar links). Jc86035 (talk) 14:33, 4 November 2018 (UTC)[reply]
    @ChristianKl: The interlanguage link template can still be used to link to Wikidata on enwiki (it looks like Article that doesn't exist (Wikidata)), and the Wikidata parameter is still used on about 2,000 pages. There was an RfC on whether Wikidata should be linked to in articles, but it was closed with no consensus. I don't think this proposal would significantly improve that specific template, since it would still be required to manually supply the QID (although it would be possible to avoid manually linking the article title itself) due to it being impossible to get a QID from a sitelink. Jc86035 (talk) 14:24, 4 November 2018 (UTC)[reply]
    Maybe the "impossible to get a QID from a sitelink" can be improved as part of the proposal. It would also be neat that, if there is a Template:ill|en red link on certain language wikipedia, when some editor click into the link and created a page, the wiki would remember that the page was created by clicking that ill template, and thus linking the same wikidata item as the foreign language article linked from the original ill template. But I don't think that'd be too easily implementable. C933103 (talk) 12:10, 5 November 2018 (UTC)[reply]
    Okay, I stand corrected and it seems like this is possible gain with the interlanguage link template. ChristianKl ❪✉❫
    • Maybe I'm too direct and offensive to some, but my proposal is not limited to en-wiki and therefor I do not care about issues/discussions/shortage of knowledge for en-wiki users. Therefor I also do not care if en-wiki will implement such a feature or not (and most likely nl-wiki will also make some drama at first). But if es-wiki or hu-wiki will use it, I would be still happy, even when I'm not active on their projects. Sorry for being direct in my statement, it is not meant to offense anyone, but please look further then en-wiki only. Edoderoo (talk) 08:48, 5 November 2018 (UTC)[reply]
  • User:Multichill recently introduced d:Wikidata:Property_proposal/Wikipedia_suggested_article_name on Wikidata, to record what should be the article name on a particular language wiki to correspond to a Wikidata item, if currently there is no article. The idea is that software could then created to identify redlinks matching these names on a wiki page being displayed, and give either a link to Wikidata, or show some summary of information derived from Wikidata. So far his proposal hasn't met an entirely positive response, but it is one facet of what could be needed to make a suggestion like this work. Jheald (talk) 20:01, 5 November 2018 (UTC)[reply]
  • maybe we add a feature to mark these sitelinks also red in wikipedias, or just hide them. so any wikipedia can configure it as wanted. --W!B: (talk) 12:45, 9 November 2018 (UTC)[reply]

Archived

What you're asking for is essentially ArticlePlaceholder. We can enable it on wikis that want it, but it requires local consensus. Thanks for participating in our survey. MaxSem (WMF) (talk) 00:52, 15 November 2018 (UTC)[reply]

So what's needed is to implement this extension on wikipedia? C933103 (talk) 06:08, 15 November 2018 (UTC)[reply]

add publish as e-book tool to allow offline reading

  • Problem: wikisource reading requires internet connection to read
  • Who would benefit: readers with e-book readers, and off line readers
  • Proposed solution: create a publish as e-book tool to render wikisource output in e-book format
  • More comments: e-books while a cul-de-sac output, retains some loyalty among readers. reading pdf's on e-reader is not optimal. there is a body of readers here which we can target
  • Phabricator tickets:

Discussion

@Slowking4: This might be phab:T97672 and phab:T74077? --AKlapper (WMF) (talk) 03:43, 1 November 2018 (UTC)[reply]

thank you, related to Book Creator lack of support. but don't know if easier. don't know if need an app, as in T74077, just some code to format the content friendly to e-readers. but would be accessible to mobile. typically e-reader users sync to desktop.
rather than create a book, i would like to see a "download in e-book", since download as PDF is not friendly. see also: https://www.kobo.com/help/en-US/article/784/file-formats-you-can-use-on-your-kobo-ereader and Mozilla Firefox has a reader mode in the browser https://addons.mozilla.org/en-US/firefox/addon/reader/ -- Slowking4 (talk) 19:54, 1 November 2018 (UTC)[reply]
@Slowking4: Is this wsexport tool not sufficient for you ? I know that its need to improve. Last year proposal was same for Community Wishlist Survey 2017/Wikisource/Improve export of electronic books. Jayantanth (talk) 21:00, 4 November 2018 (UTC)[reply]
yes, that is the idea. but integrated into the wikisource main menu as a published format. Slowking4 (talk) 03:28, 7 November 2018 (UTC)[reply]
That export tool does not have the option to export ebooks in vertical layout (optionally used by some Asian languages), and also lack the support for international language fonts like CJK languages. C933103 (talk) 02:53, 14 November 2018 (UTC)[reply]
MediaWiki does not support vertical text. --Izno (talk) 04:33, 14 November 2018 (UTC)[reply]
MediaWiki does not (fully) support vertical text (yet). Doesn't mean individual functional tools couldn't be improved to support it. C933103 (talk) 07:05, 14 November 2018 (UTC)[reply]

This proposal is mostly encompassed by Community Wishlist Survey 2019/Wikisource/Improve export of electronic books. I think the bits that aren't around around better advertising of the exports and integrating links into sidebars and elsewhere, and that stuff should only happen after the tool is on a more stable footing. I'll archive this, if that's okay? Sam Wilson 00:59, 15 November 2018 (UTC) [reply]

Tool for easy conversion to DJVU

  • Problem: After the conversion module at the Internet Archive stopped working, converting the files to DJVU has become a pain point.
    français: ("Depuis l'arrêt du module de conversion sur Internet Archive, convertir des fichiers en DJVU est devenu une plaie.")
  • Who would benefit: All Wikisource users.
    français: ("tous les participants à Wikisource")
  • Proposed solution: Create a tool that offers conversion from PDF to DVJU directly on Commons, or salvage the old tool at the Internet Archive.
    français: ("créer un outil proposant la conversion de PDF en Djvu directement sur Commons ou récupérer l'ancien outil d'Internet Archive")
  • Other comments:

Discussion

This was posted in French. I've done a rough translation to English, but kept the French original below. /Johan (WMF) (talk) 18:43, 2 November 2018 (UTC)[reply]

Converting pdf into djvu is not so hard, there's a free excellent routine pdf2djvu both for Windows and Unix/linux; the problem is to build a djvu with the best possible OCR text layer. IMHO IA discontinued djvu output because it turns out useful for a minimal number of items. Perhaps IA could activate djvu output again "on demand" for items where djvu is needed; I hope that Wikimedia Foundation and Internet Archive staff could find an agreement about. In the meantime, IA Upload can already build a djvu with an excellent OCR layer from many IA items, and I feel that the residual issues for difficult cases could be fixed soon. --Alex brollo (talk) 19:29, 5 November 2018 (UTC)[reply]
pdf2djvu is not so easy to use (especially the first time). Adding a text on Wikisource is complicated and I would like to make some steps easier. I forgot to say that modify a DJVU (because there is something wrong with a file) is also very complicated. Sorry for my English... --Shev123 (talk) 10:19, 6 November 2018 (UTC)[reply]
this is totally true. For Mac users, like me, that relied on Internet Archive for the Djvu conversion, it is now really a problem.
User:Tpt has included a conversion from pdf/jp2 to Djvu when using IA-upload to import a book from IA that has no Djvu, but this implies that the book is already on IA. Then a first conversion is done on IA, that may take hours (and recently 2 days) on a book. And the on-the-fly conversion to DjVu sometimes fail (just have a look at the tool's page).
To import books from Gallica, or Google, or other libraries, it would be really great to have an online tool, that would allow to convert pdf file) to DjVu when importing directly (without having to upload to IA first), or even convert to DjVu files already uploaded on Commons...
for now, the process can take up to 2-3 days before the file is uploaded and ready for correction, which is much, much longer, and really problematic, since users with technical abilities to convert files have left.
a tool, usable by users without specific technical ability, to themselves upload a book file, and have it converted to DjVu, would certainly improve the project and relieve some of the pression on the very few who have the technical ability... --Hsarrazin (talk) 16:59, 6 November 2018 (UTC)[reply]

I think the main problem is that we're becoming one of the few remaining communities making any use of DjVu; for most people, PDF suffices and is already part of their workflow. The IA has said they'd look into re-enabling it, but that was a year ago and they've not, so I think we're stuck with fixing up IA Upload — if that's the best thing to do. This proposal basically boils down to fixing the outstanding bugs with IA Upload (which are mostly already documented). I'm going to archive this — hope that's ok? Sam Wilson 02:43, 15 November 2018 (UTC)[reply]

@Samwilson: Veuillez remettre cette proposition au vote. De quel droit l'avez-vous supprimé ? Please put this proposal to the vote. By what right did you suppress it? --Le ciel est par dessus le toit (talk) 12:34, 17 November 2018 (UTC)[reply]

@Le ciel est par dessus le toit: Sorry, I mistakenly made the archiving edit under my personal username, not my WMF one. See below for more rationale for archiving this. SWilson (WMF) (talk) 23:21, 19 November 2018 (UTC)[reply]

@Samwilson: this proposal was not for "fixing IA-upload" but for a full tool, that would allow any wikisource contributor to provide a pdf file or url, and have it uploaded and converted to DjVu without having to upload it to IA first. Could you please put it back where it was ? --Hsarrazin (talk) 17:19, 18 November 2018 (UTC)[reply]

@Hsarrazin: The reason CommTech feel that we can't work on DjVu-generation this year is that it's not simple, and is only of limited use. If someone has a PDF to proofread, then can upload it to Commons with the existing tools, and proofread it from PDF. I'm not trying to say that DjVu isn't a better format in lots of ways, and I'm disappointed that we can't do more with it, but the reality seems to be that it's less and less used by GLAM partners, and the tools for working with it are not evolving. I definitely still think that the issue linked above (for an all-round better ingestion workflow for Wikisource) is something that really needs more focus, but specifically around DjVu I think there's a diminishing return for effort spent on it. Sorry! SWilson (WMF) (talk) 23:21, 19 November 2018 (UTC)[reply]
@Samwilson: There is a technical issue at stake here : on frws, we now work to find scans for texts that were uploaded in main space without scan backup. We have a tool that allows to auto-match the uploaded text with the text layer in the DjVu. It does not work with Pdf, and thus we are obliged to redo the correction work twice, when the book is DjVu and not Pdf. This is really needed for working.
AFAIK wikisource is not mainly used by GLAM partners (not frws), so taking into account the needs of GLAM partners to refuse a legitimate wikisource wish before it is even submitted to vote does not seem fair to me (and the whole frws community I'm now writing for).
Why did you remove it without letting the community vote about it. It is a Community wishlist after all, and the Community should be allowed to vote about it. --Hsarrazin (talk) 08:25, 20 November 2018 (UTC)[reply]
by saying that "we can't work on DjVu-generation this year", you are, in fact, burying the issue, because, next year, even less people will be able to use DjVu, so there will be even less reason (in your opinion)... this is NOT fair to dedicated contributors who should at least be allowed to vote on this... --Hsarrazin (talk) 08:32, 20 November 2018 (UTC)[reply]
@Hsarrazin: Are you referring to the toolforge:phetools match_and_split tool? That indeed showcases one of the advantages of DjVu over PDF (easier traversal of OCR text by page-text). And I'm sorry if you feel like I'm burying the issue; I'm really not trying to. I think we all need to talk more about how and why we're using DjVu, because it takes not inconsiderable technical resources to continue to do so. Basically by archiving this proposal the CommTech team is saying that it's not something that we can technically work on, and that's why it's not worth having people vote on it. I think we'd be better off building tools to work with the formats that are more commonly in use. Again, I do apologise if I've not communicated properly about this. I really do want the best for Wikisource. :) SWilson (WMF) (talk) 10:29, 20 November 2018 (UTC)[reply]

Search through visual identification

 N Outside the scope of Community Tech

  • Problem: When I am walking in the street and wonder about the name of the people honored by the street's name, I need to stop and type on my phone to get the answer. Then, I get to a library and want to check if an old book I like is available on Wikisource, I need to type the whole name on my phone. In the same book, there is a word I don't understand, so I type it in Wiktionary to get a definition. Tired of typing on my phone, I wonder what's more interesting to do in my city and I type the name on Wikivoyage search bar. I typed a lot. And I don't even had a look at the gorgeous gallery of pictures in Wikimedia Commons associated with my city!
  • Who would benefit: Every person with a smartphone looking for information in Wikipedia, a book in Wikisource, a definition in Wiktionary, a tip in Wikivoyage and so on.
  • Proposed solution: Instead of typing, the camera of my phone should identify a word or a sentence in the frame and provide me suggestions of contents related to it in the wikiverse.
  • More comments: I imagine it's a very specific technology here. But Google Translate can identify and suggest a translation, so why we couldn't have a similar way to enter into the wikiverse?

Discussion

Such OCR technology sounds more like in scope for a mobile application, I guess? --AKlapper (WMF) (talk) 14:49, 31 October 2018 (UTC)[reply]

You're right, it may be better classified under Mobile apps, or under both label? Noé (talk) 15:02, 31 October 2018 (UTC)[reply]
Hi @Noé:. This is a really cool idea, and I'd personally really love to see this happen in some capacity. Unfortunately, creating this system is very complicated, and requires developing and maintaining technology that is quite a way beyond the scope of the Wishlist team. I suggest adding this idea to Phabricator; it might be something that can be slowly worked on as a service by a third party. MSchottlender-WMF (talk) 17:55, 15 November 2018 (UTC)[reply]
Hi, MSchottlender-WMF, and thank you for your message. I am not so surprise it is out of the scope, but sometimes, I feel it's healthy to suggest some dreams and to see how they came to life in a far future. So, I just create a Phabricator ticket, T209787   Noé (talk) 16:32, 18 November 2018 (UTC)[reply]

Single property history of an item

 N Outside the scope of Community Tech

  • Problem: When user needs to find a history of changes of the single property of a given item, it is highly uncomfortable and impractical. User needs to go to the history page, click the link to list the history by the highest number (which is not always high enough, so also edit the number in URL then) and then find items by Ctrl-F search on the page, which is however not always all changes relevant to the property, since some are done by bots in bulk with other properties hence are not marked in summary comment via /* ... */ syntax. Diffing of edits which are continuous in given property but not continuous over the entire history is also uncomfortable - user first needs to identify those two and then play with the radio buttons to get the proper diff. No chance to go to the previous/next property change like in regular history tracking by hitting the previous/next diff links.
  • Who would benefit: Whoever needs to check the history of a single property, ie. to track down who made the change and/or when it was done etc...
  • Proposed solution:
    1. Have some sort of the filter on the history page. I.e. selectbox or input with suggest (similar to the one where user creates the property) in which user selects available property and then only relevant edits from the whole history of the item are shown like continuous history, thus browsable by previous/next diff links too. URL params could be then ...&action=history&property=P123...
    2. Aside of every property have an icon to click. When user clicks, it would show i.e. popup window of relevant history.
    3. Both together - clicking on the icon would take user to the filtered history page.
    4. Other?
  • More comments: Caveats: Some properties may have been used in past and then removed. For the beginning it would be good enough to have the availability of single property history for current existing properties of the item only if it is easier to develop, however, for the further future, taking former properties into consideration as well would be great too.
    Special:PropertyHistory/P123/Q456 (or vice versa) would be also nice, but that's just a cherry on the cake...
  • Phabricator tickets:
  • Proposer: — Danny B. 13:10, 11 November 2018 (UTC)[reply]

Discussion

I personally prefer the third solution, however I acknowledge that it is obviously the most difficult one.
— Danny B. 13:10, 11 November 2018 (UTC)[reply]

Add to unexisting page a link to some Wikidata item

 N Outside the scope of Community Tech

  • Problem: Before the article was created we can't use the Wikidata information, still it exists for the same article in other languages.
  • Who would benefit: Wikipedia readers, to know something about the article before somebody could write it.
  • Proposed solution: Add an ability to mark any unexisting page with Wikidata item Q-number. So, we could add, for example, an infobox to MediaWiki:editnotice-0, that will use the Wikidata information, by #property and #statement, and it will look something as Wikidata infoboxes in Commons.
  • More comments: It can be implemented, of course, by adding a new section to Wikidata items. But also, this can be local information. Depends on implementation convenience.
  • Phabricator tickets: None.

Discussion

Something similar exists: mw:Extension:ArticlePlaceholder. --Wargo (talk) 20:06, 29 October 2018 (UTC)[reply]

Yes, I know, thank you. But it is much more complicated, and does not work on any wiki site. I'm talking about using regular local infoboxes, not special pages, so the users will do all the work, and only a little piece of information will be keeped in database. IKhitron (talk) 20:21, 29 October 2018 (UTC)[reply]
I think it's almost like proposal in my ticket phab:T178249, just simple match for new page before creation. — putnik 20:57, 29 October 2018 (UTC)[reply]
Hi, Putnik. Yes, I believe you can say so. IKhitron (talk) 21:15, 29 October 2018 (UTC)[reply]
It might be more useful implementing this the same way we can preview a given page while editing a template. It could have a text input to put the Wikidata entity ID to override the linked Wikidata item of the article. This could work with any page, and not only with unconnected pages. - Agabi10 (talk) 11:34, 30 October 2018 (UTC)[reply]
I think it may be a good idea. Users can create inter-wiki pages in other languages by just clicking the red link on the left, and when they want to create one, they will know there are some existing pages in other wikis they can refer to. --Leiem (talk) 15:29, 1 November 2018 (UTC)[reply]

see #Connect a red link to wikidata --W!B: (talk) 12:45, 9 November 2018 (UTC)[reply]

Hi @IKhitron:, the mw:Extension:ArticlePlaceholder extension aimed to tackle this exact problem, and it is available to wikis if they're interested in enabling it (they should just request it). Providing a separate functionality that changes the way we work with nonexisting pages, and potentially storing the information that links back to wikidata in such a way, requires work which is too big for the scope of what the team can provide through the Wishlist process. I suggest summarizing this request in a ticket so it is saved for posterity and so the Wikidata team and communities can perhaps discuss whether this can be done as part of a strategic process. Thank you for your participation in the wishlist, MSchottlender-WMF (talk) 18:17, 15 November 2018 (UTC)[reply]
Hello, MSchottlender-WMF. Can I try to change your mind, please? This is because (1) the extension is talking about absolutely different issue; (2) ruwiki asked it two years ago and still did not except it because "it is not ready and has bugs"; (3) there is no wiki that used it at all. IKhitron (talk) 18:21, 15 November 2018 (UTC)[reply]
@IKhitron: The extension is enabled in about 14 wikis, but if there are issues that are preventing wikis from using it properly, then we could concentrate on that. If you want, you can adjust this wish to ask for a review on ArticlePlaceholder and assistance on deploying it to more wikis. We might not be able to fix a list of 15 bugs, but we can definitely take a look into this extension, review the necessary and most urgent fixes needed, and help moving its deployment along. MSchottlender-WMF (talk) 18:33, 15 November 2018 (UTC)[reply]
Exactly as I said, MSchottlender-WMF, we can't use it now. I can't help. because I'm not a developer. And what about "the extension is talking about absolutely different issue"? IKhitron (talk) 18:35, 15 November 2018 (UTC)[reply]
I think I am not completely understanding the different issue, then, @IKhitron:. The extension prefills nonexisting pages with data from Wikidata and some other sources, which is answering the need, it seems, and sounds extremely close to what you're asking. Can you be more specific about what your request is that is not answered by the purpose of that extension? MSchottlender-WMF (talk) 18:39, 15 November 2018 (UTC)[reply]
Sure, MSchottlender-WMF. Except the issue of wikilink color, the main problem is that the extension creates predefined infobox. I suggest a way to use the Wikidata link according to communities decisions. One community can decide to show the life dates only with no templates at all, and other to check the local infobox template according to wikitext logic. So, my proposal tooks about 1% of work that is needed to code the extension, but extremelly more powerful. IKhitron (talk) 18:43, 15 November 2018 (UTC)[reply]
If I understand right, you're envisioning a way to allow each community to change what ArticlePlaceholder displays according to community decision. I am not yet sure how much work that is, but it sounds like something we can definitely explore. But working on a feature that adds per-wiki infoboxes from wikidata asynchronously on edit has challenges and architectural considerations that are simply too big for the wishlist. If you wish, we can take a look at what ArticlePlaceholder is missing -- which you seem to say does almost everything, except some small things? -- and tackle those so it is actually useful. It will make a lot more sense to make an already existing solution useful than discarding it in favor of a completely different one that requires technical architectural changes. MSchottlender-WMF (talk) 18:49, 15 November 2018 (UTC)[reply]
Yes, MSchottlender-WMF, something like that. Of course, it's a lot of work to change the existing extension. All I suggested is a two column SQL table in each wiki - existing Wikidata item and some page title. #property will use it as it was the page's item. That's all. It will take an hour to implement. Not keeping infobox type or wikicode, not creating or changing some special page, or something else. For me, it's better than ArticlePlaceholder at the first place, but it's just me. And if it does not work, it's even better. IKhitron (talk) 21:53, 15 November 2018 (UTC)[reply]
It's a lot more work to change the Database Schema in MediaWiki than it is to fix up the extension. Changing the mediawiki schema and coming up with a way to retain extra data per nonexisting page is huge architectural work that is way outside our scope. Changing the existing extension to make it work better so that it will answer at least most of your needs and be useful for you, is doable. If you want to go that route, please change the wish to request auditing, fixing urgent bugs and helping deploy the ArticlePlaceholder extension. If you do that, I will move the wish back to the wishlist. Otherwise, as it is written, and as with the expectations, it's not possible for us to achieve as part of the wishlist. Just beware that the clock is ticking on this. MSchottlender-WMF (talk) 23:32, 15 November 2018 (UTC)[reply]
I see, MSchottlender-WMF. Maybe next year. I give up. But you say it will take more time than extension, when extension takes years to fix even before adding new features. IKhitron (talk) 13:30, 16 November 2018 (UTC)[reply]
The ArticlePlaceholder is built in a way that makes it possible for each local community to adapt the layout and what is shown to their needs. So that already works. What's missing is making it scale for larger wikis. --Lydia Pintscher (WMDE) (talk) 08:27, 19 November 2018 (UTC)[reply]
I see, Lydia Pintscher. So, is hewiki small enough? Thank you. IKhitron (talk) 20:25, 24 November 2018 (UTC)[reply]
I asked the developers but don't have a reply so far. Will let you know. --Lydia Pintscher (WMDE) (talk) 18:45, 27 November 2018 (UTC)[reply]
Ok it looks like we can go ahead with hewiki from the technical side. @IKhitron: Do you want to go ahead and get an ok from your community and then file a ticket on phabricator? --Lydia Pintscher (WMDE) (talk) 20:21, 5 December 2018 (UTC)[reply]
I see, Lydia Pintscher. Thank you. Actually, I already w:he:wp:מזנון/ארכיון 378#כמעט קצרמר - האם זה טובsuggested it to the hewiki community, and it was about 40% of support (we need 51%). The problems can be fixed mostly by localization of result. So, could you tell me, please, where can I find the manual? So I could find there answers to a lot of questions. For example: How does it work? Who and when can create a new placeholder? How can I localize it? What will happen with red links? Will there a be a CSS class for links to placeholders. Is there a special page with a list for all existing placeholders. And much more. Thank you. IKhitron (talk) 13:21, 6 December 2018 (UTC)[reply]
@IKhitron: Generally information about the ArticlePlaceholder can be found on its MediaWiki extension page.
So basically we have a special page which uses Lua to render data taken from any Wikidata item (unless the Wikidata item is already linked to an article, in that case the ArticlePlaceholder will redirect to that article instead). Currently the ArticlePlaceholder can be integrated in the search page, but it has no effects on redlinks in articles (there are plans to implement this, but that's in a very early planning stage right now). We currently don't have a special page listing all available placeholders… but in general all Wikidata items (unless an article exists) can be rendered as placeholders. If you have any further questions, I'm always happy to help. Cheers, Hoo man (talk) 10:32, 7 December 2018 (UTC)[reply]
I see, Hoo man. Thank you very much for the explanation. So, we can't use it in next couple of years. A pity, Wargo and MSchottlender-WMF, that my proposal was archived. It would win for sure, just because it is very simple, needs very little work, and resolves the problems that Placeholder can't. See you next year. I'll propose it again, with detailed demonstration why Placeholder does not fit. Thank you.IKhitron (talk) 12:25, 7 December 2018 (UTC)[reply]

Easy to use external data collector

 N Outside the scope of Community Tech

  • Problem: It is often painfull to gater data from external sources by hand while it could be automatized.
  • Who would benefit: This idea has the potential to quickly enhance wikidata completion.
  • Proposed solution: The idea is to ease the creation of tools that can automaticly gather data from similar pages.

    A wikidata contributor open the tool generator and type a URL such as https://www.iso.org/standard/45481.html . He clicks on different parts of the page such as the title, the baseline, the edition number, the publication date... Each time he click on a field the system ask him what wikidata field of property should be linked to the content. When finished, the tool show him what the item would look like. By validating it, it creates a proposal page on Wikidata with the generated code of the tool's module that can be reviewed by the community. After review, an admin can create the tool. Then the tool is launched on a specific URL typology : https://www.iso.org/standard/i.html with i from 1 to 99999 to automaticly gather all data from the ISO site, compare it with existing items and create/complete the relevant items.

  • More comments: The phase of clicking on the different fields of the page is the easy part. Important parts that have to leaved to experienced users are the code verification and the algorithm to detect already existing items.
  • Phabricator tickets:
  • Proposer: Thibdx (talk) 22:18, 5 November 2018 (UTC)[reply]

Discussion

  • This is really similar to how you make Citoid work with specific pages, except it requires more programming skill. Maybe there's a technical wish that direction that makes sense. --Izno (talk) 02:50, 6 November 2018 (UTC)[reply]
  • Hi @Thibdx:. Creating a tool to automatically scrape data-related pages is quite a feat; it requires a lot of work to make the tool properly adjustable so the user is able to use it in a useful manner in pages that probably have more differences than we realize. A "scraping" tool is always a challenge, and one that needs to be flexible enough to answer the need of this task is a huge task. As such, this is out of scope for the Community Tech team to do as part of the wishlist process. Thank you for your participation, MSchottlender-WMF (talk) 18:23, 15 November 2018 (UTC)[reply]

Add a two-column view for editor and preview together

 N Outside the scope of Community Tech

  • 問題: English: For newcomers who have just joined Wikipedia or other Wikimedia projects, they have nothing to do with visual editing and original code editing. However, neither of these is an ideal way to edit. However, visual editing is not conducive to mastering powerful wikitext code; and source code editing is complicated. In order to fix or find errors in your own code, newcomers often need to click the "view preview" button numerous times to fix the problem in the code. It is a painful experience. Having a two-column view with the editor and the preview window would make it easier for newcomers

Who is good for: I believe that the two-column editor will be more conducive to newcomers to learn and edit with the MediaWiki system. This will allow novices to more intuitively understand how to use wiki text, eliminating the pain of previewing again and again. Undoubtedly, this editing method will also bring benefits to experienced editors. Although senior editors can master wikitext, if content such as tables is more intuitive to edit in visual mode, they will also check their own previews. Edit, eliminating the hassle of previewing text and switching back and forth between visual-source code editing.

Original: 对于刚刚加入维基百科或是其他维基媒体计划的新手来说，他们无外乎有可视化编辑和原代码编辑两种编辑方式，然而这两种都不是理想的编辑方式。但是可视化编辑不利于掌握强大的wikitext代码；而源代码编辑又复杂，为了修复或者找出自己代码中的错误，新手往往需要点击无数次的“查看预览”按钮，才能修复代码中的问题，这是一个痛苦的体验。
  • 有益於誰: 我相信双栏编辑器将更有利于刚刚接触MediaWiki系统的新手学习和编辑。这样可以使新手更直观的了解维基文本的使用方法，免去一次次预览的痛苦。毫无疑问的是，这个编辑方法也会给熟练编辑的老手带来好处，尽管资深编辑者能够掌握wikitext，但如表格之类的内容在可视化模式编辑更直观，他们也会通过预览检查自己的编辑，免去预览文本和在可视化-源代码编辑之间来回切换的麻烦。
  • 提案的解決方案: 设置一个双栏编辑器，一侧为源代码编辑，另一侧为可视化编辑。分隔栏应该易于设置其位置和方向，如用户可以自己设置是上下分栏或左右分栏。一旦一栏作出更改，另一栏应立即作出更改。当光标置于源代码栏的一行代码上，这个代码对应的可视化编辑内的控件应高亮；当在可视化编辑栏选中一个控件时，源代码栏中的相应代码也应高亮。
  • 更多評論: 如果两栏编辑存在技术上的难度无法实现，那么建议开发可视化编辑即时查看代码和源代码编辑即时预览的功能。在下英文不好，恕以母语发布此愿望单。感谢翻译者的翻译工作。
  • Phabricator請求:
  • 提案者: —Ngguls(UTC) 08:17, 4 November 2018 (UTC)[reply]

討論

Izno How I interpreted this is a two-column view for editor and preview (with or without VE and auto-preview). Going to Preview mode and going back is cumbersome. I'm going to rename this proposal to that effect. Ngguls I hope that's okay. Thank you. -- NKohli (WMF) (talk) 22:26, 14 November 2018 (UTC)[reply]

2-column view for editor and preview (includes previewing the source code while doing VE edit) is described as a fallback wish if the original wish cannot be achieved. Given the original idea is to help editors change from using VE to perform edits into using source editor to perform edits, it should be able to allow editors to perform a single edit using the two different editors without switching. C933103 (talk) 06:05, 15 November 2018 (UTC)[reply]
Hi @Ngguls:; creating a live preview is actually a very very complicated task. VisualEditor has been working on providing a live preview by presentation -- that is, the ability to edit your live preview -- and they are continuously improving this experience and adding more and more of the advanced features. I understand the need to go to the source editor, but creating a live preview from the wikitext source editor -- while being scalable so that many users can use it at once without creating untenable loads on our servers -- is a task that is simply too big for the team in the context of the wishlist. Thank you for your participation, MSchottlender-WMF (talk) 18:37, 15 November 2018 (UTC)[reply]

Integrated "incategory" functionality

 N Because functionality already exists

  • Problem: The "incategory" search filter gives results for pages that are included in that category. This feature is very useful but little known. I think that it should be integrated to the graphic interface of the search page, to make it easier to find and use.
  • Proposed solution: The search page should have a "Category filters" box below the namespaces box, with options to add and remove categories to the filter.
Also, each category in the filter list should have an option "include subcategories".
For example, this search:
would return a list of Canadian men's basketball players born in the 1980s (who are in the included subcategories of "1980s births"), but not wheelchair basketball players (who are in an excluded subcategory of "Canadian men's basketball players").
  • More comments:
 
Advanced Search beta showing Category search feature.

Discussion

I like the idea greatly and I would like it to also allow to sort by the date the article was added to the category. Gryllida 23:00, 30 October 2018 (UTC)[reply]

  • This is already supported by mw:Extension:AdvancedSearch which is currently available as a beta feature - anything else remains to be done here? MaxSem (WMF) (talk) 00:22, 31 October 2018 (UTC)[reply]
    • MaxSem (WMF) is right; the Advanced Search beta already has a Category search feature (it's a little bit hidden, under "Advanced parameters"). I believe this beta is deployed on all wikis. See the screenshot at right; NaBUru38 does that meet your needs? Do you want to refine this request or can we retire it?
Example search query making use of the deepcat search option. —TheDJ (talk • contribs) 04:38, 31 October 2018 (UTC)[reply]

That's great! So when will this AdvancedSearch extension graduate from beta? --NaBUru38 (talk) 18:58, 6 November 2018 (UTC)[reply]

@NaBUru38: According to phab:T207640, it's about to become default on the first wikis in november/december. The rest will slowly follow. —TheDJ (talk • contribs) 08:44, 7 November 2018 (UTC)[reply]

Hello, I've been testing the "deepcat" functionality on Wikimedia Commons, and it often fails (see 1, 2, 3). This feature needs improvement. --NaBUru38 (talk) 19:04, 7 November 2018 (UTC)[reply]

Add option to set the mobile skin and desktop skin

  • Problem: The current default mobile skin which is forced onto all users is not extremely featured for the editor community(understatement). With the advent of responsive skins like Timeless and Monobook (the mobile version), it seems unfair that the mobile editor community will be stranded with a skin that was primarily meant for readers.
  • Who would benefit: All users who edit Wikipedia on mobile interface
  • Proposed solution: Allow users to set separate mobile and desktop skins. Thus, I could be able to select monobook's mobile version/Timeless for mobile and Vector/Monobook/Modern on desktop.
  • More comments: This is an alternative proposal to Replace the mobile frontend with the timeless skin which advocates a complete change over to Timeless. I personally prefer if the choice of the skin was left to the editor's own liking. The Wikimedia Foundation will always be free to serve up the reader's skin (MiniveraNeue) to most anon users.

Discussion

Hi FR30799386: we've got a product team working on this right now; check out the Advanced mobile contributions project. They're bringing lots of editor controls to the mobile site -- here's a current mock-up:

 

So I'm going to archive this proposal, because the work is already in progress. Thanks for participating in the survey! -- DannyH (WMF) (talk) 19:00, 15 November 2018 (UTC)[reply]

DannyH (WMF), I am already aware of the current work being done to improve the mobile skin and I support it. However, this proposal is not about improving the mobile skin ! It is about adding the ability for editors to switch skins while the mobile Frontend is deployed. Among other things, it will add the ability to use the citoid extension on the mobile interface, something that the current MiniveraNeue work does not have on its agenda. I hope I was able to clear your misconceptions. If you have any other questions you are free to ask them to me here. Regards.FR30799386 (talk) 10:26, 16 November 2018 (UTC)[reply]
" Among other things, it will add the ability to use the citoid extension on the mobile interface, something that the current MiniveraNeue work does not have on its agenda." - Sadly I'm not sure this is true. The issue with many things on mobile is not related to the skin MinervaNeue, but related to the JavaScript used on these pages. I'd recommend you have a play with the Vector mobile skin by appending useskin=vector to the end of mobile URIs (example) to see what I mean. Personally, this is why I would have supported this preference (even if it was a hidden one via the API) as it will help share knowledge of this problem (and help find solutions!) as right now there's a lot of misinformation about how our mobile site is configured/works and how that's separate from skin. Jdlrobson (talk) 16:07, 29 November 2018 (UTC)[reply]

Edit Wikidata from another project

 N Declined because another team is working on this

  • Problem: When data from Wikidata is used in infoboxes on other projects, it might be confusing for both long time editors to that project and newcomers on how this data could be edited. Adding a link to Wikidata is not optimal, because suddenly you end up being in another project which looks very different from the one you started in and editing behaves totally different.
  • Who would benefit: Everyone who is not very well versed in Wikidata already. Wikidata would also benefit since more people would contribute and things will be fixed quicker. I believe this will also enhance the adaptation of Wikidata since one of the common complaints is that some users don't want to have to change projects to edit content visible in the project they are active on.
  • Proposed solution: Create functionality that makes it possible to edit a Wikidata statement directly from the infobox, possibly in a tiny popup, so that the editor does not have to leave the project that is using data from Wikidata. This should preferably be done in such a way that it is not exclusive to one wiki, but available on request for other wikis or maybe even portable by users themselves.
  • More comments:
  • Phabricator tickets: T136599
  • Proposer: Ainali (talk) 18:42, 29 October 2018 (UTC)[reply]

Discussion

 
suggested milestones, risks etc
    • Thanks Putnik for the ping. I just want to mention there is already a nice prototype how it should look like in d:Wikidata:Client_editing_prototype (by Incabell), and this was also discussed in WMTC18 (phab:T206085#4696219, and thanks for User:DTankersley_(WMF) who took image attached :-) )
      I have already coded the most basic implementation for it in phab:T199892 so it will work in TemplateWizard (this is a new template editor for wikitext, not VisualEditor). There are limitations, but I believe we can evolve it step by step and having a first working prototype is very important to motivate communities to start document Wikidata templates with templatedata. The limitations in my implementations are:
      • (It doesn't work in VE - I think who should first get feedback from advanced users/community before pushing it to VE
      • Doesn't directly let you edit Wikidata - It just shows the data from Wikidata and link to Wikidata for edit (this should later replaced with a more powerful/complex editing within the client)
      • The TempldateData mapping has simple assumptions (access to mainsnaks/not to qualifiers, to main entity of the article etc)
      eranroz (talk) 00:18, 30 October 2018 (UTC)[reply]
  • ruWP has a pretty good tool for this that could be worth incorporating into a solution here. —Beleg Tâl (talk) 13:14, 30 October 2018 (UTC)[reply]
  • Hi there! I don't know if it's the right place to mention that but when data from Wikidata is used in infoboxes, it may lead to multiple identical references (See ISS (entreprise) on frwiki). If there is currently a solution to replace them by just one, I didn't find it... Anyway, edits on (wiki)data used in infoboxes should be more convenient. Clumsy and stupid (talk) 06:55, 31 October 2018 (UTC)[reply]
  • Moin Moin, Drag'n'drop is a gadget in Wikidata, it will open a new window and you can just drag data from Wikipedia. Then you would need en:Module:EditAtWikidata and a FrameWork editing inline directly in the Infobox, saved to Wikipedia and Wikidata, too. Regards --Crazy1880 (talk) 21:00, 2 November 2018 (UTC)[reply]
  • This is dangerous as some users won't understand they are editing something across language versions. Unless the software prevents it somehow it might lead to a lot of text in foreign languages appearing in infoboxes. It also removes an "are you sure?" step. Most things in Wikidata are supposed to be largely time-invariant. If they need frequent changes something went wrong before. --mfb (talk) 03:31, 4 November 2018 (UTC)[reply]
  • Un seul constat doit prévaloir pour toute amélioration = Une information présente dans Wikipédia doit pouvoir être modifiée dans Wikipédia. Tout le reste n'est que verbiage. Matpib (talk) 09:39, 4 November 2018 (UTC)[reply]
  • Hi Ainali. Thanks for your proposal, which I know a lot of people are interested in. The CommTech team decided to withdraw this wish from voting based on two things: firstly, it's a big job that is not in our area of expertise, but on the more positive side Wikimedia Deutschland (WMDE) is committed to working on this in 2019. —JMatazzoni (WMF) (talk) 19:02, 15 November 2018 (UTC)[reply]

Identify requirements for testing "edit" in square brackets as an alternative to the pencil icon on mobile

 N Outside the scope of Community Tech

  • Problem: Institutional pressures make it difficult to measure the effect of replacing icons with text
  • Who would benefit: Potential benefit to editor uptake on mobile
  • Proposed solution: Phrasing TBD
  • More comments: hold comments until Friday please
  • Phabricator tickets: TBD
  • Proposer: James Salsman (talk) 03:16, 4 November 2018 (UTC)[reply]

Discussion

Please see https://meta.wikimedia.org/wiki/User_talk:Heatherawalls#Design-blocked_technical_community_wish James Salsman (talk) 03:16, 4 November 2018 (UTC)[reply]

Hi James Salsman: As I said last year, this is a design decision that CommTech can't work on. You should check out the Advanced mobile contributions project -- post on the talk page there, and someone from that team can talk to you about it. Sorry for the disappointment on the survey. -- DannyH (WMF) (talk) 19:17, 15 November 2018 (UTC)[reply]

Low-bandwidth editing app

  • Problem: Many people now have access to smartphones and data storage, but not affordable high-bandwidth connections. This is common in the third world. I have also experienced it personally as my work has sometimes taken me to remote areas for periods of a few months. Under these circumstances, I naturally used offline copies of Wikimedia content. Even when I am somewhere with a cheap high-bandwidth connection, I now often browse my offline copies, especially for political content (I don't want tracking of my political interests to be used to target election ads to me) and dictionaries.

    The problem is that I then don't edit the wikis. If I see some error, I rarely bother to re-load the page through another interface and fix it, even if I have a cheap high-bandwidth connection right there waiting. If I have an expensive connection (for example, connections via satellite or HF radiophone), I don't even consider editing. If I have no connection, I don't edit, and I rarely remember to go back and fix content when I next have a connection.

  • Who would benefit: Any editor or would-be editor with a low-bandwidth or expensive connection, or using offline wiki content for other reasons. A lot of people in developing countries who are underrepresented among editors.
  • Proposed solution: A mobile/desktop app allowing me to load wiki content from local storage, but optionally (with a single click) sync a single page with the up-to-date version online. The synced page should then be editable. Ideally, the app would save edits made when there is no connection so that they can be uploaded when the editor next has a connection. Wikipedia edits which use the standard markup are plain text, and thus very low-bandwidth. The app could thus be very cheap to use over even an expensive connection.

    Obviously the local storage should be updatable with a sync (download of differences) rather than a full re-download, too.

  • More comments: Sorry to submit this at the last moment after withdrawing my former third proposal, but I just thought of it. May overlap with Internet-in-a-Box; Doc James, could you comment?
  • Phabricator tickets:
  • Proposer: HLHJ (talk) 17:27, 10 November 2018 (UTC)[reply]

Discussion

Thank you, Doc James. I'm a bit worried that it might be difficult to implement, too, but there's some really good copyleft syncing software out there already... comments from devs on this would be welcome. I think one would deal with edit conflicts in exactly the same way one does now. If you left it too long to upload your changes, you'd be more likely to have a mess you needed to sort out manually. But I've edited plenty of pages which haven't changed for years. HLHJ (talk) 00:24, 11 November 2018 (UTC)[reply]
  • For those not familiar with the idea of syncing, it goes like this (character counts are made-up):
Note that human attention is only required for the stuff after the network comes back if there is an edit conflict. Obviously this is not done in natural human-readable language without data compression, so it's really even more concise. Even in this form, though, it's a lot shorter than sending even one entire copy of both articles, so you transmit less data and pay less to your communications network. HLHJ (talk) 16:18, 11 November 2018 (UTC)[reply]
It does. Thank you very much for the reference, Bluerasberry, I had no idea. "We are working on the next version with the technical support of Kiwix... The most exciting element is that there are discussions ongoing to create a synchronization system... Finalized articles have to be retrieved manually by local facilitators to be imported on Wikipedia or Vikidia, which is obviously not very practical."[11] (quote by Anthere, from last May; Islahaddow is the second co-creator). If I've understood right, it looks as though WikiFundi uses content stored on a local intranet, and (currently manually) syncs the intranet to the WM servers. Target users are schools and similar organizations. So this suggestion is almost exactly a one-person version of WikiFundi. The hierarchical-wiki version makes sense, though, as it would save on hardware costs (although it would sometimes make edit conflicts from more awkward). There are really two problems here; low-bandwidth connectivity (on price or capacity grounds) and intermittent connectivity. HLHJ (talk) 23:58, 11 November 2018 (UTC)[reply]

Hello. Indeed, you have a bit reinvented WikiFundi :) Looks like we need to communicate more about it ;)

So, key points

  • First version was launched in Jan 2017. We JUST finalized V2 (last successful testing was Friday, so really, just finished).
  • The two places where you can find the most info about it is m:WikiFundi and the website http://www.wikifundi.org. I warranty those are up to date because we actually updated those last Friday...
  • Dev was done by Emmanuel for the V1 and with Kiwix for V2. We do not do sync but it would be absolutely LOVELY to have a system to do sync... So any technical solution you can come up with... I am interested.
  • We plan to communicate about V2... this week or next week. Newsletter to our contacts, the offline mailing list for the Offline Projects and Wikimedians for offline wikis. WMF blog probably. On Twitter and Facebook. Wikimedia-l as well I guess. If you have other interesting venues, please tell me. I would recommend you join the offline mailing list.
  • We actually use that WikiFundi stuff... for example, I am currently working on this : https://fr.vikidia.org/wiki/Projet:WikiChallenge_Ecoles_d%27Afrique. It already operated last year and will operate in 2019 again.
  • There is a bi-monthly meet up on about async wikis, which is... exactly what you seem to be interested in ;) Next meeting in tomorrow. Please get in touch with David Strine (dstrine BIP wikimedia.org)
  • I also invite you (strong recommandation) to check out this project grant request Grants:Project/Rapid/MarkAHershberger/MABS: Multilateral, Asynchronous, Bidirectional Synchronisation (of wikis) and get in touch with Mark ?

Anthere (talk) 11:11, 12 November 2018 (UTC). Motif User:Islahaddow[reply]

Thank you, Anthere. I think I'm a bit late on the monthly meet-up this month. It looks as if MarkAHershberger's grant application for... V3? 4?... is fairly directly what is suggested here. I'd encourage anyone reading this to go endorse the grant proposal, as I have done (it doesn't count towards your votes!). Can this Wishlist proposal be adapted to be useful to this project? I do not know enough about these political structures to know. HLHJ (talk) 03:19, 14 November 2018 (UTC)[reply]
Actually... I was one week ahead :) This is next Tuesday... Let me point the offline people to your wishlist. Anthere (talk)
This is awesome. I'm glad to see you taking an interest in MABS. With this sort of encouragement, I am more motivated to see if we can produce something that others will be able to use. --☠MarkAHershberger☢(talk)☣ 15:41, 15 November 2018 (UTC)[reply]

Hi HLHJ and all: It sounds like you're making friends and connecting to the related work that people are doing. I'm going to take this proposal off the Wishlist Survey, because I think you're already talking with the folks who'll be able to work on these ideas. Thanks for participating in the survey! -- DannyH (WMF) (talk) 19:20, 15 November 2018 (UTC)[reply]

MarkAHershberger, can this proposal be converted into anything of use to your work? Or would it be best for your work to discontinue the proposal? HLHJ (talk) 02:40, 16 November 2018 (UTC)[reply]

Wiktionary as pilot app

 N Outside the scope of Community Tech

  • Problem: There is no official Wiktionary app. There was an app years ago. Millions of people installed it. The Wikimedia Foundation removed it from app stores in 2018 because it had not been updated for years and was broken in various ways.
  • Who would benefit: In the most developed languages, like English, German, etc, there are many online dictionaries. For many languages with smaller communities, the Wiktionaries are much more popular because there are no online alternatives. The only option was Wiktionary, and those communities need their Wiktionary app restored!
  • Proposed solution: The Wikimedia Foundation should provide at least one Wiktionary app to continue to collect user data and have a pilot project. The Tamil language community (South India) especially wants this project and to have their app restored.
  • More comments: There is a documentation problem associated with Wiktionary. Now that the Wikimedia Foundation has removed the apps from the off-wiki app stores, there are no remaining public records about who was using the apps. There is not currently a practice of making on-wiki documentation for off-wiki apps. There is not any obvious on-wiki place for people to discuss apps.
  • Phabricator tickets:
  • Proposer: from Balajijagadesh drafted with that user's ideas by Blue Rasberry (talk) 18:52, 10 November 2018 (UTC)[reply]

Discussion

  • @Balajijagadesh: I talked with you about this project on your talk page. I tried to write this up for you so we could get it in by the deadline tomorrow. @Ganeshk: I think you know something about the issue of the Tamil Wiktionary. If either of you can develop this idea then please post and edit. Blue Rasberry (talk) 18:52, 10 November 2018 (UTC)[reply]
  • The demand for wiktionary app in android/iOS is obvious from the fact that there are many other apps available in the playstores by the third party. The third party apps use the wiktionary content. But most of them are loaded with advertisements and possibly other issues. In Indic languages too the (especially Tamil language) there are a dozen third party apps use wiktionary data loaded with other problematic ad/malware etc. When the wiktionary app from the wikimedia foundation was live it had millions of downloaded and more than 4000 feedback. Though the app was old it has many recent downloads. When discussed with other people the information received is as follows. The dictionary content in the wiktionary project is being integrated into wikidata with entirely new structure. so when it is integrated then we have better data base. so wiktionary app wouldnt be a necessary. But there are problems I find in this argument. The integration of dictionary content into wikidata is still in the nascent stages. Even with conservative estimates it would take around 3 years for a reasonable integration. Secondly even after complete integration of wikidata into wiktionary there no plans as of now (as of my knowledge) to stop/discontinue the wiktionary project. So I could not comprehend why do we not have a wiktionary app for our users. Atleast for another 3 years why do we have to deny our users a wiktionary app. Those who use the app may turn into contributor. With our vision being 'Data as a service' why dont we service people with a wiktionary app? Already we have two sucessful apps from the wikimedia foundation in the playstore. one for wikipedia and one for commons. so already we have an app to work on. So I guess it would be easy to build a wiktionary app from the existing structure of apps. Even costwise too ( I havenot made a analysis) I hope it would be cheaper for the foundation to make a wiktionary app. -- Balajijagadesh (talk) 03:23, 11 November 2018 (UTC)[reply]
  • i agree with User:Balajijagadesh and also many language are diappearing, if we have a app for sound recorder (I think no app is available for open format output .ogg/.oga) I already discussed with Tshrinivasan regarding the features of Wiktionary mobile app and i hope he will join in this dicussion--Info-farmer (talk) 04:03, 11 November 2018 (UTC)[reply]
  • Based on my experience by talking with people at Wikimania '18 I feel that there's a lot of interest for the reviving the Wiktionary app. User:Balajijagadesh tried reaching out to several people at the foundation to find the maintainer of the original app. Github has a WiktionaryMobile repo hosted but it seems to be a PhoneGap based application instead of native one. As a first step it would be great to revive the PhoneGap application and later if there are enough volunteers, a native app can be built. --Maskaravivek (talk) 15:52, 11 November 2018 (UTC)[reply]
  • It is better to have the app in playstore, so that tamil community can use it. It will be good if someone share why the Wiktionary android app is removed from store, issues with tamil Wiktionary, guides to solve them. So that we, as tamil community, will work on fixing the issues with tamil Wiktionary. -Tshrinivasan (talk) 05:18, 11 November 2018 (UTC)[reply]
  • Thanks @Tshrinivasan: for posting your comments. The wiktionary app can be made as a common app for all languages just like wikipedia app. So any language users can use it by selecting their appropriate language. The translation of the app interface can be made at translatewiki.net. So some functionalities like recording the the pronunciation of a particular word, uploading to commons and linking back to the word can be all done with the app itself as User:Info-farmer suggested. -- Balajijagadesh (talk) 07:51, 11 November 2018 (UTC)[reply]
  • As someone [very slightly] involved in the original Wiktionary app creation: I do not believe anyone on that team will have any interest in doing anything with WMF. The Foundation's devs burnt that bridge spectacularly at the Wikimania. (NB: youtube video of 1.5 hour session for 3 presentations; the announcement of the sister project app begins at 1:19:04 and is allowed about 3 minutes of time.) - Amgine/meta wikt wnews 16:16, 11 November 2018 (UTC)[reply]
  • @CGauthier (WMF), JMinor (WMF), and CKoerner (WMF): Hey WMF'ers. I am pinging you here because you have some connection to the development of the Wiktionary Android App. Do you have any guidance or thoughts to narrow the scope of this wishlist proposal to make it stronger or make some advancement on getting mobile Wikitionary access to underserved languages which need the service? It is hard for me to guess if the first step is full and complete development of the Android app, or if there is some smaller step or development which could be more achieveable. Blue Rasberry (talk) 02:55, 13 November 2018 (UTC)[reply]

@Balajijagadesh: Regretfully, I'm going to have to decline this proposal. Building a Wiktionary app would be too large a project for the Community Tech team (especially since we don't have any app developers). I have, however, contacted CGauthier (WMF), the product manager for Android apps, and let her know about the renewed community interest in the Wiktionary app. I have asked her to follow up at https://phabricator.wikimedia.org/T205727. Ryan Kaldari (WMF) (talk) 19:23, 15 November 2018 (UTC)[reply]

Replace the mobile frontend with the timeless skin

 N Outside the scope of Community Tech

  • Problem: mobile frontend at [12] is hard to use lacks features etc. Vast majority of users are not aware of the alternative, the timeless skin
  • Who would benefit: mobile users
  • Proposed solution: query wikis asking whether they would be willing to change ".m." URLs to use the timeless skin by default
  • More comments: further development of the timeless skin and making other skins mobile friendly would be nice
  • Phabricator tickets:

Discussion

@Gryllida: Could you please elaborate what "hard to use lacks features etc." means? --AKlapper (WMF) (talk) 14:52, 31 October 2018 (UTC)[reply]

AKlapper (WMF) The Mobile frontend as it is currently being implemented is actually hard to use and un-intuitive for the editor community. Take for example, the difference in the text editors-the mobile one does not even support the basic buttons for adding bold text, references, links etc something which Timeless already offers. Any work done on the mobile editor is lost if you swipe to far down on an android mobile. The lack of a revert button, and the Page Issues dialog make it absolutely impossible to perform basic maintenance tasks which could have been done with two clicks on the Timeless skin. Additionally, some of the equally basic gadget functionality (such as the Twinkle or HotCat) is missing from MiniveraNeue which is provided by Timeless.FR30799386 (talk) 18:29, 31 October 2018 (UTC)[reply]
Hi AKlapper (WMF) thanks for your question,
  • Missing sidebar which was carefully crafted by the sysops and consensus - disrespect for the links which they considered useful for a newcomer
  • the default edit notice is not shown - again neglects the needs and consensus by the relevant wiki members (visual editor shows it in a tiny 200px wide box, classic source editor in a timeless skin shows it full width, often the edit notice has important information)
  • gadgets missing - again there was consensus about what gadgets to enable by default,
  • no undo button for an edit that I just made,
    • history is really hard to discover,
  • bold and italic missing in source editor,
  • source editor has no syntax highlight,
  • settings limited and do not have many important things,
  • edit box does not have preview,
  • user privileges and edit count are shown at the bottom somewhere when viewing a diff but I don't want them to show and there is no opt-out,
  • project logo not shown only its name as text,
  • icons are boring greyscale hard to remember compared with colored icons or even text labels,
  • (By the way, the Special:History page is a nightmare, it is hard to find it useful, many user icons which lack meaning as they are all the same.)
  • it does not show what categories a page is in (something you vector guys see at the end and I as a user of timeless see in the sidebar at the right.
I think you may find more points in phabricator and on the talk page of the mobile frontend.
If you ask at a wiki village pump they may share more tips.
I think it would make more sense to fund the development of responsive versions of the existing skins (timeless, vector, monobook, modern), and merge any relevant bits of mobile frontend into the existing skins. This way everything just seems more useful and any potential improvements are available.
--Gryllida 00:13, 1 November 2018 (UTC)[reply]
  • Actually, is there any ways to use timeless skin instead of mobile skin as default when navigating wikipedia using mobile web browser? C933103 (talk) 18:10, 1 November 2018 (UTC)[reply]
    @C933103: As far as I'm aware it is not possible to turn off the mobile site in preferences. If you manually go to the desktop site on a mobile device then Timeless works okay. Jc86035 (talk) 19:14, 1 November 2018 (UTC)[reply]
    What happens if you visit the URL without '.m.' in it? Gryllida 19:24, 1 November 2018 (UTC)[reply]
    @Gryllida: (Are you asking me?) The preference to use the desktop site is set with a cookie. URLs without .m redirect to the mobile site on most mobile browsers until the cookie is set by manually choosing the desktop site. Jc86035 (talk) 19:42, 1 November 2018 (UTC)[reply]
    This proposal is pretty broad (I've worked on the mobile site for 6 years towards the goals of "merging relevant its of mobilefrontend into core/skins", adding "undo" and still haven't achieved them 😂), but technically, you cannot replace Mobilefrontend with Timeless. You can replace Vector with Timeless or Minerva with Timeless but not MobileFrontend with Timeless.
    MobileFrontend is what provides you a "m." domain and the ability to use different skins on that domain. Right now MobileFrontend is tightly coupled to a bunch of mobile optimisations. Both MinervaNeue (the current mobile skin) and Timeless are responsive skins and any issue that's present in Minerva would have exactly the same issues in Timeless. For example, you complained about the history page - I'd expect history page in timeless is not useful to you either; and there's a whole bunch of work to be done to fix the editing issues you bring up. Removing the MobileFrontend optimisation features for all users would be very backward from a performance perspective. Right now we are often recognised as being one of the highest performers on mobile devices because of those optimisations. Access to Wikipedia in developing countries is pretty important IMO, so such a step should not be taken lightly and would have to be hugely justified. On a more exciting note, Wikimedia is dedicating quite a large chunk of resourcing to mw:Reading/Web/Advanced mobile contributions (about a year's worth of work!). Reading between the lines and through your list it sounds like the work there would satisfy most of your wishes here. The goal here is to provide more links in the main menu and fix a bunch of special pages in mobile to be more aligned with their desktop counterparts. Wikimedia investment in features for editors has been lacking in the previous years so I personally am very excited to see this happen. I request you scrutinize that project page and help guide it, as that project is likely to get a lot more resourcing than community tech will be able to provide and so far it hasn't gathered that much feedback (and if community tell that project what it wants they'll likely get it). In particular, please provide some feedback on the prototype linked to at the top of the page! There is a longstanding bug to allow users to choose a preferred skin on mobile. Back in August, I even wrote a patch to support that . I think the only reason it isn't merged is lack of review and support on its associated Phabricator ticket. You might want to consider asking specifically for that as a wish as I'm not sure if that's currently in scope for the Advanced mobile contributions project. Jdlrobson (talk) 22:55, 1 November 2018 (UTC)[reply]
  • @Gryllida: This isn't a bad idea, but I think it will get declined by the Community Tech team due to interfering with the roadmap for the Reading Web team's mobile work (as mentioned by Jon above). My suggestion would be to reframe this proposal as "Let users set their mobile skin to Timeless" (i.e. T173527), as that would be more feasible and less likely to be declined. Kaldari (talk) 23:22, 1 November 2018 (UTC)[reply]
    I agree with @Kaldari. We would require to have the option to choose independently a desktop/laptop skin (large screens) and a mobile skin (small screens) that are both active (in the profile/preferences) depending on the type of interface at run time. If a user wants to use the same skin on a desktop/laptop and on a smartphone, then one would just select two times the same skin... Maybe we do not need to refer to desktop/laptop/mobile but only want to discriminate between large and small screens? Even for small laptops you can have a large (external) screen connected? Imagine also a Raspberry Pi 3+ connected to a large flatscreen? Give the user some freedom. Geert Van Pamel (WMBE) (talk) 14:25, 4 November 2018 (UTC)[reply]
  • From a technical standpoint, the easiest thing here would probably just be to make the distinction be between the MF version of the site and the non-MF ('desktop') and surface the MF setting for mobile skin as a user preference option as well/allow communities to set it as a site option... except even if people select Timeless instead of Minerva for that, it's MF specifically hiding a lot of features, displaying the different versions of special pages, etc, not the skin, so Timeless would have a lot of the same problems there regardless. -— Isarra ༆ 16:49, 6 November 2018 (UTC)[reply]
    @Isarra So basically you adopt my proposal to allow the user to choose 2 skins in his profile; one for normal URL (large screens) and one for .m. sites (small screens). This would perfectly work. It would give the user the freedom to work with 2 types of screens each with the right skin attached to it. Geert Van Pamel (WMBE) (talk) 09:48, 8 November 2018 (UTC)[reply]
  • Also see CSS changes. Geert Van Pamel (WMBE) (talk) 09:56, 8 November 2018 (UTC)[reply]

Hi Gryllida and all: I think what Jdlrobson recommends is the best way to handle this -- you should check out the Advanced mobile contributions project page, and talk to the folks on that team. They'd like to get more feedback on the work that they're currently doing, and I know they'll appreciate hearing from you there. I'm going to archive this proposal; thanks for participating in the Wishlist Survey. -- DannyH (WMF) (talk) 19:26, 15 November 2018 (UTC) [reply]

All projects in the same watchlist

 N Outside the scope of Community Tech

  • Problem: For editors who work on various projects, we sometimes review the watchlist of a project and only see the changes when we access that particular project.
  • Who would benefit: To all the editors of several projects, to have all the data in the same watchlist.
  • Proposed solution: Currently in Wikipedia we can enable a field to review the changes that are made in Wikidata of the articles we have in follow-up, but we can not have all the projects in one place, so it would be beneficial to have buttons to enable the other projects and other languages.
  • More comments:
  • Phabricator tickets:
  • Proposer: Vanbasten 23 (talk) 11:28, 4 November 2018 (UTC)[reply]

Discussion

@Vanbasten 23: Is this basically phab:T5525 ("Cross-wiki watchlist")? --AKlapper (WMF) (talk) 17:12, 4 November 2018 (UTC)[reply]

Thanks :DDDD --Vanbasten 23 (talk) 18:44, 4 November 2018 (UTC)[reply]
@Vanbasten 23: Hello. Thanks for submitting a proposal. This wish (Cross-wki watchlist) ranked #4 in the first ever wishlist survey we held. We worked on it for several months but did not end up finishing the project. We realized that this is a very big technical project that needs a big team to work on it. Completing this wish is outside the scope of this team. Hence, I will have to close this proposal. I'm sorry about that. However the good news is that there is another wishlist proposal to bring back the Crosswatch tool which will allow users to view all their watchlists in one place. If you have not used Crosswatch in the past - it is an external tool and not on the wiki. The tool does not work currently and the proposal is to fix it. I would encourage you to vote for that proposal instead. Thank you so much for participating. Ping me if you have any concerns or questions. -- NKohli (WMF) (talk) 19:26, 15 November 2018 (UTC)[reply]

Option to embed SVGs as SVGs

 N Outside the scope of Community Tech

  • Who would benefit:
    1. graphic designer (SVG)
    2. all Authors that like to use SVG-Files (to use them they have be rendered correctly)
  • Proposed solution: allow an option like [[File:Filename.svg|thumb|vector]] to allow embedding as SVG just for special files, for files that are whitelisted.

Discussion

We want ensure an uniform rendering, therefore it is necesarry that the SVGs are rendered by Wikimedia, but for view problematic files that might be usefull to be rendered by the users browser. For small files it would even decrease the download-size. If a file contains text it should also contain fallbackfonts for Windows/Linux/Mac.  — Johannes Kalliauer - Talk | Contributions 21:19, 29 October 2018 (UTC)[reply]

Small note that embedding an SVG is a specific technique that is different from using SVGs as images (instead of the PNG thumbnails, which you likely mean). I have added the most closely related ticket that I could remember to your proposal, T134455. This change does potentially conflict with translatable SVGs btw, as browsers use the browser instead of the HTML content language to render SVGs. Additionally, there likely has to be some limit on very complext SVGs like the one of our entire earth, which would cause significant strain on the client side. I think both problems are surmountable as part of this wishlist effort. —TheDJ (talk • contribs) 10:30, 30 October 2018 (UTC)[reply]
Displaying SVGs as svg files has been an ongoing discussion within the technical community and there are, unfortunately, several potential issues with that present us with blockers at least for the short-term. Most notably:
  • Browser support is lacking, and where it exists it is non consistent. This isn't a complete blocker to implement SVGs but it definitely makes the task a lot harder and requires architectural thinking about how and when to do fallbacks.
  • Performance considerations: While SVGs can be smaller than their PNG equivalent, they can also be massively bigger; an example is the Wikipedia logo, where the globe and logo drawings are significantly larger than the scaled-down thumbnails. Even if we solve the issue of serving "fallback" pngs, we'll need to make sure that these fallbacks take into account file sizes, which is another fairly elaborate architectural consideration.
  • Security considerations: We disable some SVG features in the server-side renderer, and we automatically detect security or privacy-sensitive features on SVG upload, but upload detection is not as strong as it should be to recognize real potential security dangers. There are certainly features that are okay to do server-side but would present a serious privacy risk if done on the client. Updating security concerns on upload would also have to then be done on all existing SVGs which is a very expensive operation, but we will have to make sure we keep our security and privacy up to date.
All of these (an incomplete list, but fairly representative) are not end-all-be-all for SVGs, but they definitely show that the request as it stands right now is very complex and requires quite a number of architectural changes to be done for us to start considering potential solutions. Some of these are in progress, and some we'll need to continue discussing and work on, including, probably, some technical RfCs, to hash out the best long-term solutions that maintain the proper performance, browser support and security/privacy considerations that we're requiring from all products.
That said, @JoKalliauer: maybe we can try and scope this down a bit? Maybe identify the biggest bugs, or hurdles, and get the wish to concentrate on solutions to these? We can probably tackle a couple of those bugs or some of the features that are requested, within the scope of what the team can do in the wishlist, without having to count on the pretty massive architectural (and security/etc) concerns that a full blown SVG-display support will require. MSchottlender-WMF (talk) 21:06, 31 October 2018 (UTC)[reply]

My recommendation is that JoKalliauer file a Phabricator task for this idea. This will provide a permanent place for us to explore the technical issues and document the justifications. At present, I don't think this proposal has been developed sufficiently to be ready for voting. -- Tim Starling (WMF) (talk) 05:34, 1 November 2018 (UTC)[reply]

An epic task for this can be found at phab:T5593. -- NKohli (WMF) (talk) 19:52, 1 November 2018 (UTC)[reply]
@TheDJ: Thanks for your answer and adding the Phabricator task  : I thought about both problems already before you mentioned them, but as you said they are approachable.
  • language-switch: Files with a language-switch should be embedded as png. I don't know any file that shows a librsvg-bug and has a language-switch. (except: File:Well_to_Wheels_(kWh).svg this had a librsvgbug and afterwards it got a language-switch.) For the rare case of a combination of a librsvg-bug and language-switch it might be usefull to offer several svgs, simmilarly as now we offer several pngs, but thats far beyong my whish.
  • Complex SVGs (SVGs above ~512KB) should not be embedded as SVGs (Always embedd SVGs above 1MB as PNG, even if the user specifies it differently)
@MSchottlender-WMF:
  • Browser support might be lacking, but is generally much better than librsvg (check for example https://github.com/RazrFalcon/resvg#svg-support ) I would say librsvg has more than 10times more bugs than Chrome or Firefox and even Internet Explorer is much better. Or what do you mean with Browser support is lacking? (f.e. common Examples)
  • Performance considerations: It should only be available for problematic SVG-files not for all. Patroller might whitelisting specific SVGs for allowing rendering SVGs on client-side (users might be able to deactivate that in Special:Preferences), like for animated SVGs (f.e. File:Morphing_SMIL.svg).
  • Security considerations: If Patroller whitelist SVGs for allowing rendering specific SVGs I don't see a big security issue. (But SVGs have a lower security-risk than PDFs, but xlink:href to external gets blocked anyway)
  • Maybe identify the biggest bugs, or hurdles: There are too many, that is not good idea[clientRendering 1]. Above I quoted 20 Bugs that would be solved with client-side-rendering. (phab:T20463, does not have any woraround, phab:T32033 needs commas but phab:T194192 needs spaces, phab:T35245 is the most common bug, phab:T35245 does occour when converting PDFs to SVGs in Inkscape; phab:T36947 read the last 4 request on w:Wikipedia:SVG help or w:de:Wikipedia:Probleme_mit_SVGs#Die_Abstände_von_Buchstaben_stimmen_nicht and you know this is a problem; phab:T43424 Wikipedia is known for this bug[13] (Since it does not apper on browsers); phab:T55899 is the second most common bug).
If not all common browser does not support a feature of svg, there is no need to support this feature! (except language-switch is not fully/uniform supported by all browsers, but librsvg also has it's problem with language-switches).
@Tim Starling (WMF): I think phab:T5593 and phab:T134455 are enough, or is something missing?
I think the proposal now developed enough, or what is missing? If you have doubts tell me them, I'm shure I'll already thought about a solution. (I do not quote all problems, which already have a solution since they are not problems any more.)
@NKohli (WMF): Thanks for adding this Phabricator task.  
 — Johannes Kalliauer - Talk | Contributions 21:56, 1 November 2018 (UTC)[reply]
No, they are not enough, I mean a task specifically for the file=svg parameter. -- Tim Starling (WMF) (talk) 22:01, 1 November 2018 (UTC)[reply]
I added a specifically task for the file=svg-parameter: phab:T208578,  — Johannes Kalliauer - Talk | Contributions 18:07, 4 November 2018 (UTC)[reply]
@JoKalliauer: I understand your proposed solutions and the frustration with the existing insufficient technological answer. However, adding the ability to display svgs as svgs will require quite a lot of architectural changes, some of which I mentioned above, and some require deeper decisions about how to handle security and performance with given images and with making sure that the upload and display technologies are synchronized in requirement and spec. It's not that we think this is a bad idea, it's that the path to make this happen looks like it's quite very much too big for the scope of a wishlist wish.
However, I do believe we can help both fixing some of the bugs and, perhaps, starting some of the required tasks to get to the ultimate goal of having this enabled on wikis -- which is why I asked that we try and trim this down, or try to find a way where this wish is more feasible, given the reality of what the team can provide. MSchottlender-WMF (talk) 02:08, 14 November 2018 (UTC)[reply]

I like this proposal a lot but mostly of different reasons than the rendering-bugs. All the benefits of vector grafics get lost if we convert them to pngs serverside. Server-side-rendering makes sense for complex graphics but not for simple graphics. Maybe you can add this as additional point to the description. Also I think that instead of [[File:Filename.svg|thumb|file=svg]] we should use [[File:Filename.svg|thumb|vector]]. It's easier and more to the point. -- MichaelSchoenitzer (talk) 23:51, 7 November 2018 (UTC)[reply]

Annotations
  1. ↑ It might be better to allow change the renderer to Inkscape(very slow, but very precisse) or to resvg(fast processing, fast developing but still almost as buggy as librsvg). See phab:T40010,mediawiki:SVG Benchmark,current SVG-Rendering-benchmark for details.

Hi JoKalliauer: As MSchottlender-WMF said above, this proposal is too big for the Community Tech team to take on. It looks like you're talking to the right people now, and there's some conversation happening on phab:T208578 and the related tickets. I'm going to archive this proposal. Thanks for participating in the survey. -- DannyH (WMF) (talk) 19:40, 15 November 2018 (UTC) [reply]

Increase font size of section headings

 N Requires community consensus

  • Problem: The font size of the section headings h2 is 1.5em which is too small with respect to the h3 and below subheadings. Section headings don’t stand out enough among the bold subheadings.
  • Who would benefit: All readers.
  • Proposed solution: The section headings (h2) should be 1.7em.
  • More comments: The page title (h1) is 1.8em.
  • Phabricator tickets:
  • Proposer: Hnvnc (talk) 00:41, 6 November 2018 (UTC)[reply]

Discussion

@Hnvnc: To me this does not sound like in scope of Community Tech but like a (technically trivial) change of a few lines in a skin file (or an edit to MediaWiki:Common.css or MediaWiki:Vector.css if a community agrees, or an edit to your personal CSS definitions if only you agree). --AKlapper (WMF) (talk) 11:29, 6 November 2018 (UTC)[reply]

AKlapper (WMF), no wish is too easy! Since we always seem to agree to wishes that are actually too hard, we need some that we can do quickly, to average things out. —Jmatazzoni (talk) 16:41, 6 November 2018 (UTC)[reply]
@AKlapper (WMF): OK, thanks. It was in my mind for a while, so it met the Wishlist banner and here it got. I thought of an admin request, while wondering why the wiki style sheet had been set up with font sizes the way they are. Thanks for looking into this. -- Hnvnc (talk) 12:19, 6 November 2018 (UTC) / Hnvnc (talk) 17:27, 6 November 2018 (UTC)[reply]
@Hnvnc: Note that Font size changes are more complicated than might be guessed, if you're not already familiar with the deep complexities caused by the differences between the (millions of?) combinations of each person's: Operating system, browser choice, browser settings, locally installed fonts, local language script, screen size, screen resolution, and existing per-user customizations. See mw:Typography refresh (and many subpages and discussion pages) for the last time a global update was attempted. I suggest just making a personal change to your global.css or proposing a change at your home-wiki after doing extensive testing via http://browsershots.org/ or similar. Here is the current master code for vector, and there are no current overrides in w:fr:MediaWiki:Vector.css (minimizing wiki-wide local overrides is good, because it often leads to hard-to-diagnose problems later). Cheers, Quiddity (WMF) (talk) 23:24, 8 November 2018 (UTC)[reply]
@Quiddity (WMF): Thanks for reminding the caveats. I’m using Firefox on Linux and have the DejaVu font family series at size 18pt as default, and I’ve tested changing settings but to no avail, so there is a strong assumption that the problem is elsewhere. Some CSS rules are redundant or contradictory, and they’re overriding each other even inside a same file, but I’m not suggesting to do a lot of clean-up, just proposing a goal and a fix.
The visual heading hierarchy is broken when headings have different font weights while font sizes keep scaling proportionally. When subheadings must be bold to stand out enough, section headings must, too, given there’s no point in making them look cool if it’s at the expense of overall readability. Just tweaking the font family as between serif for h1 and h2, and sans-serif for the rest, while slightly scaling the font size doesn’t seem enough to make section headings stand out visually over subheadings. I guess that in addition to being serif like the title, they need to be bold like the subheadings. Increasing their font size a bit might also help improve the layout.
The fix I’m suggesting is in "load_003.css":
  1. At line 1841, increase font-size from 1.5em to 1.7em.
  2. From line 1388, move font-weight:normal; to line 1396, then add a semicolon at the end of the line above. (Note that having the last declaration in a block ending with a semicolon, too, is good practice because it makes style sheets easier to maintain.)
One could also remove as redundant the font-weight:bold at line 1403 but, again, just cleaning things up is not worthwile at this point.
I’ve tested it locally and am thinking that there’s a chance that this change will encounter general agreement. But if you believe that bold section headings are widely disliked, then please consider at least increasing their size to 1.7em, that is still 0.1 em below the size of the page title. -- Hnvnc (talk) 11:49, 9 November 2018 (UTC)[reply]
@Hnvnc: Oh, that H3 issue! I'm also a Linux user, and know your pain. ;-) Yes, that is entirely dependent on which fonts someone has installed. That's phab:T65844 and phab:T73240. Any changes that are made to fix one font, will also have a very large chance of negatively affecting people who use different fonts. I recommend that you leave comments on those tasks (for the long-term solution), and also tweak your own global.css (for a short-term solution), and then I will archive this proposal (because we have 230+ proposals and that is quite overwhelming for the voters to read through!). Does that sound ok? Quiddity (WMF) (talk) 18:12, 9 November 2018 (UTC)[reply]
@Quiddity (WMF): Thank you a lot for the Phabricator ticket links. These and other linked ones show that everything has already been told so far, leaving us with one single question: Why, why hasn’t it been fixed?
Wikipedia should be interoperable, so all platform dependent display issues should be minimized. I don’t believe that this boils down to a Linux issue. We have a large choice of default fonts. I don’t like reading Wikipedia in serif, but checking the result is worth it: Font sizes scale continuously from 1.8 em for the page title (h1), to 1.5 em for the section headings (h2), to 1.2 em for the subheadings (h3). Then, h4 through h6 are just bold and still as confusing similar to each other as they were when phab:T72004.
The bug comes from h2 not being boldened. That inconsistency in heading styles exposes the layout to the risk of being messed up by a bunch of somewhat trivial font issues.
We can’t even rely on h2 standing out by being serif, given the lower headings and the body text are at the discretion of the browser’s default font. I can have serif for all of them, by simply setting the default font to "Serif". So again, h2 must be bold.
And h2 can also use being a bit bigger (than h3) than just by the regular +0.3 em step, given that section headings matter most. They could even have the size of the page title, because not being on top suffices for disambiguation. If there wasn’t the issue pointed above, that could save a -0.3 step down the hierarchy, allowing to grant the h4’s a distinctive 1.2 em size, fixing roughly 70 % of the lower heading confusion, when only the less frequent h5 and h6 headings will still be styled similarly. To make that happen, switching h2’s font weight is indispensable, because as soon as h2 is bold, standing out over h3 will suddenly be far less of an issue even with the actual +0.3 em weight delta.
Now back to the question why it hasn’t been fixed yet. Probably the goal at initial setup was to make Wikipedia look cool. That could explain why h2 isn’t boldened, and also why it hasn’t got a bigger font size. That’s OK when most or all of the stuff is cool. No doubt it really was, when Wikipedia started up. Because in that era, global warming wasn’t yet widely seen as a threat, global poisoning wasn’t in the news headings yet, civil nuclear catastrophes weren’t going to become a widespread phenomenon, and so on.
That would also explain why the heading numbers aren’t displayed in the body. And also why (without that special widget) we cannot grab the direct link right from the heading in the body. That could be added to the wishlist, but everybody needing this simply scrolls to the top/TOC. The actual state makes Wikipedia cooler to read, but more complicated to use.
If you give me another try, I’d guess that it hasn’t been fixed since a long time, and probably isn’t going to be fixed soon, because it would tap into the eye of really everybody looking up Wikipedia, and almost everybody would be going to ask: Why that now? Even if ultimately, as I believe, almost everybody would be glad it’s being fixed. The problem is, many people perhaps won’t figure out how easy the fix is, while those who do, will be left with right that question unanswered: Why now?
Best regards, -- Hnvnc (talk) 01:03, 10 November 2018 (UTC)[reply]
Therefore, making the fix happen is straightforward if WMF has the humility to expose that the article layout was suboptimal and has now been fixed. Isn’t making Wikipedia fit for the third millennium a sufficiently appealing rationale? -- Hnvnc (talk) 09:17, 10 November 2018 (UTC)[reply]
 
@Quiddity (WMF): More bluntly: The disconnect is in that it was believed that the heading hierarchy is always visually correct when inconsistent font weight is combined with regular font size stepping down gradually. In fact, the weight must be consistent all over h2..h6 for the size scaling to have the desired effect. If you have different weights between h2 and h3, then you should counterbalance by increasing the size of h2 more than by the regular step. So ultimately you lose one size step simply by not boldening h2. At the other end, h4..h6 are mashed because there is no more size step left.
So the fix making Wikipedia look regular is:
  1. Bolden h2.
  2. Increase font sizes of h2..h4 by one 0.3 em step.
  3. Slightly decrease font size of h6, still standing out while formatted as heading.
Well, to answer your question: Your suggestion doesn’t sound ok to me. So let me ask you whether this one does to you? -- Hnvnc (talk) 10:35, 10 November 2018 (UTC)[reply]
  • Somewhat redundant to what was said above, but this looks like project admins can take care of almost all of this today and we don't need developers to do anything? Can you split this out perhaps in to things that project admins can not already do and would require dev time? — xaosflux Talk 15:19, 10 November 2018 (UTC)[reply]
    • Redundant to what Jmatazzoni already answered above: If no dev time is required (the posted solution works out of the box, and the rest is only to encompass the h4..h6 issue), one advantage of including this proposal is to lessen the average dev time per project. -- Hnvnc (talk) 18:19, 10 November 2018 (UTC); edit: Hnvnc (talk) 12:19, 11 November 2018 (UTC)[reply]
    • @Xaosflux: Do you advise to directly forward this to project admins, shortcutting the wishlist process? And if so, to whom? -- Hnvnc (talk) 19:07, 10 November 2018 (UTC)[reply]
      • @Hnvnc: For example it looks like you primarily use the French Wikipedia, you could propose a change at w:fr:Discussion_MediaWiki:Common.css. — xaosflux Talk 20:25, 10 November 2018 (UTC)[reply]
        • @Xaosflux: Good point. That would help check global acceptance. But it is biased because fr-wiki isn’t forcibly willing to stand out by inconsistency with the global wiki skin. Already fr-wiki has the horizontal line formatting beyond h2, which en-wiki has not (compare fr:Touche de composition and en:Compose key). Anyway the heading formatting issue wrt font size and weight is the same in all local wikis (for a brief check see my sandbox fr:Utilisateur:Hnvnc/Brouillon).
        • @Quiddity (WMF): Meanwhile I’m wondering why WMF officials are unwilling to fix issues that are on the table since a long time *and* that are questioning initial setup. Looks like there is a consensus that the headings in Wikipedia are poor typography. Fixing them is to recognize that publicly. When we make mistakes affecting the public, and we get aware, we need to recognize our mistakes publicly while correcting. That is as true for WMF as for any business, be it profit or non-profit. You may call it a lack of humility when I’m giving lessons to other people. Still we may wonder on which side that lack is bigger. Great people recognize their mistakes. That isn’t harmful to their public image. It’s the opposite. Wikipedia heavily relies on volunteers, so forcibly there may be lots of amateurism, but above all there is giant goodwill. Now I’m appealing to your goodwill. -- Hnvnc (talk) 08:26, 11 November 2018 (UTC)[reply]
        • The issue is not as simple as it could be (while seeming rather complicated, as hinted above). When we follow h2 in "load_003.css" of en-wiki, it seems like there was an evolution. At line 237, all headings (including h1 and h2) are declared with font-weight:bold;. At line 1082, all headings again (h1..h6) are declared with font-weight:normal, but all are given the horizontal line below design border-bottom:1px solid #a2a9b1 (l.1087). Then almost immediately after, at l.1096 sq., the bottom border is removed from h3..h6, while these are boldened again. Also, the font size of the headings is tweaked by percentage, scaling from 188 % (h1) to 100 % (h6). h2 is 150 %, h3 128 %, h4 116 %, and h5 108 %. So the expectation for h4..h6 not being formatted similarly was met. Then at l.1492 comes the font stack of h1 and h2: font-family:'Linux Libertine','Georgia','Times',serif;. Then at l.1535, font sizes start being defined in em, with font-size:1.5em; for h2, and font-size:1.2em; for h3 (l.1545), while h3 and h4 are boldened (l.1548), and h4, h5, h6 have their font size equalized to 100 % (l.1551). At line 2206, h2 gets a black 2px bottom border, and at l.2216 an 18 pt font size, when h3 gets 13 pt, and h4,h5,h6, 10 pt. I don’t know why changing the last h2 font size had no effect, but we can safely let the browser sort it all out, and see what to change to get Wikipedia right. -- Hnvnc (talk) 09:43, 11 November 2018 (UTC) (Argh, yet another Sunday messed up! Should hurry to at least follow the commemoration of WW I end.)[reply]
          • @Hnvnc: Hi, thanks for the extensive details. The problems are that (A) there are subjective aspects to this (e.g. some people prefer the serif headers, some people prefer the non-bold H2 visually) that tend to override logic, and (B) there are technical variables that I think you're overlooking. See http://browsershots.org/https://en.wikipedia.org/wiki/User:Quiddity_(WMF)/sandbox for results from a simple test, showing how test page looks in various systems - Notice how the line-lengths are different based on which fonts each system has available. Specifically one, two, three (especially 'one'). (People could also grumble about not using the typeface "Georgia Bold" instead of applying bold to "Georgia", etc...) - Plus, this is even more complicated in other language's scripts (so we definitely couldn't make a sweeping change to everything, it would have to be restricted to languages using latin scripts). Plus some typefaces might render a character with less clarity when bolded. Overall, without webfonts, everything is very complicated.
          • I fully agree that it would be great to make everyone happy, and make the global site typography better in various ways; I'm just pointing out that I believe it is more complicated than you think, both socially, and technically. As I suggested above, and matching xaosflux, I recommend you try this change at your homewiki first, see if there are any complaints (and if so try to fix them), and then if/once it is a success then leave comments on the phab tasks explaining how and why you've changed things at that wiki. Hope that helps. Quiddity (WMF) (talk) 20:33, 13 November 2018 (UTC)[reply]
            • Hello @Quiddity (WMF):, thank you for the browser screenshots. I see that just boldening h2 doesn’t solve the issue for everyone. On the other hand, the problems you point with boldening headings in non-Latin scripts may back the point in unboldening all headings while making them stand out with a bottom border, as seen in one revision layer of load_003.css quoted above. Again, fr-wiki has (dotted) bottom lines from h3 downwards, so maybe we won’t mind temporarily getting away farther from the en-wiki template if the goal is to explore a new style for global implementation in case it succeeds at home. -- Hnvnc (talk) 06:51, 14 November 2018 (UTC)[reply]

Hnvnc Hello. Thanks for submitting the proposal. We discussed this project in our team meeting yesterday and we all agree that this needs to be a consensus-driven change. I agree WMF has made mistakes in the past and we admit them. What we don't want to do is make those mistakes again. Any changes to user-interface should go through a community-consensus first because we have thousands on people reading this on different devices, with different skins and accessibility tools etc. A very small fraction of those who can be impacted by this change take part in this survey. The WMF Design team should also be involved in the process so they can conduct usability tests before we make these changes to millions of our readers. Also as others mentioned above, a lot of what you ask for can be changed by project admins if there is consensus on a given project. Owing to all of these above factors, I am going to archive this proposal. However I encourage you to kindly file a Phabricator task where we can discuss this with the rest of the communit and the Design team at WMF to come up with a solution that can work for everyone. Thank you so much for your understanding. -- NKohli (WMF) (talk) 19:46, 15 November 2018 (UTC) [reply]

Language-neutral Wikidata-based Commons categories

 N Outside the scope of Community Tech

  • Problem: Wiki Commons is described as multilingual, but most of categories are in English, even in countries where English is not a spoken language. For newbies or people that are not used to work in Commons this can be a huge problem, even more if they do not know English. Could be the case to upload an image of a church and search for the category "Iglesia del Santo Niño" but find nothing, even if this church is native from the place of the user, because the church is in category "Church of the Holy Child" or alike.
  • Who would benefit: The multilingual community of Commons
  • Proposed solution: Recall the name of a category in your own language from a Wikidata item
  • More comments:
  • Phabricator tickets:
  • Proposer: Sahaquiel9102 (talk) 19:59, 30 October 2018 (UTC)[reply]

Discussion

@Jc86035:, definitively the spirit of this proposal is according to the Structured Data in Commons project. But it is already developing, and the best way to make them consider this is to vote for it. @Watchduck:, redirections do not solve the problem when searching manually in the tree of categories, because the name of the category is only viewed in one language (more of the times in English). Sahaquiel9102 (talk) 21:11, 5 November 2018 (UTC)[reply]
Non-English searching should be getting better, now that c:Template:Wikidata Infobox is starting to fetch labels and descriptions in all languages known to Wikidata and to write them into the page where the search indexer can find them. The infobox also displays a label, description, and data, localised to a user's own language, to the extent that data is available on Wikidata.
But it would still be nice to make the Category names fully multilingual. I suspect it probably wouldn't be too hard to show the Wikidata label instead of the English category name at the top of the category page (or alternatively, to show it as a subtitle) -- after all, template Wikidata infobox already shows it easily enough. But implicit in the OP's suggestion is to go further than that, I think, to make the category name completely multilingual. That involves more challenges I think, so I am interested to see what strategies people may have for how they might be overcome. For example, it is the English category name that is used as a key in all the MediaWiki databases; it is the English name that is used in the wikitext [[:Category:...]] statements at the bottom of file pages; and while those are the case, they sort-of require that the English name is given prominence on the category page itself, so people know how to indicate it. Of course, for non-English speakers it's far from intuitive to be expected to have to categorise files in English, so what do we think can be done about it.
One stepping stone might be to try to make tools like HotCat and Cat-a-lot multilingual, using the same multilingual labels from Wikidata that the infobox displays. But even this has another problem: Wikidata labels may be not disambiguated (they don't need to be, since it is the Wikidata Q-number that is the primary unique identifier for a Wikidata page, not any label). So Wikidata labels wouldn't necessary be enough to specify a unique category on Commons, even if Cat-a-lot etc could be modified to accept and interpret them. Though perhaps the Cat-a-lot drop-down menu could offer Wikidata descriptions by way of disambiguation.
That still wouldn't help international users editing in wikitext. But perhaps it would be enough for a start.  Jheald (talk) 23:38, 5 November 2018 (UTC)[reply]

Hi Sahaquiel9102 and all: This proposal falls under the [[Structured Data on Commons project, which is currently in progress. Community Tech won't be able to work on it, unfortunately. I'm going to archive this proposal, but check out that project page, and you can talk to that team. Thanks for participating in the survey. -- DannyH (WMF) (talk) 19:47, 15 November 2018 (UTC) [reply]

Make Wikidata queries embeddable in Wikipedia

 N This proposal had already been declined before

  • Problem: Currently Wikidata queries results can be embedded out of Wikimedia, using iframes, but we can't do it inside Wikimedia projects. Readers can't benefit from rich and evolving maps, timelines, graphs or other complex visualizations. Giving something to everyone except ourselves isn't the best way of working.
  • Who would benefit: Readers and Wikipedia. Also Wikidata would be better known.
  • Proposed solution: Adding the iframe solution inside Wikipedia for Wikidata queries.
  • More comments:
  • Phabricator tickets: T67626
  • Proposer: Theklan (talk) 12:05, 30 October 2018 (UTC)[reply]

Discussion

What kind of data do you want to embed, and how? Are you aware that visualizing Wikidata is already possible via graphs and maps? MaxSem (WMF) (talk) 01:45, 31 October 2018 (UTC)[reply]

This proposal is not appropriate for CommTech given its scope; the Phab ticket I've just added is tagged as Epic by the Wikidata team. --Izno (talk) 19:23, 3 November 2018 (UTC)[reply]

There is a workaround using User:ListeriaBot. --Izno (talk) 19:24, 3 November 2018 (UTC)[reply]
@Izno: No, Listeriabot only adds lists. We can't add timelines, bubble graphs or clickable maps. -Theklan (talk) 18:26, 17 November 2018 (UTC)[reply]

Archived

Unfortunately, this is essentially last year's Community Wishlist Survey 2017/Archive/Allow embedding of query results in Wikipedia and the situation hasn't significantly changed since it was declined: we're still unable to do this for performance reasons. Regardless, thanks for participating in our survey. MaxSem (WMF) (talk) 19:50, 15 November 2018 (UTC)[reply]

@MaxSem (WMF): I disagree with two things: one, you have declined it without letting people vote. Second one, you have declined it without pinging me, so I could also save another proposal I had withdrawn to prioritize this one. -Theklan (talk) 18:25, 17 November 2018 (UTC)[reply]
Theklan, we specifically decline unsuitable proposals before voting so that people don't vote on stuff that we won't work on anyway. As of not pinging - I'm sorry, we had to review a lot of proposals and we obviosly made some mistakes. However, proposers are also expected to watchlist their proposals and keep an eye on them. MaxSem (WMF) (talk) 01:11, 19 November 2018 (UTC)[reply]
MaxSem (WMF) I don't think this proposal is unsuitable. And if most people think that this MUST happen, then the WMF should allocate resources for this. Because if we can only imagine what is possible in a short time, then we can't go for the big picture. -Theklan (talk) 08:05, 19 November 2018 (UTC)[reply]

Create a tag file system in addition to conventional categories

 N Outside the scope of Community Tech

  • Who would benefit: All image reusers and anyone searching for images.
  • Proposed solution: System of user created non-hierarchical thematic tags for files, as used by almost all other image repositories, like Flickr.
  • More comments: Suggestion of a "child-friendly" tag/category/filter may be suited in another proposal?
  • Phabricator tickets: There are many related past tickets, this has been discussed for at least ten years.
    phab: T125273 2016 - "Investigate the options available for creating and adding tags for Commons pictures", still sitting in Triage, though this is about automated tags

Discussion

  Comment I think before we proceed any further, it should be explained how these tags will work. If I click on a tag "Trees" attached to an image will it take me to a page in which all images have that tag? I can foresee that creating huge unspecific pages in which it's difficult to find anything will be a nightmare. In which case, what point does it have? Rodhullandemu (talk) 14:56, 30 October 2018 (UTC)[reply]
What you are describing sounds like galleries, but there is no intention to create "pages" like galleries. I'm envisioning the way tags work on Flickr, which could piggyback on the existing was that the search engine currently works on Commons, rendering search results on the fly based on user request. For example this search shows any matches for the words "tree, bird, italy" on Commons. If these were thematic tags, the results would be shown as search engine returns but only for files which users had chosen to tag with all of "tree", "bird", "italy", because those files could illustrate all those themes, or were specifically about those themes. On Flickr you get reasonable matches with a search like this, though it seems to use fuzzy matching and most appear to just have birds in trees but no obvious "italy" tag. --Fæ (talk) 15:18, 30 October 2018 (UTC)[reply]
  • I think Rodhullandemu nailed it, in terms of framing the problem. In my opinion, this “tag” business is pointless for a repository with 50 million items and any results yielded would be illusory (incidentally, that’s why we dissiminate crowded cats). Of course, the same goes for Flickr, George’s boasting in the interview notwithstanding — the only difference is that Commons is not merely a hosting platform but means to be useful for reusers. Tuvalkin (talk) 18:14, 30 October 2018 (UTC)[reply]

Fæ and all: This proposal falls under the [[Structured Data on Commons project, which is currently in progress. Community Tech won't be able to work on it, unfortunately. I'm going to archive this proposal, but check out that project page, and you can talk to that team. Thanks for participating in the survey. -- DannyH (WMF) (talk) 19:57, 15 November 2018 (UTC) [reply]

Assist Wikimedians with crowdfunding

 N Outside the scope of Community Tech

 
Assist Wikimedians with crowdfunding, Salsman (2018) for Ward Cunningham (Newspeak House, London.)
  • Problem: Grants are difficult to administer, take time, and are often frustrating.
  • Who would benefit: Those who can show they are acting in support of the Foundation's Mission.
  • Proposed solution: Provide services to help Wikimedians set up their own fundraising outreach.
  • More comments: I will finish this Wednesday, November 14
  • Phabricator tickets: to be created if the proposal is selected
  • Proposer: James Salsman (talk) 02:46, 4 November 2018 (UTC)[reply]

Working list of technologies:

Discussion

Please feel free to SVG-ize the diagram. James Salsman (talk) 03:22, 4 November 2018 (UTC)[reply]

@James Salsman: I've looked at that diagram and don't understand what it wants to express. :( Is this about / related to Grants:Start? What exactly is "difficult to administer" and "frustrating", with regard to technical aspects? --AKlapper (WMF) (talk) 00:38, 5 November 2018 (UTC)[reply]
Thank you, it goes from fundraising goals to search strategies to search results which are transformed into recommended tweets/posts etc. Patreon, Twitter, and Reddit are included as examples but I'd prefer it platform-neutral, so please give me until at least Friday to abstract it from that working diagram. There have been recent discussions of the difficulties in grants administration and program management. I will provide those by Wednesday. James Salsman (talk) 17:59, 13 November 2018 (UTC)[reply]

Hi James Salsman: The Community Tech team can work on discrete technical proposals; this proposal is asking for structural and policy changes that can't be addressed through the Wishlist Survey. I'm going to archive this proposal; thanks for participating in the survey. -- DannyH (WMF) (talk) 20:01, 15 November 2018 (UTC) [reply]

Content Translation

  • Problem: The problem in Content Traslations is that it's basically a disaster, it would help a lot better when Google Traslate is built in. Since Google Translate has involved a lot of people, so it's better.
  • Who would benefit: The entire Wikipedia community and those who translates articles.
  • Proposed solution: Add Google Traslate to Content Traslations, since it has been around for so many years so that it is the best translator in the world, and I also believe that all translation services must be improved.
  • More comments: What is done in the new version of Content Traslations is good, but it lacks Google Translate.
  • Phabricator Reports: There are already many from all the Wikipedia communities
  • Proposer:   Ignacio >>>> ¿Hablamos? 00:01 10 Jul 2018 (UTC) 21:39, 4 November 2018 (UTC)[reply]

(Problema: El problema en Content Traslations es que básicamente es un desastre, ayudaría mucho Google Traslate que es construída por mucha gente, entonces es mejor

  • A quiénes beneficiaría: A toda la comunidad de Wikipedia que traduce artículos
  • Solución propuesta: Añadir Google Traslate a Content Traslations, pues tiene tantos años que es el mejor traductor del mundo y también creo que se debe mejorar todos los servicios de traducción
  • Más comentarios: Lo que se hace en la nueva versión de Content Traslations es bueno pero le falta eso
  • Informes de Phabricator: Ya hay muchos por parte de todas la comunidades de Wikipedia
  • Proponente: 15px Ignacio2403 >>>> ¿Hablamos? 00:01 10 jul 2018 (UTC) 21:39, 4 November 2018 (UTC) )[reply]

Discussion

Ignacio2403: Do you have any specific solution in mind? /Johan (WMF) (talk) 16:38, 5 November 2018 (UTC)[reply]

User:Johan (WMF) seré más específico porque entendí lo que me dijiste pero háblame en español por favor, i'll more specific but speak spanish please. 15px Ignacio2403 >>>> ¿Hablamos? 00:01 10 jul 2018 (UTC) 17:18, 5 November 2018 (UTC)[reply]
Ignacio2403: Sorry, I can sort of read Spanish, but I can't write it.
I think the risk of misunderstandings is smaller if you copy what I say to for example Google Translate, so that you will have both the Spanish automatic translation and the original, than if I do an automatic translation and it is more difficult for someone else to help out and correct it because they don't have the English text so they can see what went wrong. /Johan (WMF) (talk) 09:54, 6 November 2018 (UTC)[reply]
@Ignacio2403: I wonder, is this basically phab:T90208? --AKlapper (WMF) (talk) 03:48, 7 November 2018 (UTC)[reply]

  Comment @Ignacio2403: I have translated the proposal and left the original as well. —Omotecho (talk) 02:58, 13 November 2018 (UTC)[reply]

@Omotecho: Actually, are we supposed to left the original on the page after translation? I translated one of them a few days ago without doing so. C933103 (talk) 16:09, 13 November 2018 (UTC)[reply]

And actually, is it realistic to include Google Translate in ContentTranslation? My understanding is that the reason why it currently don't have Google Translate option is non-technical, as in I don't think they have a free api to use. C933103 (talk) 16:09, 13 November 2018 (UTC)[reply]

@Johan (WMF): I think you have showed a sample elsewhere to leave the original proposal when translating. User:C933103 wishes me to clarify, and I hope you could give an input.
> Actually, are we supposed to left the original on the page after translation? --Omotecho (talk) 19:50, 13 November 2018 (UTC)[reply]
I've moved it. /Johan (WMF) (talk) 20:03, 13 November 2018 (UTC)[reply]
I've left the original text, but that's more my personal preference than anything else. /Johan (WMF) (talk) 20:07, 13 November 2018 (UTC)[reply]
Thank you to come by. Yes, my personal preference as a translator is that the original might involve and benefit the proposer's local community, as people will easily find what wish their community has proposed. I might propose a wish in 2019 a flag showing the local language to English translation of a wish (; --Omotecho (talk) 20:41, 13 November 2018 (UTC)[reply]

@Ignacio2403: The Language team is already in the process of adding Google Translate to Content Translation. I expect it should be available sometime next year. Is there anything else that you would like to request specifically? If not, I'll go ahead and close this request. Ryan Kaldari (WMF) (talk) 22:23, 13 November 2018 (UTC)[reply]

  • I do not like this suggestion. I think we should focus on using copyleft software. Many free tools provided by data brokers track page users when integrated into a page, which is bad for privacy. HLHJ (talk) 07:56, 14 November 2018 (UTC)[reply]
    • @HLHJ: Any use of 3rd party APIs would be done through a proxy server to prevent them from being able to track individual users. From their point of view all requests would be coming from a single anonymous user on a WMF IP address. Ryan Kaldari (WMF) (talk) 17:54, 14 November 2018 (UTC)[reply]
      • That's good, and partially resolves one concern. However, I'd strongly prefer Community Wishlist Survey 2019/Reading#Wikipedia-Translator for articles word by word based on Wiktionary. If I can look up some of the words in a language I don't know, I can generally get the drift, and often a truer idea of what was said than a translation, especially a clumsy machine translation. However, some people prefer machine translation. If we had an easy way to metadataize the manual translations we make in the course of our editing into a copyleft parallel-texts corpus, we'd soon have a very valuable resource for training a copyleft machine translator; is this being done? The Content Translation engine complained about by the original poster is copyleft, and looks helpful, though I didn't know about it. I think making it easier for us to find and train Content Translation would be a better use of resources than making it easier for us to feed data into Google Translate. HLHJ (talk) 19:28, 14 November 2018 (UTC)[reply]

Make individual threads watchable

  • Problem: Cannot easily discover when someone has posted to an individual thread.
  • Who would benefit:
  • Proposed solution: The ability to "watch" individual talk page or forum threads, and receive notifications when people post to those threads, is required for use on forum pages with many active threads, such as the month-by-month sub-pages of https://en.wiktionary.org/wiki/Wiktionary:Tea_room, for example. The way it presently works is hopeless. If, like me, you participate in multiple threads over a period of time, there is apparently at the moment no feasible way of discovering when someone has posted a reply to a specific thread (unless the poster explicitly "pings" you, which usually does not happen), short of checking each one individually, which is clearly infeasible on a regular basis, or subscribing to the whole page and being deluged with irrelevant notifications.
  • More comments:
  • Phabricator tickets:
  • Proposer: Mihia (talk) 21:52, 4 November 2018 (UTC)[reply]

Discussion

For the records, mw:Extension:StructuredDiscussions (which is deployed on some wikis) offers this functionality. --AKlapper (WMF) (talk) 00:26, 5 November 2018 (UTC)[reply]

Hi Mihia, 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 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) 21:02, 15 November 2018 (UTC)[reply]

@DannyH (WMF): Thanks, I understand. Certainly, if I can make any useful comments on the new proposals, in respect of this issue (or indeed others), then I would be most happy to do so. Thanks again for your very clear and comprehensive reply. Mihia (talk) 21:10, 15 November 2018 (UTC)[reply]

Develop common modules throught languages for the use of Wikidata in Wikipedias

 N See the explanation below

  • Problem: We have now the possibility to enter a very big number of informations in Wikidata for one part, and second part, Wikidata has often more informations than an infobox from Wikipedia. We are also able to add sources. Wikidata is open to a very large number of languages. But if datas are often existing, they are not systematicaly displayed, because programs are old and not adapted to new ways to contribute.
  • Who would benefit: Every Wikipedia, especially small Wikipedias where the number of users is very small. But note that on the French Wikipedia, we sometimes have problems to make updates on some point, for example when the subject is very far.
  • Proposed solution: Considering Wikidata is now enough complete, I propose we develop algorithms able to display datas in a very big number of Wikipedias with the necessary adaptation to languages, as we done for infoboxes and tables in cycling, putting the priority on small Wikipedias. The goal will be to create perfect infoboxes (see fr:Grand Prix de Denain 2016 in different languages) and tables, where there is no longer problems to display informations, and infoboxes we can qualify to wealthy and updated. Documentation on how to fill Wikidata will be also one of priorities. One of the idea is to spend less time in updates, and permit at one user to do the work for everybody.
  • More comments: On cycling, we create a project that use d:Module:Cycling race. We enter datas and a supermodule permits to give datas at around 20 Wikipedias. The idea is to share data and let the others benefit from them in the idea then can make updates or corrections. Datas are also reused on Commons when we have a category thanks to Wikidata Infobox, translatable in all languages (if users add translations).

    Yesterday, I add a bourgmestre (P6) for Brugelette in Belgium. CA Wiki display this information from Wikidata, RO Wiki do it with the source. The others 25 Wikipedias are not able to take this information, some of them don't have an infobox. If the mayor/bourgmestre change, it will be very difficult to obtain naturally all updates. To stay in this domain, the actual system is also a problem to update the number of inhabitants.

  • Phabricator tickets:
  • Proposer: Jérémy-Günther-Heinz Jähnick (talk) 10:26, 4 November 2018 (UTC)[reply]

Discussion

Archived

Hey Jérémy-Günther-Heinz Jähnick - unfortunately, we won't be able to work on this proposal as the part of it that's not covered by 2015's wish Community Tech/Central repository for gadgets is not really within the scope of our team. You're askng for two things here - to have a global repository of modules and templates and to have particular set of templates available everywhere. The former had already been voted top 10 by the community, so it doesn't need another vote, although it's unclear when this functionality will be actually implemented. The latter is up to each community to decide, we can't force them to use any centralized templates. MaxSem (WMF) (talk) 21:03, 15 November 2018 (UTC)[reply]

MaxSem (WMF) : as showed on d:Module:Cycling race, when an algorithm is good it is naturally adopted by communities. Jérémy-Günther-Heinz Jähnick (talk) 12:09, 18 November 2018 (UTC)[reply]
Sorry, we're a team of programming, editing templates is just not what we're supposed to do. MaxSem (WMF) (talk) 00:42, 19 November 2018 (UTC)[reply]

Integration with distribution platforms such as Amazon, google play store for wikisource content

  • Problem: absence of wikisource as a publisher in distribution platforms such as amazon store, google books, etc. In popular distribution platforms such as amazon store, google store, etc., the proofread contents from the wikisource are uploaded by third party publishers. They publish the content for a price for the readers. Now if some wikisource volunteer wants to upload a proofread book into such distribution platforms for free it is not possible. Only big publishers are allowed to offer books for free.
  • Who would benefit: readers of wikisource content
  • Proposed solution: Register wikisource as an official publisher in the popular distribution platforms and give access to some of the users to update the content. So the proof read content could made available for free of cost to many people. The people who read these content for free if come to know about wikisource, they may turn as volunteers for the proofreading activity.
  • More comments: The foundation is in apt position to make the negotiation with the distribution platforms. It is not possible for individuals to perform this kind of discussion with them.
  • Phabricator tickets:
  • Proposer: Balajijagadesh (talk)

Discussion

Hi Balajijagadesh: This is a good idea, but it's not a task that the Community Tech team can take on. Community Tech can make software features and fixes; it's not a team that can negotiate with other companies. I'm going to archive your proposal. Thanks for participating in the survey. -- DannyH (WMF) (talk) 21:08, 15 November 2018 (UTC) [reply]

Statement Level Provenance

  • Problem: Trust is a function of data provenance in the semantic web. Wikidata is created by people and the data represents their assertions at a particular point in time. Plurality has been considered in the data model via qualifiers and ranking, but these methods silently conceal the identity value of the individual(s) whose interpretations are represented and the exact moment in time that the assertion was made. Wikidata differs from Wikipedia in that the data may exist separately from the Wiki (as RDF) and as such is divorced from the history which is an integral part of Wiki, and one could argue its most valuable feature for providing data provenance.

    Somehow the history must be recorded in the downstream serializations in order to reinforce the trust that is absent in the current data model. For example, external use cases such as IIIF (web annotation data model) annotations may require "back references" to the creator and timestamp of the last revision of a particular RDF statement.

  • Who would benefit: Consumers of Wikidata.
  • Proposed solution: Add provenance metadata from the history to RDF statements that includes Agent and Activity. This could also be done manually by allowing a user to link to his/her profile within the context of a particular interface assertion. This is particularly relevant to properties like Property:P180 whose values could be considered "original research" and definitely fall within the realm of interpretation.
  • More comments:
  • Phabricator tickets:

Discussion

  • IMO it would indeed be very nice to be able to access info about when a statement was last edited, and by whom, from the WDQS SPARQL service; and perhaps also via the API. Some edit information is available through WDQS (but possibly not in the RDF dumps), but it's not the most obvious of facilities, and I'm not sure whether the information goes down to statement level, or whether it only provides when the item as a whole was edited. But being able to easily see (including in the user-interface) who added or last edited a statement, and when would I think be an addition of considerable value.
(eg some have had a long-standing interest in being able to identify statements identified by official museum accounts, and from other GLAMs -- leading for an old proposal for statements to be cryptographically signable (phab:T138708). IMO the latter is completely unnecessary -- I am quite happy to trust Wikidata's servers as an authority for the edit history of an item, without requiring anything to do with Blockchain. But being able to access that information directly statement-by-statement, rather than only in the edit history of the item as a whole, would IMO be very valuable; and be an auditability step that would add to the perceived investigability and therefore practical transparency of Wikidata content). Jheald (talk) 19:08, 5 November 2018 (UTC)[reply]
A couple of further thoughts. In many ways, this suggestion is asking for a similar functionality to that provided by the en:Wikipedia:WikiBlame tool on regular wikis -- to see who was responsible for a particular wording in an article, and when. It might be quite straightforward to create a gadget that, at the press of a button added next to each statement, would filter the edit history and give a pop-up showing the lines relevant to that statement. Providing a more general API access would perhaps be more involved, but IMO would be worth it, and would give a more efficient back-end way to power a user-interface button. Providing access from WDQS would probably require again a different approach, but the OP's suggestion of augmenting the information in the RDF dump with an edit history attached to each statement would appear a nice way to go, if the WDQS SPARQL servers could handle what might presumably be a considerable inflation in the size of the triplestore. Jheald (talk) 19:25, 5 November 2018 (UTC)[reply]
  • If I'm understanding the proposal, this would be useful for tracing back systematic issues as well. As a part of the statement level provenance there should be reverts noted to the previous editor. Currently changing a statement made by someone else is not tracked as a revert, but essentially a change of a field is a correction to the person or bot which made the statement. This would be very useful for increasing the QA/abuse capabilities and analysis. Wolfgang8741 (talk) 17:21, 9 November 2018 (UTC)[reply]

@Chjohnson39: This would be a significant change in how Wikidata data is used and stored. Such a significant change needs community consensus before we can agree to touch it. Please create an RFC discussion on Wikidata first. If that discussion results in a consensus to move forward with this idea, we would be happy to reconsider working on it for next year. Ryan Kaldari (WMF) (talk) 21:42, 15 November 2018 (UTC) [reply]

Disable mobile view in preferences for logged-in users

  • Problem: On my smartphone or on my tablet, I only want to display the desktop version because the mobile one doesn't support gadgets (all Wikis) or even editing (Wikidata). So I often have to switch back to the desktop version which may be difficult due to infinite scroll on Watchlist or RecentChanges.
  • Who would benefit: All advanced users editing from mobile devices
  • Proposed solution: Add a preference for logged-in users to always disable the mobile version
  • More comments:
  • Phabricator tickets:
  • Proposer: Ayack (talk) 09:55, 5 November 2018 (UTC)[reply]

Discussion

Duplicate of Community_Wishlist_Survey_2019/Mobile_and_apps/Add_option_to_set_the_mobile_skin_and_desktop_skin Jdlrobson (talk) 20:53, 5 November 2018 (UTC) ?[reply]

I don't think so. This one is specifically about enabling desktop view on mobile as a preference. -- NKohli (WMF) (talk) 21:46, 6 November 2018 (UTC)[reply]

@Ayack: I use the desktop version on my iPad just fine; I tapped the "Desktop" button at the bottom of the page many months ago, and it's stayed that way. Are you finding that your mobile device forgets that you tapped that button, and that you need to tap it again? It sounds like you're experiencing a bug, to me. Can you give some more specific details about what's actually happening to you? --Deskana (talk) 01:02, 7 November 2018 (UTC)[reply]

@Deskana:: Yes, my iPhone and iPad regularly forget that I clicked on Desktop view. It's not systematic but it occurs often enough to be annoying. Ayack (talk) 09:12, 7 November 2018 (UTC)[reply]
I think it'd be better to fix whatever bug it is that's causing that rather than introducing yet another preference. Our preference system is now so complex that we can really only afford to add preferences if there's no other feasible way of addressing the relevant issue, so if the bug here can be fixed easily, that'd be a better route to go down. --Deskana (talk) 10:06, 7 November 2018 (UTC)[reply]
Hi Ayack: There's a product team that's currently working on advanced contribution features for the mobile skin. They're bringing lots of editor controls to the mobile site -- here's a current mockup:

 

I'm going to archive this proposal, because there's already a team working on it. You should check out that project page, and let the team know what you think. Thanks for participating in the survey. -- DannyH (WMF) (talk) 22:20, 15 November 2018 (UTC)[reply]

Use PetScan to find how long a template has been in an article

 N This feature is not technically feasible

  • Problem: There are a lot of articles with problems. These problems are often marked with a template, and sometimes the articles get fixed quite soon. There are also articles that have been marked for many years. Currently, it is possible to use PetScan to find out which articles have a certain template (example). What is not possible is to find out is which one of those articles was the first one to get the template.
  • Who would benefit: Active editors
  • Proposed solution: PetScan, A way to find the date a template was added.
  • More comments:
  • Phabricator tickets:
  • Proposer: Jylöstalo (talk) 17:38, 6 November 2018 (UTC)[reply]

Discussion

  • On en.WP we have a bot which adds the date so that the page can be categorized. Do other wikis not also have that? --Izno (talk) 19:16, 6 November 2018 (UTC)[reply]
    • Specifically: the current en.WP bot does edits like this to add date parameters to templates, and automates the creation of categories, and various other aspects of this workflow (see "TagDater" here for technical details). @Izno: the majority of communities do not have any (or enough) local bot-wranglers and lua/js-developers whom are needed to support the creation (or localization and customization) and maintenance of partially-automated workflows like this.
    • In the long-term, we need either global templates + global bots, and/or some sort of modular-creation-system for partially-automated workflows that is easy-to-use and localize, or something similar.
    • In the short-term, an idea like this one might(?) work to help those communities. However, I think it is essentially requesting the creation of the "Blame" tool, which is immensely complicated but widely desired - see phab:T2639 for links to the many previous discussions (including 3 past Wishlists) and research. Quiddity (WMF) (talk) 21:47, 8 November 2018 (UTC)[reply]

Archived

Jylöstalo, unfortunately our team wouldn't be able to work on this feature as adding template addition time tracking to MediaWiki is a fairly complex task that doesn't look good in cost/benefit analysis, while doing that in PetScan alone would require maintaining a huge database for that purpose only. Thanks for participating in our survey. MaxSem (WMF) (talk) 22:58, 15 November 2018 (UTC) [reply]

Allow users to comment when thanking others

  • Problem: 提議在條目歷史中的感謝功能裡添加可選摘要，若感謝者想要對被感謝者說些什麼時很便利。// In the page history, there is a "thank" button. Proposing to add the option of adding a short summary in order to better convey why are you thanking a particular user for their edits.
  • Who would benefit:
  • Proposed solution:
  • Phabricator tickets: T58373 (declined)
  • Proposer: Janee Talk to me 10:17, 4 November 2018 (UTC)[reply]

Discussion

@Jane9306: Do you have any thoughts about the suggestions above? I wouldn't be opposed to a proposal along the lines of JAn Dudík's solution, but the proposal as written has already been declined in Phabricator and goes against the purpose of Thanks, which is to provide a very simple feedback mechanism that requires no extra moderation of content. (The WikiLove extension was created to handle more complicated positive feedback needs.) If there is no response before the voting period begins, I'll go ahead and close this proposal (per the "previously declined" rule). Thanks for your understanding. Ryan Kaldari (WMF) (talk) 01:47, 14 November 2018 (UTC)[reply]

Maybe a "post to editor talk page about this edit" button next to the "thanks" button? I'd like a function that would let me post a talk page comment containing a link to the edit in question easily from the history page. HLHJ (talk) 07:35, 14 November 2018 (UTC)[reply]

Unnecessarily adds a harassment vector. Oppose. MER-C (talk) 12:44, 14 November 2018 (UTC) [reply]

Wiki skill support at Wikisource

  • Problem: Newbies are discouraged or get negative feedback due to lack of wikiskills.
  • Who would benefit: Newbies/people who would be excluded because of lack of wikiskills/minorities representation on WS because their present low representation is due to lack of skills + moderators etc who spend too much time on supporting individuals in this category + Wikisource as it would be a source of proofreaders to increase content
  • Proposed solution: Wikisource is developed as the training ground for newbies where, because the content is provided, there is much less that a newbie can do "wrong", avoiding a sense of harassment: With tools that make it easy to work from a limited skill set + a decent help + consensus on a standard of proofreading.
  • More comments: From discussion on Wikisource Scriptorium re the negative impact of recent changes to wikieditor:

    To be frank, the editor as it was needed a total overhaul from a proofreaders point of view. It could be a very useful support for new proofreaders, a key tool for teaching new people how to wiki. I think it would be great kudos for Wikisource to be the place where newbies can come to learn how to wiki without having to worry about content and a discussion of how these tools could support proofreading with this intent in mind would be very valuable. I think WS could get a lot more support and respect from the Wikipedia community if we pitched this as a key aim of WS: to be the community that teaches wiki skills from the most basic level. This would require a training process, like at Distributed Proofreaders: that would mean (shock, horror) standard ways to do things that support people who are low or un-skilled. I've learned an awful lot since starting here but by sheer bloodymindedness and an inclination to learn. Most people wouldn't withstand the learning process. Which is why, in my humble opinion, proofreaders are so scarce here. There is an assumed level of competence with working on a wiki as a prerequisite to contributing at WS. I have found that generally, the culture here is really good, people don't jump down your throats like at WP. There is huge potential for people to choose their level of contribution, once they are past that initial learning curve so newbies can work at their own pace and get comfortable. It could be the place to which Wikipedians retreat when they have encountered shit at WP, or they just aren't up to dealing with it. With tools that make it easy to work from a limited skill set + a decent help + consensus on a standard, perhaps fencing off certain works as beginners level or having their own standard like Popular Science (with an appointed Project Manager, as at DP), people would have clear guidelines of the expected skill level and they could choose appropriately. Then we can be really supportive of people at the level they are at. WS could feed WP with upskilled contributors and WS would be recommended to anyone on any other wiki site as the place to go to upskill so we get more proofreading done. Win, win.

Discussion

Zoeannl I acknowledge the problem you describe here but the solution you suggest is more of a social change and not a technical one. We cannot comvince communities to treat Wikisource as a playground for newcomers. We also don't have a way to funnel newcomers across all projects to Wikisource. This is also something that would need communities (like Wikipedia) to agree to. I would recommend you think of technical things we can do to help with the situation - make the proofreading experience better or create a tool to teach wiki-skills to beginners or such. Thank you for putting up a proposal. -- NKohli (WMF) (talk) 19:45, 5 November 2018 (UTC)[reply]

Hi Zoeann1, it seems to me like the real technical wish is to make the proofreading tools easier to use, so that new editors will be more likely to participate on Wikisource. I think that's a worthwhile wish. But there's an extra layer in this proposal about sending new people to Wikisource in order to learn how to work on wikis, which would be a social change that the Community Tech team can't work on.
Are you interested in rewriting this proposal, to just focus on making the proofreading tools easier to use? If you do that, then I think this is a great proposal. If you leave it the way that it is, we'll have to decline it as out of scope for the Wishlist Survey. We've just got a couple days until the voting period starts, so you'd have to make the changes right away. Can you make those changes, or should we decline the proposal? -- DannyH (WMF) (talk) 01:34, 14 November 2018 (UTC)[reply]
Zoeann1: We're getting close tot he voting period, so I'm going to archive the proposal. Thanks for participating in the survey! -- DannyH (WMF) (talk) 00:15, 16 November 2018 (UTC)[reply]

Crosswiki articles for deletion notice

 N This proposal is too big

  • Problem: On the one hand, some cross-wiki spam or vandalism made advertising articles, original research articles, and lack of notable articles, etc., sometimes take a long time to remove them from all projects (especially small Wiki). On the other hand, some articles may be deleted by mistake due to restrictions on language, culture, etc. If there is a cross-wiki AfD notification, it should alleviate this problem.
  • Who would benefit: Wikipedia editor, Wikimedia
  • Proposed solution: Each wiki setup a central page. If a language version of an article is AfD, the central page of the other language is notified. Or if a language version of an article is AfD, it is notified on this article talk page in other languages.
  • More comments:
  • Phabricator tickets:
  • Proposer: Shizhao (talk) 07:01, 5 November 2018 (UTC)[reply]

Discussion

  • I recently had to go through the articles for en:Kishu mikan, fr:Kishu mikan, and nl:Kishu mikan, removing the same advertising content from each. ja:キシュウミカン did not seems to have it, as far as I can tell. I also added a major update to a featured article based on new sources. In other languages there are six other featured articles, and five ex-featured articles, and 21 others, all or most needing the update, too. I don't speak 31 languages, and I can't even figure out how to template them to look at the English version. A specifiable cross-language notification would be useful. HLHJ (talk) 06:46, 14 November 2018 (UTC)[reply]

Archived

Hey Shizhao, unfortunately our team decided that we'll be unable to work on this proposal as supporting interrelations between many projects with different workflows is too much work during the year when we'll need to work on other 9 projects. MaxSem (WMF) (talk) 00:23, 16 November 2018 (UTC) [reply]

Merge user accounts

  • Problem: Two user accounts of one person cannot be merged.
  • Who would benefit: Everybody: to get back an overview with whom we are working.
  • Proposed solution: Develope a version of the Mediawiki-tool that is also functioning in Wikipedia.
  • More comments:
  • Phabricator tickets:

Discussion

  • Could you point to any instances where this would legitimately be used? Otherwise this sounds like an amnesty for sockpuppets. Cabayi (talk) 09:15, 31 October 2018 (UTC)[reply]
  • @Slaney: mw:Extension:UserMerge is already deployed on Wikimedia servers, but Global User Account merges are not possible according to phab:T49918. Could you clarify which specific situation(s) you have in mind? Thanks! --AKlapper (WMF) (talk) 15:02, 31 October 2018 (UTC)[reply]
  • There are users who use other accounts for some time. I would not like to judge about the reasons. Maybe there was not a rename-function and they changed from editing with real name to editing with pseudonym, or vice versa, or they chose to do so to have more distance from community and more focus onto the articles. In these cases putting 2 accounts back to 1 should be a good option: statistics about user activity, started articles, number of hits would be one. There would be only 1 account that is confirmed with the right to vote. What I heard was, that it was planned and tested, but after a test the login failed to unknown problems. - Slaney (talk) 15:12, 31 October 2018 (UTC)[reply]
    Personally I had begun with my real name 10 years ago, before creating a pseudo (I didn't know about the renaming possibilities). So I could use it. Moreover, I can see that the situation to edit anonymously before realizing that the browser wasn't logged, often happens. JackPotte (talk) 11:33, 1 November 2018 (UTC)[reply]
    @Cabayi, Slaney, and AKlapper (WMF): There are valid and allowed situations for creating another account by the same user. Our use-case in WMCZ are the Wikipedia courses – I have created 3 new accounts during the last 2 years, because I need to show to the "students" of the course (senior citizens in our case), what exactly happens when you register for the first time, what will happen with the account after my/theirs first edit and so on. All these 3 account are completely useless for me after the end of each course, so it would be nice to merge them in my primary, personal, account and tidy the usernames for others. Ping at Vojtěch Veselý, 'cause we have discussed this before --YjM (talk) 00:12, 10 November 2018 (UTC)[reply]
    That doesn't seem like a great use case. You should show what happens when you create a student account. --Izno (talk) 01:21, 10 November 2018 (UTC)[reply]
    There are cases with some thousand edis per account. The MediaWiki-Feature has been developed many years ago anyway (like renaming accounts as well). The last particular problems could and should be solved. -- Slaney (talk) 07:04, 10 November 2018 (UTC)[reply]
    @Izno: I don't fully understand what you mean by "student account"... --YjM (talk) 14:33, 11 November 2018 (UTC)[reply]
    I agree. Right now, I have roughly 20 of these useless "show-how-it-works" accounts. I need some five or seven new every year... If I can use only one, merging it at the end of the course and re-register it at the beginning of the next one and so on... that would be nice. --Vojtěch Veselý (talk) 10:48, 12 November 2018 (UTC)[reply]
    However, there is the problem with these onec created sandboxes and userpages. After the merging, these should be deleted (and not redirected) to clear the space for new creating the next time.--Vojtěch Veselý (talk) 10:51, 12 November 2018 (UTC)[reply]
  • @Legoktm and Keegan (WMF): has anything technically changed in this area since it was last significantly discussed (early 2016? T49918), which might make it more feasible to look at again? (i.e. an investigation, if not actual development). If not, we'll have to decline it. Quiddity (WMF) (talk) 00:00, 14 November 2018 (UTC)[reply]
    Not really. The main change has been the introduction of the actor table, but that will only make renaming users easier, not merging users. I wouldn't say anything is technically impossible, but I can't imagine any scenario in which the development cost is worth the value provided to users. Legoktm (talk) 01:27, 16 November 2018 (UTC)[reply]

Allow run-preview of user-sandbox templates

  Proposes an existing feature

  • Problem: When editing a sandbox version of a template, under userspace prefix "User:XX/Template:", then the run-preview feature is not activated. There should be a data-field "Template replaced" to specify which template name is being replaced by the sandbox edit.
  • Who would benefit: Anyone who edits templates as userspace sandbox versions.
  • Proposed solution:
  • More comments:
  • Phabricator tickets:
  • Proposer: Wikid77 (talk) 10:40, 10 November 2018 (UTC)[reply]

Discussion

Pageviews Statistics improvements

 N Outside the scope of Community Tech

  • Problem: I'd like to pay attention on 2 issues with pageviews statistics:
    1. Sometimes there are strange outliers that cannot be explicate in any simple way. For example see stats of article Tunnel in October. It can be caused by some technical error or even by an attendance cheating or something else. By the way this distorts the real stats.
    2. The source of pageviews is not evident. Some readers can come to WP article through Google search, others turn up from another WP page or sister project, etc. And that's why it is not known how to pull new reader, what way is the most effective.
  • Who would benefit: All projects (especially not very popular) by pulling new readers. Pageviews analysers.
  • Proposed solution:
    1. Calculate statistics of unique readers in addition to total views. This facility is wide spreading through stats counters like Google or Alexa.
    2. Split all views to some categories by where from the reader comes (don't know whether it possible) like "from another WP page", "from sister project", "from Google search" etc.
  • More comments:
  • Phabricator tickets:
  • Proposer: Emaus (talk) 14:37, 11 November 2018 (UTC)[reply]

Discussion

  • Hi Emaus! The issue with strange outliers is common. This is usually because an automated program is scraping the page (why they do this, no one knows...). There is some logic that filters out bots, but this is only if they declare themselves as a bot. The false positives you see are when the bot is pretending to be human. Some project-wide anomalies and known issues are published at Dashiki:PageviewsAnnotations. Doing this on a per-page basis may not be feasible, as I assume every anomaly has to be investigated and confirmed individually, which won't scale. phab:T138207 lists some things that are being investigated in order to improve automatic bot detection.

    Your second point has to do with referrals. This data does exist, but I believe it is not publicly available for privacy reasons. I cannot say for sure, so I'm going to ping NRuiz (WMF) and Milimetric (WMF) who are on the Analytics team. I wonder if it would be possible to sanitize referral data to basic things like "internal" or "external"? Perhaps even more fine-grained such as "external - search engine" and "external - direct"?

    Regardless, I think implementing these systems will be a large project that's possibly outside Community Tech's scope. I will wait for input from Analytics, as maybe there are some things we could help with. MusikAnimal (WMF) (talk) 00:56, 14 November 2018 (UTC)[reply]

  • Unfortunately, as we have not heard back from you, or from my colleagues (no disrespect to anyone!), I am going to archive this proposal as out of scope. It is my strong suspicion we won't be able to help with this at this time. Better bot filtering is on the radar for the Analytics team, and referral data is not currently publicly available. The good news -- I am the primary author of Pageviews Analysis, and I am committed to making more improvements to it. Once your requested features become feasible, I will happily implement them into the application. If you'd like to discuss further, let's move it to Talk:Pageviews Analysis or Phabricator. Thanks for participating in the survey! MusikAnimal (WMF) (talk) 17:39, 16 November 2018 (UTC)[reply]

MP4 uploading

  • Problem: Users can't upload directly their MP4s, and they have to use an "external" system (video2commons) and, most of the times, upload it before to YouTube so it can be grabbed. This creates some problems: video uploading is not encouraged, video production depends on other services and we can't enrich articles. Currently, nearly all the publishing platforms in the world allow using a wide variety of formats, and we are the only one not allowing to upload the most used video format. New users can't use the video2commons solution, because they don't have permissions in Commons, so we can't make video creators engage in our project and they won't free license it anywhere.
  • Who would benefit: Readers and uploaders. Also people who isn't aware of the video format we need to use
  • Proposed solution: Allow MP4 uploading directly, to everyone without restrictions.

Discussion

This was a community decision that would have to be overturned before WMF developers could work on this I think. —TheDJ (talk • contribs) 13:52, 30 October 2018 (UTC)[reply]

mp4 is a proprietary format I don't think it works well? Gryllida 22:53, 30 October 2018 (UTC)[reply]

As of earlier this year, all MP4 patents are now expired, so it is no longer patent-encumbered. TheDJ is correct though that Commons would need to have a new RfC to overturn the results of the old RfC before the WMF could work on supporting it. Kaldari (talk) 05:10, 31 October 2018 (UTC)[reply]

This is a 2014 decision, at that time patents was not at the same stage as today, and also a RfC is just a consult... If here we have enough support, is not necessary a RfC there. However, I believe that the priority should be a internal transcoder to .webm, upload videos at WCommons is painful. Rodrigo Tetsuo Argenton m 06:56, 31 October 2018 (UTC)[reply]

As a video editor working for a Wikimedia chapter, I strongly support rethinking the blanket ban on uploading .mp4 files. I am not sure that Kaldari is correct about .mp4 patents expiring though - I thought it was .mp3 patents that expired earlier this year. However, if they are correct and .mp4 is also out of copyright, this would be a very good reason to have an RfC about changing the ban on these files. As a video editor, .webm is a poor quality format, which cannot anyway be used in common editing programmes like Adobe Premiere Pro. If I wanted to use video files from Commons, I currently have to transcode them into a usable format, which would be of low quality, and then when I output the file again, I'd have to transcode back to webm. The result of all this is that Commons is totally useless to video makers. This has also created a situation where we don't have many video makers in our community who could press for change. If we could change this, Commons would become the most important and useful resource for video makers on the internet. --Jwslubbock (talk) 12:22, 1 November 2018 (UTC)[reply]

Or it might be the MPEG-2 (h.262) patents Kaldari was thinking of. But MP4 is apparently often used with h.264/MPEG-4 AVC, for which the last patents apparently don't expire until at least 2028. I don't know about other video codecs that might be used with MP4. Anomie (talk) 12:47, 1 November 2018 (UTC)[reply]
Oops, you're right, I was thinking of MPEG-2 video! Who's using this new-fangled MPEG-4? In that case, this wish is pretty much impossible, as the Commons community isn't going to agree to support a patent-encumbered format. Kaldari (talk) 17:23, 1 November 2018 (UTC)[reply]

I totally agree with this proposal. Today, MP4 format is a standard everywhere and why shouldn't we make life easier for people contributing to Wikimedia projects. --Luky001 (talk) 00:38, 2 November 2018 (UTC)[reply]

there are some tools not let you feel the transcoding work, video2commons notably: https://tools.wmflabs.org/video2commons/, which make it easy to contribute mp4. but - i needed to use google to find it. imo a simple interface like video2commons should be standard. --ThurnerRupert (talk) 06:33, 9 November 2018 (UTC)[reply]

@ThurnerRupert: Can't you just insert magic word __INDEX__ to your files, so your files are hard-coded indexed by all search engines around the world? --Liuxinyu970226 (talk) 12:39, 11 November 2018 (UTC)[reply]
OTOH, @TheDJ and Gryllida: Then why do we allow seleted users to have specific permission to upload MP3 files? --Liuxinyu970226 (talk) 15:07, 12 November 2018 (UTC)[reply]
@Liuxinyu970226: MP3 files no longer have any patents. Uploads of these are only restricted because people feared that Commons would be used as a website to share 'illegal' mp3s and that the community would not be able to keep up with reviewing them. —TheDJ (talk • contribs) 15:39, 12 November 2018 (UTC)[reply]

The main blockers for this proposal are social and legal, not technical. If a new RfC on Commons overturns the existing consensus against uploading MP4, we would be happy to reconsider. Ryan Kaldari (WMF) (talk) 00:39, 15 November 2018 (UTC)[reply]

@Ryan Kaldari (WMF): Why isn't this proposal in the voting list? -Theklan (talk) 18:29, 17 November 2018 (UTC)[reply]
@Theklan: The Commons community already decided that they don't want to allow MP4 video (by a wide margin). The Community Wishlist is not the appropriate forum to overturn that decision. If you start a new RfC on Commons and it looks likely to pass, I would be happy to re-open this proposal. However, it seems unlikely that Commons will choose to accept MP4 until all of its patents have expired. Ryan Kaldari (WMF) (talk) 03:41, 19 November 2018 (UTC)[reply]
@Ryan Kaldari (WMF): I'm not suggesting to store MP4 in Commons, but to allow uploading it. You can upload MP4 to the system and then make the conversion to webm in order to have the file. In other words: YouTube allows the uploading of virtually any file and then stores it in mp4 format. Let's do the opposite! -Theklan (talk) 08:03, 19 November 2018 (UTC)[reply]
@Theklan: That was one of the options that was proposed at the previous RFC, but it didn't receive a lot of support. Ryan Kaldari (WMF) (talk) 18:25, 19 November 2018 (UTC)[reply]
Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2019/Archive&oldid=26515614"