Community Wishlist Survey 2017/Archive

This page is an archive for 2017 Community Wishlist Survey 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 27, 2017, we can't move any proposals out of the Archive.

make more detail in information,To protect all reader profit

  Idea is not well explained

  • Problem:
  • Who would benefit: reader
  • Proposed solution: create more protection
  • More comments: create more information
  • Phabricator tickets:

Community discussionEdit

This proposal is currently too vague and unclear. Please follow https://meta.wikimedia.org/wiki/2017_Community_Wishlist_Survey#What_happens_during_the_proposal_phase.3F and provide way more information, by editing your proposal. --AKlapper (WMF) (talk) 12:38, 7 November 2017 (UTC)

  • Sorry, but I've archived this proposal because nobody can understand what you mean. You may want to find someone to translate your proposal from your native language. Feel free to revise and unarchive. Thanks! Max Semenik (talk) 18:35, 8 November 2017 (UTC)

Provide a search facility for office documents (like .doc)

  Unrelated to Wikimedia projects

  • Problem:

By now searches in e.g. .doc files is not possible.

  • Who would benefit:

Anyone up to the wikia software base, where it would be of additional benefit due to enhanced possiblities to use wikia for business applications.

  • Proposed solution:

An internal tools is needed to decipher (proprietary) data formats. There is an abandoned project/version somewhere (saw it some years ago).

  • More comments:
  • Phabricator tickets:
  • Proposer: Mideal (talk) 10:57, 7 November 2017 (UTC)

--Mideal (talk) 10:57, 7 November 2017 (UTC)

Community discussionEdit

Hmm, how is this related to bots and gadgets? Sounds more like https://meta.wikimedia.org/wiki/2017_Community_Wishlist_Survey/Search to me? --AKlapper (WMF) (talk) 12:32, 7 November 2017 (UTC)

  • This is a Wikimedia community survey. So far, your proposal doesn't have anything related to our projects so it doesn't look eligible. Max Semenik (talk) 21:48, 7 November 2017 (UTC)
  • If you want enterprise features, you will need to pay for them. MER-C (talk) 01:11, 8 November 2017 (UTC)

ArchivedEdit

Per my comment above, I've archived this proposal as it's clearly not related to Wikimedia projects. We're not enterprise users and you can't even upload files in proprietary office formats here. Please feel free to reformulate and unarchive. Thanks for participating! Max Semenik (talk) 19:52, 8 November 2017 (UTC)

Rules for internal Wikimedia projects

 N Proposes social/community change rather than a technical feature

  • Problem: Harrasment, defamation and lies of users in internal or non offical Wikimedia projects/groups (e.g. Phabricator, Meta) make contributing impossible to some users. The problem is, these groups does not have conflict solving processes, like Wikipedia and attackers, may freely live, within these communities.
  • Who would benefit: Wikimedia Projects, inidividual contributors
  • Proposed solution: Establish transparent decission making process and adopt Wikipedia like proceduress like Arbitration Comittees, within the groups, which doesnt have them yet.
  • More comments:
  • Phabricator tickets:

Community discussionEdit

I'm afraid this is out of scope for this survey as the survey is about community's technical needs while your proposal is about policies. Do you have any technical asks? Max Semenik (talk) 21:07, 8 November 2017 (UTC)

@Juandev: Just this year, Wikimedia's Code of Conduct for technical spaces went into effect. It is a new policy and committee designed to resolve exactly the problems you are mentioning on Meta, Phabricator, IRC, and other technical spaces. Are there any tools or features that need to be built for this to work? I'm going to archive your proposal, but please open a new one if you have ideas for tools or features for us to build. — Trevor Bolliger, WMF Product Manager 🗨 21:24, 8 November 2017 (UTC)

Викимарафоны и конкурсы с ценными призами

 N Proposes social/community change rather than a technical feature

  • Problem: Викимарафоны и конкурсы по написанию статей в настоящее время привлекают недостаточное количество участников. Работа над статьями ведётся весьма медленно. В то же время конкурсы "Ящик конфет/компьютер/автомобиль/ за репост" в соцсетях набирают сотни тысяч и миллионы репостов. Почему же мы не можем организовывать нечто подобное? К тому же многие редакторы были бы рады получить вознаграждение за активную работу.
  • Who would benefit: википроект, в котором будет проведён такой спецзабег.
  • Proposed solution: необходимо регулярно организовывать статейные конкурсы с ценными призами. Призы может обеспечивать спонсор, при этом каждый приз должен быть брендирован Википедией. Статьи заливаются в Фонтан и оцениваются жюри, причём базовые критерии качества (размер от 5 КБ, хоть одна ссылка а источник, хоть одна категория, антиплагиат) проверяются автоматически. Возможные форматы конкурса:
  1. Обычный забег по написанию статей, универсальный или тематический. Статьи оцениваются жюри балльно, в конце концов все участники ранжируются по количеству баллов и соответственно получают награды.
  2. Забег с вероятностью. Призы разыгрываются рандомно, как в конкурсе репостов, но количество баллов влияет на вероятность (пример: в марафоне 2 участника, первый получил 10 баллов, второй - 40. С вероятностью 80% приз получит второй участник).
  3. Призы с объявленной ценностью. Заранее объявляется ценность каждого приза (например, значок - 10 баллов, смартфон - 1000 баллов и т.д.), а по итогам забега каждый участник может потратить полученные баллы на любые призы по своему усмотрению, как в ru:Поле чудес.
  4. Гарантированные призы. Ставится несколько планок, и в зависимости от того, какая достигнута, участник получает приз. Например, если по итогам марафона более 300 баллов - получает набор сувениров, более 2000 - смартфон, более 5000 - ноутбук.

Разумеется, призы могут быть тематическими, если таков марафон. Например, на марафоне искусств можно разыгрывать репродукции картин и книги, на географическом марафоне - атласы, глобусы и навигаторы, на музыкальном - сборники нот, наушники и музыкальные инструменты. Главный приз должен быть наиболее ценным, а поощрительными призами для большого количества участников могут быть блокноты, значки, магнитики и даже коллекционное издание Википедии на CD-диске. Под Новый год можно проводить большой марафон с исключительно ценными призами, например, главным призом может быть автомобиль (а поощрительные призы - ёлочные игрушки в виде логотипа Вики). Для повышения интереса новичков марафоны должны быть широко анонсированы в социальных медиа.

  • More comments: работа над статьями в настоящее время выглядит так: "Служи, дурачок, получишь значок!".
  • Phabricator tickets:

Community discussionEdit

ArchivedEdit

I've archived this proposal because it's about running an event while our survey is about technical problems only. Thanks for participation though! / Я перевёл это предложение в архив потому что оно касается проведения мероприятий, тогда как наш опрос только для технических вопросов. В любом случае, спасибо за участие! Max Semenik (talk) 23:06, 8 November 2017 (UTC)

Establish fund for those, who work with community

 N Proposes financial/cultural change rather than a technical feature

  • Problem: Price of transporation or of some tools, bocks some people to work with community.
  • Who would benefit: Activy community, Wikipedia and Wiki projects
  • Proposed solution: We have funds, which supports development, we have fund which support people on travel on non Wikimedia events, but we dont have fund/programme to support people on travel for people, who need to meet physically community and work with them. So, I would set some roles and establish it.
  • More comments: Even we had reasearch on community, which revealed us much. We still take care of newbies and of looking for new editors. Old editors, kind of stay behind an are left. To work with these editors, may help with their survival, but also with how, they will care of new editors and adopt changes. If you want to travale and animate people to work on the crosslanguage project, you must be from a country, where is a strong Chapter, which will support you - otherwise your activity is lost.
  • Phabricator tickets:

Community discussionEdit

Hi Juandev, this proposal doesn't fit the purpose of this Wishlist Survey. We're looking for ideas for features or fixes that our development team can build. Our team doesn't financially support community projects; I think what you're looking for is the Grants process. I'm going to move your proposal into the Archive. Thanks for participating in the survey. -- DannyH (WMF) (talk) 23:37, 8 November 2017 (UTC)

Blockbox (information on relevant policies to blocked users)

 N Proposes social/community change rather than a technical feature

  • Problem: Well, coming from a currently (as of writing this on August 19th, 2017) blocked user I can tell you one thing, the blocking experience is very user unfriendly, if you are not familiar with WikiJargon or have sufficient knowledge of all the rules and guidelines (which I have familiarised myself with now) this can be a troubling ordeal, especially since you might not know your options. One of such options (on English Wikipedia at least) would be the UTRS, if your talk page access has been revoked and you have no idea what to do.

Maybe you think that what you did was appropriate, well the list on the “Blockbox” could precisely show what options you have as well.

  • Who would benefit: Well, most importantly the readers, and of course blocked users. This would also largely save the time of administrators for (1) not having to explain the reasons for their blocks after it has been applied as the policies are directly linked, (2) have an informative guide to all the necessary information, and (3) make it more likely that the appealing people are more informed on WikiPolicies, how to appeal blocks and how to avoid any re-blocking.
  • Proposed solution: Well, Wikimedia projects are all educational, so why not educate those who have been blocked on why they have been blocked? In those United States of America many police 👮🏻 officers read people their rights upon arrest, this could also familiarise those who genuinely have a wish to be helpful to educate the readers and utilisers of Wikimedia projects to return and learn what they did wrong.

Remember, trolls and vandals probably won’t file an unblock request, in most cases they will evade and troll some more, but those who are genuinely interested in learning from their mistakes and willing to contribute positively should be given a chance, even if they’ve been unfriendly I would say “be friendly to unfriendly people and they might return the favour”, in fact I would probably advocate a model of “talk first, block later” but to apply that community wide would be unrealistic, allowing blocked people to be properly educated on their disruptions and their options might even work to prevent a repetition of the behaviours that lead to their blocks in the first place.

I thought of an idea that could basically serve as “the Miranda rights of Wikipedia” (or “the Blockbox”) where after a user or IP gets blocked by an admin (so not rangeblocks or autoblocks but direct blocks) a bot will automatically leave this message on their talk page (even if the talk page was previously deleted). This could start off on English wikipedia and then if it turns out to be successful could be “exported” to other wikis.

It appears that you have been blocked.

Please read the guide to appealing blocks.

* If you are currently unable to access your talk page you may request an unblock via the Unblock Ticket Request System or the #wikipedia-en-unblockconnect chat channel.
* Checkuser and Oversight blocks may be appealed to the Arbitration Committee.
* If you were blocked by Jimbo Wales then you may appeal directly to him and/or the Arbitration Committee.
* If this is a Sockpuppet then you should confess your main account (or IP) now so you may receive a reduced penalty.
* If you have been blocked for a username violation then you can simply create or request a new account or request to be renamed here or at #wikimedia-renameconnect, if however the username was made in bad faith then first request a rename and then you may appeal the block; further reading Wikipedia:Changing username.
* If you have been blocked for adding promotional material or spam then please read about our policy on this and our external links policy before requesting an unblock.
** If you continue to violate this policy then the next time the duration of your block will increase. If you believe the link(s) you added aren't spam then you may request for it to be removed from the blacklist.
* If your options are currently still unclear then please read the more technical how to appeal a block.

Notes: As of currently the standard offer is 6 months but maybe if a user confesses this could be reduced to 3 months or something in that direction, this would give sockpuppeteers more of an incentive to co-operate.

The above are all the blocking criteria I am currently aware of, this is just a suggestion and open to improvement.

Personally I envision this box/template to be red or orange or a combination thereof but I am not familiar enough with the parameters to adjust this.

Maybe a sad Wikitan in prison clothes could be used as the image. 🤔

Note that all links 🔗 function as if they are in the English Wikipedia and may not function here on Meta.

For this task a new bot called the “Mirandabot” will be programmed, on a more humourous note it could tag every edit with “You have the right to remain silent, anything you say can and will be used against you in an appeal of WikiOrder”, this bot solely exists to deliver the above template and may not perform any other tasks.

IMPORTANT NEED FEEDBACK: Maybe a note for living people who were trying to remove unsourced slanderous material from pages about themselves to be directed to the right outlets, this will almost certainly prevent many WMF office actions. But then again I’m not a barrister, works?

Also note that this is to prevent further disruptions and to familiarise blocked persons with the guidelines and policies that apply to Wikipedia, as of now those willing to come back to contribute positively are faced with a wall of silence and not all rules and guidelines are properly linked to each other, I believe that creating such a system can be instrumental in preventing many disruptions, sure trolls will troll not every blocked person is a vandal and we should not assume as such.

Honestly I thought that this idea could also “grandfather in” users blocked prior to its launch, however that might require a “MirandaBotOld” or might it simply delay the newly blocked members of the community, however I think that time should be no issue and that all standing blocks should also be grandfathered in.

The goal of this project is to ultimately reduce the number of disruptions and increase the numbers of willing good faith contributors, if we would approach everyone with a friendly message showing them their available options and inform them to properly read the guidelines they did wrong I strongly believe that the amount of continued disruptions to the project shall decrease, even if there are current flaws and yes the system is open to abuse (angry trolls might vandalise the IRC channels) I think that it will do more good than harm.

  • More comments: Additionally there should be a newly established “Sockfession booth” where Sockpuppeteers (such as myself) may have the option to confess and receive less penalties, however the system may only be used once and repeated violators of WP:SOCK will then be “punished” the same way as those who didn't confess (your “once sock shot” if you will).

Other names for the Sockfession booth could be “Wikipedia costums” (as in border costums), “Multiple Account Disorder Therapy Group” (for those who share my sense of humour, to those that don't get it it’s named after the multiple personality disorder), or “Drawer checkings” (get it…. Because they’re socks… I’ll let myself out).

  • Phabricator tickets:

Community discussionEdit

  • How is this "problem" not solved by MediaWiki:Blockedtext, WP:GAB and Template:Unblock? And why should we bother trying to help blocked users come back and waste more volunteer time, especially those who are blocked for very good reasons? MER-C (talk) 12:00, 9 November 2017 (UTC)
Hi Donald Trung: The Wishlist Survey is looking for proposals that the Community Tech product team could work on. What you're proposing here is a social/community change, rather than a technical feature. I'm archiving this proposal. Thanks for participating in the survey. -- DannyH (WMF) (talk) 19:14, 9 November 2017 (UTC)

User watchlist

 N Declined in a previous survey

  • Problem: в настоящее время невозможно удобно следить за вкладом выбранного участника, сделанным в любые страницы. Это может быть полезно для контроля за потенциально недобросовестными или неопытными участниками либо за участниками, чей вклад представляет интерес для наблюдающего
  • Who would benefit: зарегистрированные участники
  • Proposed solution: предлагается включить функцию "Следить за вкладом участника". В этом случае в списке наблюдения будут отображаться все его правки, сделанные в любые страницы. Аналогичное наблюдение можно сделать для IP-адресов.
  • More comments:
  • Phabricator tickets:

Community discussionEdit

Translated to English...

  • Problem: It is currently not possible to conveniently monitor the contribution of the selected participant made to any page. This can be useful for monitoring potentially unscrupulous or inexperienced participants or for participants whose contributions are of interest to the observer.
  • Who would benefit: Registered participants.
  • Proposed solution: it is suggested to include the function "Follow the participant's contribution". In this case, all the edits made to any pages will be displayed in the watchlist. A similar observation can be made for IP addresses.

(Translated to make discussion more accessible to others. Tortillovsky (talk) 00:15, 9 November 2017 (UTC))

Yes -- unfortunately, this isn't a feature that we can build. There are good reasons why people want a feature like this, but it makes things too easy for a user who wants to harass others. As Semmendinger said above, you can read more about this on the Community_Tech/Add_a_user_watchlist page. I'm going to move this proposal to the archive. Thanks for participating in the survey! -- DannyH (WMF) (talk) 21:48, 9 November 2017 (UTC)

Take the subject of licenses seriously

 N Primarily a policy/licensing change rather than a technical feature

  • Problem: Wikidata withdraw licenses while performing massive imports from miscellaneous sources, including Wikipedia. This put the project itself, and every project using it at large scale, at a heavy legal risk.
  • Who would benefit: Anyone using wikidata at some expand.
  • Proposed solution:
    • Integrate a field "licenses", enabling to document this at the same extent as references
      • Update this field for every Wikidata entry which obviously came from a massive import (be it through bots or crowd sourcing)
      • If any, remove data which came from such a massive import backed on sources without at least one explicit free license
      • Allow every user to select a set of free licenses under which they agree to publish their own original contributions, so that the "licenses" field is set automatically for this user contributions. As on Commons, user should select at least one free license, but neither CC0 nor any other license should be an mandatory choice.
        • Of course if the data is already licensed under a license not compatible with some of the user set of license, any attempt to contribute should lead to a warning and, after user approval, a publication only under the modified data license set and its intersection of compatible licenses within the user license set.
      • For the sake of equity that our movement is highlighting as one of its core value, the default license set should only include copyleft licenses.
        • For the sake of compatibility with other Wikimidia projects that Wikidata is suppose to back, this default set of licenses should include CC-BY-SA-3.0-unported and possibly GFDL 1.3.
      • Whatever the default set of licenses will be selected, the existing data should move to it, so it will cover further updates of this entries. But CC0 might stay relevant for data imported so far when they didn't came from sources with incompatible licenses – like Wikipedia. Note that this move is completely allowed by CC0 and was even advanced as part of the plan beyond the test phase[1].
    • Conduct an open legal inquiry with experts of the field to create a clear up-to-date report of what is – under current laws – definitely legal, definitely illegal, and what is in the realm of legal blur.
      • Following this report, adopt clear policies for Wikidata to only accept contribution that stands in the field of definitely legal practices
        • If any, clean Wikidata entries which are already recorded and don't conform to this policy
        • Possibly, develop some tools which help making this policy respected
  • More comments:
    • This solution does not prevent any reuse at all. It only makes more clear what are the real potential legal issues, were the current practise is to pretend there is no issue without presenting any serious report on the subject. Giving a fine grained license information allow reusers to remix accordingly with full background knowledge. Querying features make it easy to filter data which are covered under compatible licenses.
    • On a side note, a policy regarding import of Wikipedia content should be created in order to avoid circular references which make a large portion of Wikidata references useless for Wikipedia and sister projects, all the more when the reference doesn't provide a precise passage of an article in a given version.
    • Enlarged community consultation on some or all of this point would be appreciable.
    • Most points are independents, or the list depth reflect this dependencies, so it's not a take or leave it all proposal.
  • So do I understand it correctly that during development and testing, we can can go with CC-0, and later relicense to whatever seems suitable, which is possible with CC-0 [Wikidata-l] Is CC the right license for data? Denny Vrandečić Tue Apr 3 09:42:57 UTC 2012
    • Phabricator tickets:

    Community discussionEdit

    IANAL but it seems like a good idea to have Wikidata content doubly-licensed under CC-BY-SA and ODbL, to ensure that no compatibility issues arise from importing stuff into Wikidata. It's a win-win: if you take the stance we should ignore the fact that certain jurisdictions uphold database rights, no ill will come from using our data. If you accept the (regrettable) existence of database rights, this will have the added benefit of multiplying free cultural goods. NMaia (talk) 00:42, 9 November 2017 (UTC)
    IANAL but it seems like a good idea to have Wikidata content doubly-licensed under CC-BY-SA and ODbL
    You can not legally relicense CC-BY-SA under ODBL without explicit agreement of each author. To be clear, I'm not hostile to ODBL nor any free license, although I would recommand non-copyleft licenses only in very specific cases, in which I would not include Wikidata as a whole. But I would argue that you just can't take a whole data set such as Wikipedia, parse it into every predicates that automation state of the art enable you to extract, and put the result under whichever license fit your own personal preferences. All the more when after that you propose to generate stubs for smallest Wikipedia, stubs which could be then be licensed under CC0 as they come from synthesis of CC0 data, isn't it? And in the same time, you can't directly translate an Wikipedia article, even a stub, and say the translation is CC0. But I'm also not a lawyer, hence the need of creating a report by experts of the field as a prior requirement for some points of the proposal.
    Also note that with this proposal, users which would like to do so, might indeed add ODBL as one of the license set under which they agree to release their works, and that massive import from ODBL sources could lie within Wikidata, but they would be flagged as such (as well as under other licenses if it does apply). Responsibility for mixing in synthetic ways a large set of data which are coming from misc. sources would be buried by the mixer.
    It's a win-win
    if you take the stance we should ignore the fact that certain jurisdictions uphold database rights, no ill will come from using our data.
    No it's not a win-win. It's a "I withdraw your license clauses which doesn't accommodate me by withdrawing the whole license" case. Those who licensed their work under CC-BY-SA virtually lose all their rights in the process. I said virtually, because until they are serious investigation done which prove it otherwise, this is just a plain illegal practice, and everybody who use this data are just building their works on highly doubtful legal ground.
    Please stop propagating the obviously fallacious "certain/some jurisdictions" offer monopoly on database. So far, the most official peace of claims made by the foundation regarding database rights states that their are indeed monopoly accorded on databases, based on misc. legal grounds, both in USA and Europe. Ok, that's not the whole world, but it's not just a few marginal cases. All the more the previous link doesn't say there is no monopoly on data in other countries, so until someone come a complete report on the state of the law on this topic, please assume that it is not legally safe to make as if there was issue. Plus the motto for our movement is "a world where every human have access to the sum of all knowledge, not those who have the luck to live in a favourable jurisdiction.
    • This seems more a policy issue, which probably doesn't really match the goals of community tech tasks. Shouldn't this be discussed within the Wikidata community first ? —TheDJ (talkcontribs) 07:54, 9 November 2017 (UTC)
    This seems more a policy issue, which probably doesn't really match the goals of community tech tasks.
    This is a policy issue, which do lead to technical needs to help its tracking and compliance. Of course the root requirement is not technical, I would not expect a single requirement to start from purely technical needs. Technical solutions are there to solve problems of our community, aren't they?
    The proposal make it clear that there are points which do have extra-technical requirements, but the dependency tree always finish with a leaf that is technical or have at least one technical dependency. Plus, once more, this is not a take or leave it all proposal.
    Shouldn't this be discussed within the Wikidata community first ?
    Wikidata doesn't impact only Wikidata, but all Wikimedia projects and even beyond as the Wikidata team is actively pushing exo-wikimedian reuse. So, of course Wikidata community is warmly welcome to discuss the topic, just as the rest of our community. Sure the discussion might have been conducted completely out of this technical wishlist, but since some possible technical requirements have already been identified, this just make plain sense to report it there, doesn't it?

    --Psychoslave (talk) 09:11, 9 November 2017 (UTC)

    Having the discussion at this place is a good way to have a discussion that won't affect policy as the technical wishlist as it's not within the powers of the Community Tech to affect policy.
    This is essentially about removing the feature that all of Wikidata is CC0 and the wishlist documentation says "One more note: Proposals that call for removing or disabling a feature that a WMF product team has worked on are outside of Community Tech's possible scope. They won't be in the voting phase."
    Saving that it's a win-win also ignores the fact that not having data in CC0 creates problems for Wikidata. To take one example, Quora couldn't easily exchange data with us if we would have a copyleft license. The same goes for other projects. ChristianKl (talk) 10:43, 9 November 2017 (UTC)
    the technical wishlist as it's not within the powers of the Community Tech to affect policy
    I agree, the technical community don't needs to establish policies (beyond its own right to discuss it as part of the community), if that is what you mean. Nevertheless it can provide tools which help to track respect of policy, whatever it happens to be.
    This is essentially about removing the feature that all of Wikidata is CC0 and the wishlist documentation says "One more note: Proposals that call for removing or disabling a feature that a WMF product team has worked on are outside of Community Tech's possible scope. They won't be in the voting phase."
    That's not a bug, it's a feature. Well, no, this is a serious issue that have to be resolved yet with serious investigations on the one hand, and it happens that on the other hand a technical feature might lower the heavily doubtful legal state of Wikidata items. All the more the feature requested might also serve to explicitly state that an item is under CC0, if that is not legally doubtful in view of the data source and the amount of data extracted from it that was imported within Wikidata. I'm not aware of any feature on this topic for which the WMF product team that would be removed by such an addition of feature. At worst it might require deletion of items whom provenance raises licensing doubts, but no such thing can be added in the database by the WMF product team as they surely respect that the foundation terms of use that they merely host the content, and that editorial control is in the hands of [contributors] who create and manage the content.
    Saving that it's a win-win also ignores the fact that not having data in CC0 creates problems for Wikidata. To take one example, Quora couldn't easily exchange data with us if we would have a copyleft license.
    You are making a wrong assumption if you take this proposal if you take for hypothesis that it tries to prevent any use of CC0 within Wikidata. If Quora did obtained from their users to publish all their works under a CC0, then we don't need any further permission to import that in Wikidata, and specifying a source with timestamps and specify it was published under CC0, then its fine. Or if they have or their user granted them a non-exclusive, transferable, sub-licensable, royalty-free, worldwide license to do whatever they want with their works, surely there is no problem with Quora including data under CC0 within Wikidata. But if the problem you mention is that with copyleft license Quora can't do whatever they want with the work of the Wikimedia community, then yeah, that's the intended goal of the copyleft license. Just like people are not legally allowed [upload random files from Commons on Facebook]. What you are talking about is all but win-win. So far, it looks more like Wikidata was transformed into a license laundering machine, gathering tremendous amount of data which is pretended usable under CC0 without providing any serious clue to ground that claim. The fact that Google founded half the sum of the initial project and that Denny Vrandečić which have been leader of the project and a fervent CC0 promoter now works on the Google Knowledge Graph which – with other sources – relies on Wikidata, is worrisome. Not because they use Wikidata community works, which is fine, and copyleft license allow that too. But because tomorrow they might just improve their own internal database, curated with custom non-free curation interface or simply through their sprawling worldwide tracking system of users who contribute in an unaware passive manner. And as they will have extracted all the value of Wikimedian CC-BY-SA projects through the Wikidata license laundering machine, our projects will be left as a hopeless hijacked victim, and our then invisible community will be dispelled as slaves in the realm of the all mighty for-profit tech giants. Well, sure, that's a grandiloquent way to paint a really dark dystopia picture. But, sadly, it's not a unrealistic scenario.
    So, really we shouldn't care much if Quora or anyone else out there might have difficulty to use Wikimedia works as a result of our movement knowledge equity commitments. If the price asked for some agreements is to approve inequity, then our movement must reject it.
    But for now, the main technical point of this proposal is not asking anything but to provide better license curation tools to our community. --Psychoslave (talk) 13:28, 9 November 2017 (UTC)
    Serving data under CC0 is allowing data users a maximum of freedom. This license choice allows Quora to participate by adding free data to our project. The statement says "We will break down the social, political, and technical barriers preventing people from accessing and contributing to free knowledge". Having Wikidata under a more restrictive license would be a barrier for some stakeholders to participate.
    Disagreeing with policy decisions is your right, but this isn't the forum where policy is supposed to be decided and pretending that this doesn't go against the decisions for the Wikidata project is ignoring the realities. ChristianKl (talk) 13:53, 9 November 2017 (UTC)
    Serving data under CC0 is allowing data users a maximum of freedom.
    But that's not the goal of Wikimedia movement. The goal is knowledge equity. We can promote freedom wherever it begins to confirm freedom of everybody, but beside this threshold freedom, that knowledge ought to canalise, is blind pulse with no safeguard against the worst behaviours that humans are apt to.
    This license choice allows Quora to participate by adding free data to our project.
    That wouldn't change with this proposal. If Quora do have the right and the will to add data under CC0 to Wikidata, this proposal will let this possibility intact.
    Having Wikidata under a more restrictive license would be a barrier for some stakeholders to participate.
    The proposal wouldn't prevent what you described. Plus the converse of your statement is also true: having a less restrictive license can also be a repulsive barrier for those willing to contribute, but only within a fair mutual equal right beside works that will be derivative from their contributions.
    Admittedly, I fail to read "We will break down the social, political, and technical barriers preventing people from accessing and contributing to free knowledge" as "we will encourage individual to withdraw all rights that civil societies ever granted them so that for-profit corporation can exploit freely their works, being assure that they would have no legal duty if they ever arrived at a winner-take-it-all economical monopoly position". If you want to insist more on the case of Quora, I would ask you to provide more information about what do they give, what do they take, who created what they give (benevolent or paid editors?), under which condition (license, EULA) this work have been created, and how Wikidata is used by Quora if it is in any way (do they credit their sources?).
    All the more, if they can release under CC0, then they can release it under a copyleft license, so there is no legal mandatory reasons to refuse to do so if where interested in an equitable cooperation, istn't it? --Psychoslave (talk) 14:37, 9 November 2017 (UTC)
    Example needed
      Oppose adding a license field. Wikidata is CC-0 licensed and it should remain that way. Anybody addding data should be aware of that. If there has been a copyright violation, the copyright owner can request the associated data to be removed; of course we can also be proactive in such cases if we become aware of them. Have we had any example of such a request? Can you envision a specific case where it would happen? Why wouldn't it be handled the same way copy vio's are handled in wikipedia and Commons? I don't see any need to change the licensing in wikidata itself. ArthurPSmith (talk) 13:26, 9 November 2017 (UTC)
    Wikidata is CC-0 licensed and it should remain that way.
    Wikidata pretends it can re-license anything under CC0 regardless of the legal status of the source and the amount of extracted data from it. That's really different. It's more like if I pretended that since I only send you a sequence of bytes which, taken alone, represent a at best some random integer, that the fact that the whole file you built with this signal happen to be a perfect copy of the last Hollywood blockbuster blue ray makes you legally free to do whatever you want with this file, like dealing with partners. However database comes with additional special legal information monopoly which vary between countries, that's basically a good analogy for the approach that so far Wikidata took regarding licensing issues.
    If there has been a copyright violation, the copyright owner can request the associated data to be removed; of course we can also be proactive in such cases if we become aware of them.
    Or we can be proactive in just respecting licenses traceability and let end user take the responsibility to mix them in synthesis works, or to filter data by compatible licenses.
    Can you envision a specific case where it would happen?
    Well, just as many cases as there was performance of massive data import which didn't compelled with the source term of use. So far, as far as I know, misc. Wikipedia versions are among the main source provider, so it makes a lot of contributor potentially able to sue for license violation. That doesn't mean this would necessarily lead to a condemnation. I just don't know, really. That's why I said it's a doubtful legal status, and not a clearly illegal practise.
    Why wouldn't it be handled the same way copy vio's are handled in wikipedia and Commons?
    Because Wikidata is designed for scalability through automation, not only legal issues are also scaled, but without a proper tracking system, it will be difficult to analyse what data are impacted by a given legal issue.
    I don't see any need to change the licensing in wikidata itself.
    I hope my answers might enlighten somewhat. --Psychoslave (talk) 13:56, 9 November 2017 (UTC)
    if the issue is copyright on large-scale collections of data and not individual facts, then adding a license field on individual statements cannot help. Perhaps this issue needs to feed into bot approvals and could be associated with some sort of tagging of large-scale collections of bot edits. Putting a license field on statements is definitely the wrong approach here. ArthurPSmith (talk) 15:29, 9 November 2017 (UTC)
    How this would not help when this would result in copyleft license compliance? This is indeed a tagging of large-scale collection import, whether through bots or crowdsourcing, with each item keeping a tags for licenses (and matching references), if you want to name it this way. The result is that one might select items which are available under a given license. --Psychoslave (talk) 21:37, 9 November 2017 (UTC)
    It's not true that Wikidata says that any data can be imported. On the other hand, facts aren't copyrighted. When the American Chemical Association told Wikipedia a decade ago that they aren't happy with Wikipedia to store their CAS numbers, Wikipedia position was that CAS numbers are facts and can be freely shared even if the ACA didn't like it. WikiCommons made decisions like hosting the monkey-selfie to assert a permissive interpretation of copyright. Wikimedia's position was never to stay aware from the grey-zone of copyright as that removes the abilities of us to do what we do but it's rather to fight the lawsuit for the monkey-selfie.
    Having the view that facts are copyrighted wouldn't only make it more complex to import from Wikipedia but also to import from elsewhere. ChristianKl (talk) 15:52, 9 November 2017 (UTC)
    Recently, a person on our project chat asked whether he can contribute data about when software was released. He used our data on software release data as input for a machine learning product. Given that our data about software release dates isn't complete, he pays people to complete the data and is willing to give that data back. This is the kind of commercial project that benefits from Wikidata. If we had a license that would force him to relicense everything his machine learning algorithm produces as CC-BY-SA, he probably wouldn't build on our dataset.
    Just like corporations rather use Apache licensed libraries and contribute back to them then doing the same thing with GPL, it's easier to work with more freely licensed data. ChristianKl (talk) 15:53, 9 November 2017 (UTC)
    Given the rules of share-alike combining multiple share-alike licenses that aren't compatible in one project of linked data as you propose might also create it's own legal risks. ChristianKl (talk) 16:06, 9 November 2017 (UTC)
    It's not true that Wikidata says that any data can be imported.
    I don't think I said otherwise, and of course I hope you can't import the indefinite stream of bytes that generate your local /dev/urandom stating that your personal computer generated this peace of bytes at some timestamp, which would be factual but completely useless as far as I can imagine.
    On the other hand, facts aren't copyrighted.
    This is just a too fuzzy statement to have any relevancy. At large, this is just plain false, as to retake the Harry Potter example, you can't enumerate the complete list of words and their ordinal occurrence positions that appear in the saga. Yes, this would be a lot of factual data, and as they provide enough data to rebuild to whole work, this would be just plain hold copyright violation. The same is true with Wikipedia articles. Imagine you can automatically generate a whole article on a linguistic Wikipedia which doesn't cover the subject yet thanks to data stored in Wikidata which were extracted from an other Wikipedia. We are not yet there, but there are already stubs which are created that way, according to what I red somewhere. Now, imagine that enough information was extracted from the article and that the generator is so efficient that the result is equivalent with a direct translation. If you believe Wikidata claim about its license laundering ability "because it's only facts", then you could publish this synthetic article under CC0. But a direct translation would require CC-BY-SA. Even better, imagine your generator actually generate the article within the same language as the single original article from which all related data were extracted from, with a 100% match between the original and the synthetic. Ta ta, this generated article is now CC0, so is the original one, according to Wikidata claim that factual data can't have copyright issue at any scale. Clearly there is a problem. Sure with predicates stored in Wikidata, such a 100% matching will be more difficult to obtain than with an enumeration of factual statement about ordinals where a word appears in a text, but conceptually the problem is exactly the same.
    Wikimedia's position was never to stay aware from the grey-zone of copyright as that removes the abilities of us to do what we do but it's rather to fight the lawsuit for the monkey-selfie.
    Well, I like this attitude. But right now, we are in the purest grey grey-zone. I would be fine with a Wikipedia vs Wikidata case with WMF as both complainant and defendant (if such a thing is possible). That would minimize the risk and make it clear whether license laundering through the factual data argument is legally receivable and at which scale. Until we do have such certainty, then we should just respect the licenses of source works.
    Having the view that facts are copyrighted wouldn't only make it more complex to import from Wikipedia but also to import from elsewhere.
    Sure, law is always cumbersome when it stands in our way. But making as it doesn't exist where it annoy us don't make it vanish. Also you seems to continuously confuse facts, data carrying statements about facts and large aggregation of that kind of data. That might be OK in casual conversation, but for such a topic, please avoid to mix everything up.
    Recently, a person on our project chat asked whether he can contribute data about when software was released. He used our data on software release data as input for a machine learning product. Given that our data about software release dates isn't complete, he pays people to complete the data and is willing to give that data back. This is the kind of commercial project that benefits from Wikidata. If we had a license that would force him to relicense everything his machine learning algorithm produces as CC-BY-SA, he probably wouldn't build on our dataset.
    Well, first I don't plaid for forbidding CC0 in Wikidata, although I do plaid for a default set of license which only include copyleft licenses. If there are users who do want to withdraw every single right they have on their work when they have other options, that's fine. But forcing people to contribute under such a license when all other Wikimedia project where Wikimedians have grown their communities use copyleft license or at least let the user choice.
    Now, back to your example, I just don't care to release my work under licenses that are not practical for people who are not willing to play equitably and publish back under the same conditions. Either they would have comply with CC-BY-SA, or they would have search an other solution, both being far better than to see them using a free work to create derivatives and publish the result as a non-free work. Actually to me your example means that we missed a possible occasion to foster free works, so it's an example against non-copyleft license.
    But once more, it's OK to let people publish under CC0 if they really want to do so. But making it mandatory to contribute to Wikidata is not OK, as it would be unacceptable to have a mandatory CC0 on Commons or all Wikimedia projects. All the more, mass import of non-CC0 material while nothing proved it's legal is clearly an issue which should be solved.

    --Psychoslave (talk) 22:54, 9 November 2017 (UTC)

    • CC-0 is fine for Wikidata. Facts can't have a copyright, and I am against a copyright for a collection of facts. --Yann (talk) 15:23, 9 November 2017 (UTC)
      • Maybe you mean that you feel fine with CC0 for Wikidata. It doesn't mean it is legally fine to make massive import of non-CC0 sources within a CC0 database. The same apply regarding copyright and factual data collection, a personal mood is not a law. Here are some facts: The first word of the w:Wikimedia article is The, the second is Wikimedia, the third is movement, and I could factually enumerate each word within this article. Enumerating a few words and their respective positions in the text doesn't raise any legal problem. Enumerating a large part of them, or all them, does raise legal concerns. Actually it's plain old copyright violation. Otherwise circumventing any information monopoly would be trivial, and related laws would be pointless. While I do personally think that no monopoly should ever be granted on any kind of information, this is my personal opinion which unfortunately doesn't match legal reality. I don't publish Harry Potter saga in Wikisource, nor a factual position of each word occurrence used in Harry Potter within Wikidata because I think it would be illegal, not because I think that law is fine or that this works and fact are culturally worthless. Therefore, as long as they are law which grant monopoly on information and that it's unclear to which degree they impact a database who aims at gathering facts, it would be more careful to track finely sources of statements and their licenses. Wikimedia is not sci-hub, we follow the path of legality, whatever our personal feelings are about this laws. --Psychoslave (talk) 20:31, 9 November 2017 (UTC)
    • This is not a community issue. It is up to the WMF legal team to decide if they are happy with the possible liability of licensing bulk copyrighted data under CC-0. The variation by jurisdiction is immense, and I am taking the view that although in some instances we are probably causing a copyright violation, this is not a major issue, and the WMF and partners are perfectly able to deal with any possible lawsuits that result from it. I assume it will be reasonably possible to remove any datasets that are litigated if and when, given that this is structured data, and the database owner could simply run a search query to ascertain the affected items in any given dispute. In short, if it ain't broke, don't fix it. A Den Jentyl Ettien Avel Dysklyver (talk) 16:13, 9 November 2017 (UTC)
    This is not a community issue.
    Please provide a method to decide what is a community issue according to you. Here is my own proposal: 1. a person have concerns that according to this same person have an impact on the community. 2. this person report the said concerns 3. the community decide whether a. it doesn't care, b. share this concerns or c. explain why this concerns are mere delusions supported with a large rejection consensus indicating that the community find the problem is irrelevant. I don't feel like we are nowhere near 3.c so far, so I will take you claim that this is not an issue as an indicator for such a decision process, but not a conclusive fact, even in bold character.
    It is up to the WMF legal team to decide if they are happy with the possible liability of licensing bulk copyrighted data under CC-0.
    My opinion is that the Foundation is is accountable to the community. So they are not free to experiment whatever might be the fancy of the day at the expanse of putting the community sustainability at risk and certainly not without a clear transparent report which evaluate this risks. Assume good faith is fine, and trust balanced with known past behaviour is OK. But blind trust is misguided, don't blind trust the foundation, me or even yourself: keep your mind open to critiques from and toward everybody. But avoid paranoia (even if we indeed have a worldwide secret evil plan against you, mouhahaha).


    I assume it will be reasonably possible to remove any datasets that are litigated if and when, given that this is structured data, and the database owner could simply run a search query to ascertain the affected items in any given dispute.
    A goal of this is proposal is to ease that kind of solving and even prevent this kind of litigation. However it doesn't go as far as systematic deletion of all problematic material under the current lack of license tracking system.
    In short, if it ain't broke, don't fix it.
    Yeah, so, my opinion is that the current state of Wikidata is broken. The license problem apart, it didn't hold its promise of avoiding circular dependencies with Wikipedia references. This is an other related problem of source tracking laxity. Denying the broken state won't change the fact that it's here.

    --Psychoslave (talk) 21:26, 9 November 2017 (UTC)

    ArchivedEdit

    This proposal is primarily about changing the licensing policy and while it includes some development work, we can't start this work before there is agreement that licensing should change. This is a technical survey and thus it's not suitable for policy discussions. I suggest you to start a discussion on Wikidata because until the community is on board , this is not happening. Considering all of the above, I've archived this proposal. Thanks for participating in our survey! Max Semenik (talk) 23:56, 9 November 2017 (UTC)

    Well @MaxSem:, I'm a bit disappointed of course, but I prefer to concentrate on constructive actions rather than complaining. So your suggestion to put the community as a whole on board, not on Wikidata alone because this is a problem which impact the whole Wikimedia ecosystem. What are the proper processes to engage the whole community about a topic with such a large impact on its future for a mere contributor like me? --Psychoslave (talk) 09:05, 10 November 2017 (UTC)
    Wikimedia has decentralized decision making. Apart from the movement strategy discussion, there's no venue for whole community discussions. ChristianKl (talk) 21:05, 10 November 2017 (UTC)

    Better readership statistics

     N Outside the scope of Community Tech. The good news is per below, the Analytics team has some plans to implement similar statistics in the future.

    • Problem: There's only one pageview statistics tool (that I know of) which only tells the number of pageviews per day for a given article; it is a simple tool that does not differentiate readers from viewers. I think there is a need for more and better data, such as (1) whether an article is simply clicked on but not scrolled (ie not read much) or read with scrolling (2) how many minutes on average an article is read (3) which subsections get read (4) where the eyeball traffic comes from (for example, whether from other Wikipedia articles, or from the web) (5) whether the pageviews were unique readers or the same readers reading multiple times.
    • Who would benefit: The community will benefit if we can learn more about how we're serving readers. Better data will help us focus on specific articles, knowing which to improve and so forth. If there was an indicator of how many unique readers that a specific contributor has -- over time -- then it could encourage contributors to earn more readers by quantifying their contributions.
    • Proposed solution: I am not technical enough to offer specific solutions but there are talented programmers here who can.
    • More comments: Note: if there is such data already available but I just don't know about it, I apologize in advance, but to my knowledge, it doesn't yet exist.
    • Phabricator tickets:

    Community discussionEdit

    • I don't think wikipedia uses Google analytics :) good idea, but we could end up revealing more than we want people to see abut our actual readership. A Den Jentyl Ettien Avel Dysklyver (talk) 16:34, 9 November 2017 (UTC)
    • I helped author Pageviews Analysis, which I think is what you're talking about. I will try to answer your concerns but note that I am not on the Analytics team, nor can I give any official word regarding privacy policy.
      With pageviews, referral information (where traffic comes from) is being stored, along with some other data, but this is all intentionally considered private and is not exposed to the public. I agree more detailed statistics could offer some great benefits, but the general notion is that privacy will be compromised, and that is given priority. I can think of some examples, but I will leave that to the privacy experts. Similarly, data on unique devices are not publicly available, except on a per-project basis. For that, check out Siteviews.
      At any rate, changing the availability of these statistics is not a job for Community Tech. If you would like to learn more, you could try reaching out to the Analytics team directly. They will be able to give you better answers than me, but again I am doubtful such private information will become publicly available, and it should be noted special requests for the data are rarely granted.
      Given this is not in our purview or within our control, I'm going to have to archive this proposal. We very much appreciate your participation in the survey, and I am sorry we cannot help any further! MusikAnimal (WMF) (talk) 01:36, 10 November 2017 (UTC)
      • Well I suppose thank you is in order for at least responding to my request. I have been a significant contributor to Wikipedia, since 2009, writing and revamping hundreds of articles, and with my contributions of images (over 1000), a metric of how well I am doing here, the only metric that I have, is pageviews, and my guess is that they add, over time, to over 200 million pageviews. That is, the idea that people are reading my contributions motivates me and I bet it motivates other contributors too. I continue to think that my request for improved readership statistics is valid, that they would indeed help the encyclopedia by motivating contributors, as well as providing clues about where best to focus our energies (eg substandard wiki-articles with significant readership). My sense is that it is surely possible to provide better readership statistics while preserving privacy, such as by revealing only aggregate numbers or averages, and not reporting numbers if they fall below a certain threshold, say 30 views. So I believe that tabling my proposal is premature and I suggest that you reinstall it.--Tomwsulcer (talk) 10:28, 10 November 2017 (UTC)--Tomwsulcer.--Tomwsulcer (talk) 10:36, 10 November 2017 (UTC)
        • I agree! I just don't think Community Tech can do anything about it. It might be nice to still leave this proposal up during the voting phase, just to see how many people are on board with the idea. I will discuss this with my team. We have a lot of time (until November 27) so do not worry, your proposal is not losing momentum here in the archives :) I'll get back to you soon! MusikAnimal (WMF) (talk) 20:26, 10 November 2017 (UTC)
          • Ok, thanks again for responding, and if it is or becomes feasible to somehow get better readership statistics, while protecting privacy using aggregate numbers, I think we'd all be better off.--Tomwsulcer (talk) 14:26, 13 November 2017 (UTC)
            • Hi Tomwsulcer, I'm Dan Andreescu and I work for the Wikimedia Analytics team. We do have plans to work on some of the statistics you request here, and the results of that work will come out over the next year and beyond. We can get around some of the privacy problems by tricks that include the ones you mentioned (discard buckets that are too small, separate out statistics so they can't be used together to de-anonymize private information, etc.). We have some bigger commitments that we have to finish up through the spring, but after that I personally intend to focus on projects like WikiCredit. This begins to try and deliver to each user statistics that are relevant and rewarding, hopefully. I would suggest you send your request to our mailing list so everyone can see that community members value this kind of work. Milimetric (WMF) (talk) 18:14, 13 November 2017 (UTC)

    Add an undo/revert button to diff view

    • Problem: The mobile web diff view features an enormous 'thank' button at the bottom of the screen. Sadly, I find myself reverting people far more often than I thank them. Quickly reverting a dodgy edit is the sort of quick editing that should work well on mobile. Unfortunately, the mobile interface makes this all but impossible without manually rewriting the text.
    • Who would benefit: Editors checking their watchlist on their phones.
    • Proposed solution: Provide an undo button adjacent to the thank button. Undoing an edit would work the same way as on the desktop site - open the editing interface with the offending text removed from the source.
    • More comments:

    DiscussionEdit

    Endorse --BugWarp (talk) 13:16, 10 November 2017 (UTC)

    VotingEdit

    → link to page section is hard to click

      Withdrawn by proposer [1] (too many proposals)

    • Problem:

    "→" link to page section on History page, Watchlist page or RC page is too small and it can be really hard to click.

    • Who would benefit:

    Every user who wants to go to a specific section from History page, Watchlist page or RC page

    • Proposed solution:

    Make the link bigger, apply the link to the whole section title there, whatever...

    • More comments:
    • Phabricator tickets:

    T165189

    Community discussionEdit

    Allow Gender magic word in other namespaces

      Withdrawn by proposer [2] (too many proposals)

    • Problem:

    In some languages (e.g. Czech, Slovak, Polish) there is a different grammar for male and female (for example in case of "You could"/"You should"). In Help namespace there is a tendence to be user-friendly and this magic word would help there.

    • Who would benefit:

    Novice users on Czech, Slovak, Polish, ... projects

    • Proposed solution:
    • More comments:
    • Phabricator tickets:

    T137717

    DiscussionEdit

    A vertical reading-mode for Classical Chinese.

      Duplicate proposal of 2017 Community Wishlist Survey/Miscellaneous/Vertical writing support

    • Problem: Classical Chinese 🏛 Wikipedia is currently written horizontally reading from left-to-right, and then up-to-down, this isn't how any actual Classical Chinese text is written, and there certainly is the technical capability to make this script written in “the correct order”.
    • Who would benefit: People who get irritated by the fact that Classical Chinese Wikipedia 🏛 isn't written like actual Classical Chinese texts. 🧐
    • Proposed solution: Create an optional mode for the Classical Chinese Wikipedia 🏛 to be read in the traditional-style of vertical writing with characters going from up-to-down, and then from right-to-left. I think 🤔 that this should also be applied to mentions of Latin script, Cyrillic script, Greek script, Devanagari script, Etc. included within the Classical Chinese Wikipedia 🏛.
    • More comments:
    • Phabricator tickets:

    DiscussionEdit

    Section edit for VisualEditor

      Request withdrawn

    • Problem: VisualEditor currently requires an entire page to be parsed in editing mode. This makes editing long pages difficult.
    • Who would benefit: Everybody.
    • Proposed solution: Allow section edits on VisualEditor. Only the chosen section is loaded, on a separate screen (just like the Wikitext "edit section" behaviour).
    • More comments: It doesn't matter that the page isn't parsed exactly, because editors are generally aware that clicking "edit section" means that the preview is limited to the section that they're editing anyway and some changes will affect the rest of the page in ways that only become obvious after saving. This hasn't deterred people from using "edit section" on Wikitext mode and shouldn't deter people from using "edit section" on VisualEditor mode. But the additional performance requirements on loading an entire page onto VisualEditor is making the editing of long pages very difficult.
    • Proposer: Deryck C. 22:19, 9 November 2017 (UTC)

    DiscussionEdit

    • Withdrawn - Sorry for not reading the rules properly. Deryck C. 22:33, 10 November 2017 (UTC)
      No problem, and sorry if this rule was not clear enough! MusikAnimal (WMF) (talk) 23:23, 10 November 2017 (UTC)

    Make all forms of Unicode available on all Wikimedia projects.

      Withdrawn by proposer (too many proposals)

    • Problem: Currently I am drafting an article that deals with the Qing Dynasty (the Manchu Empire) which uses a great deal of Manchu script, if I were editing on a wiki where I could use the template {{ManchuSibeUnicode|ᠠᠪᡴᠠᡳ<br>ᡶᡠᠯᡳᠩᡤᠠ<br>ᡥᠠᠨ<br>ᠵᡳᡴᠠ}} however there is no local {{MantsjoeXibeUnicode|}} template on Dutch Wikipedia, for articles relating to the Qing Dynasty, being able to use the vertically written Manchu script is paramount. This problem also extends to other wiki's as not all of them have volunteers willing to invest their times in writing these templates.
    • Who would benefit: Everyone. 🤳🏻
    • Proposed solution: Make Unicode templates universal among all Wikimedia projects, and allow all forms of Unicode input 🔢 to work. 🐱‍💻
    • More comments:
    • Phabricator tickets:

    DiscussionEdit

    All forms of Unicode do work, assuming the browser has appropriate fonts to render them. These templates override the default font stack with alternatives that may exist on Windows and Macs, and sometimes provide additional CSS. Anomie (talk) 15:09, 9 November 2017 (UTC)

    The functional part of templates like this can be copied verbatim, the time-consuming part is translating the documentation. Having "universal" templates would make some aspects a little easier. --bdijkstra (talk) 21:21, 9 November 2017 (UTC)

    @Donald Trung: Please note that you are only allowed three proposals maximum. This was mentioned in the survey rules. You need to withdraw your rest. -- NKohli (WMF) (talk) 19:39, 10 November 2017 (UTC)

    Allow IP editors to see talk pages in the mobile browser.

      Withdrawn by proposer (too many proposals)

    • Problem: Currently if you edit as an IP-user on a mobile device using the mobile browser you don’t see the button 🔘 “Talk” (or “Overleg”, Etc.) anywhere, if you wish 🌠 to access the talk page you have to manually switch to “desktop” mode, then click on “discussion” and then switch back to mobile 📱. But even then you can’t edit the whole page in “Mobile” mode, only individual sections.
    • Who would benefit: Mobile-users 👥.
    • Proposed solution: Allow mobile IP-users to see the talk page button, there’s literally no need to only restricting this to named accounts.
    • More comments:
    • Phabricator tickets:

    DiscussionEdit

    • I support this. More broadly, access to the talk page should be far more prominent, it's a central vital aspect of our projects. I stopped to use the native app on my mobile because I never found an obvious way to do that. Access talk page should be everywhere (contextual menu, at top and bottom of article, at the beginning of each section and engraved in bold character within the telephone case) rather than nowhere. --Psychoslave (talk) 11:39, 9 November 2017 (UTC)

    Allow mobile editors to edit entire pages (optional)

      Withdrawn by proposer (too many proposals)

    • Problem: Currently if you edit in the mobile browser (like myself) you will run into numerous restrictions on editing that make it a more tedious task, one of these editing restrictions is the inability to edit full articles, imagine if you need to move one paragraph from one part of the article to another, the scenario goes like this: A mobile user wants to move something into a more relevant section of the article, but because of technical restrictions they have to blank one part first or move it in an impractical manner before being able to add it properly, they explain that they only need 6 (six) minutes to finish “the next” edit or maybe one (1), they then try to “finish” the second edit and click on “save 💾” but find an error message, a rollbacker has already reverted claiming it as vandalism and left a pesky template accusing the mobile 📱 editor of vandalising a page they’re a major contributor to. This should be preventable.
    • Who would benefit: Mobile-users 👥.
    • Proposed solution: Allow an option when one clicks on “the top pencil ✏” that says “edit section or edit whole article”, this way (mobile-)users can choose between either simply editing the intro exclusively or editing the entire page without having to go to “desktop” mode.
    • More comments: Otherwise allow for “intermediate edits”, seriously when you’re on mobile “assume bad faith” (see w:en:WP:BADFAITH) is the only way rollbackers can communicate with you, I wouldn't be surprised if almost every user that hated editing did so because they’re on a mobile device, and their intermediate edits were seen as “vandalism”.
    • Phabricator tickets:

    DiscussionEdit

    • Strongly endorse. Main reason I don't edit on mobile. I often myself in the same position as the proposer, with the added commentary that "ref names" are unhelpful in the mobile view, as it's not possible to see where else the reference is used in the article without having access to the full page. LocalNet (talk) 22:58, 10 November 2017 (UTC)

    A mobile UploadWizard for Wikimedia Commons.

      Withdrawn by proposer (too many proposals)

    • Problem: The current Wikimedia Commons UploadWizard is very Mobile 📱 unfriendly, and it always directs people to the desktop version to upload their files, if like me you’re (currently) unable to use an application 🈸 for Wikimedia Commons then you have to resort to use the Wikimedia Commons UploadWizard which can be a real pain in the neck if you use a small screen.
    • Who would benefit: Mobile-users 👥. And of course everyone else as their would be more educational photographs to use. 😉
    • Proposed solution: Create a mobile-version of the Wikimedia Commons UploadWizard. It would basically look and act identical to the current Wikimedia Commons UploadWizard but then adapted for smaller screens.
    • More comments: I don’t really think 🤔 that there's much to say here, just make an optional mobile UploadWizard, if someone doubts that this is a problem then I would advise them to take a wireless telephone 📞, and attempt to use the Wikimedia Commons UploadWizard for 10 (ten) photographs, share your results. 🤭
    • Phabricator tickets:

    DiscussionEdit

    Endorse. The app should be more user friendly, allow external sources uploads and allow more licenses than it currently does.--BugWarp (talk) 13:16, 10 November 2017 (UTC)

    VisualEditor summary autocomplete

      Withdrawn by proposer [3] (too many proposals)

    • Problem:

    In Wikitext editor there is a summary filed there automatically drops down/up an autocomplete/suggestion field with some possibilities. But in VE there is no such autocomplete option.

    • Who would benefit:

    All VE users

    • Proposed solution:

    Add some dropdown under or over VE summary field with some suggestions and autocompleted values

    • More comments:
    • Phabricator tickets:

    T50274

    DiscussionEdit

    Improve FastCCI capabilities and performance

      Withdrawn by proposer (too many proposals)

    • Who would benefit: Users who would otherwise create a combinatorical explosion of intersection categories.
    • Proposed solution: Enable FastCCI to perform that kind of intersection quickly and reliably. (It currently times out on sufficiently large categories.) Enable permalinks to the results, and possibly cache them on the server side. Enable the ability to do 'shallow' unions and intersections, i.e., ones that don't include files in descendant categories.
    • More comments:
    • Phabricator tickets:

    DiscussionEdit

    • I would also very much like to see significantly better search capabilities on commons - fuzzy search, boolean operators, order by filesize, megapixels and other metrics - say, popularity - would all be extremely helpful. Instead of adding this to fastCCI, is this stuff not a question of Commons' "search" capabilities? Might be better to propose it there -- Thennicke (talk) 10:29, 10 November 2017 (UTC)
      • @Thennicke: I jumped the gun here--I'd like there to be better category intersection/exploration options, but they don't have to go through FastCCI specifically. I figured 'Multimedia and Commons' is a good place for it, but I can kinda-duplicate the request under 'Search', if you think that's a good idea. Grendelkhan (talk) 23:05, 10 November 2017 (UTC)
        • Up to you; it was only a suggestion. I suppose it doesn't really matter which section it's in because it's mainly commons related, but the heading suggests that this is only about FastCCI, which I would suggest changing to say "search" in general. Thanks :) -- Thennicke (talk) 02:28, 11 November 2017 (UTC)

    New tag for notes

      Withdrawn by proposer (too many proposals)

    • Problem:

    Cannot edit notes in VE.

    • Who would benefit:

    All editors, who love VE

    • Proposed solution: introduce new tag, which will be supported by VE
    • More comments: I was told the integration of notes is a problem, because the use same tag as references. This may overstep the problem.
    • Phabricator tickets:

    DiscussionEdit

    @Juandev: Please describe what "notes" are or provide an example, and explain which "same tag" is used, so we can make sure that we discuss the same thing. Thanks! --AKlapper (WMF) (talk) 20:42, 8 November 2017 (UTC)
    This is an example of notes.--Juandev (talk) 21:04, 8 November 2017 (UTC)
    @Juandev: It is already possible, notes are using ref tags with groups, like <ref group="notes">...</ref> :
    1. edit a page using VE
    2. insert a reflist ("Seznam referencí")
    3. in that reflist, on the "use this group" ("Použít tuto skupinu") field, type a group name (like "notes" or "Poznámky")
    4. somewhere in the text, insert a note
    5. when inserting the note, using the basic form ("Základní podoba")
    6. there is a field where you can now choose "notes" or "Poznámky".
    Hope this helps! Trizek (WMF) (talk) 09:42, 9 November 2017 (UTC)
    Umm, but than it needs to be tuned. If I edit the page, which allready had some notes (which were not created this way) I cannot edit them easily (because, they have different parametr).--Juandev (talk) 20:33, 9 November 2017 (UTC)

    Preview page without reloading

      Already done. This feature is available as a preference ("Show previous without reloading the page").

    • Problem:
      • The use of "Show preview" and "Show changes" needs to load the page
    • Who would benefit:
      • All
    • Proposed solution:
      • Make these buttons running on the same page without reloading the page (.i.e. the ability to see changes at any moment during editing without reloading the page)
      • The possibility of using both together
    • More comments:
    • Phabricator tickets:

    DiscussionEdit

    • It is already an option, go to your (preferably local) Preferences, section ‘Editing’, check ‘Show previous without reloading the page’ checkbox. stjn[ru] 15:24, 11 November 2017 (UTC)
    • Per above, I'm going to archive this proposal. Thanks for your participation MusikAnimal (WMF) (talk) 04:18, 13 November 2017 (UTC)

    Correct the sexism and unconstitutionality of Wikipedia with respect to the german constitution (Grundgesetz)

     N Poses legal question rather than a technical feature

    • Problem: Until recently the german constitution said, that every person born in germany has to be registered as male, female or without a gender entry. This is refelected by the wikipedia preferences options "Address me es he/she/(dont use an attribution). German Bundesverfassungsgericht has recently decided, that people who are nether male nor female have a right to be registered as belonging to a third gender (the name of which is left to the parliament to decide). The court gave a time frame of end of 2018 to change the law to this respect. With this change taking place the preferences options in wikipedia will be consdidered as an uncontitutional sexism in germany. wikipedia may be sued and sanctioned for this.
    • Who would benefit: german wikipedia users
    • Proposed solution: add another option in the preferences (the name of which will be decided later)
    • More comments:
    • Phabricator tickets:
    • Proposer: 88.128.80.190 08:45, 13 November 2017 (UTC) (whichever)

    DiscussionEdit

    • I note that the 3rd option is not "Don't use an attribution", but is "use gender neutral where possible". —TheDJ (talkcontribs) 10:15, 13 November 2017 (UTC)
    • Also note that we don't ask you to register your gender, but which gender form you would prefer to be used for the translations/language. The option is part of the "Internationalisation"-options, not the "Basic information" section of your user profile. —TheDJ (talkcontribs) 10:18, 13 November 2017 (UTC)

    This is an interesting question, and one that people at the WMF should learn and think about. I don't think that this is appropriate for the Wishlist Survey -- if this is a legal question, then folks in the legal department should determine what the appropriate response is. I'm going to put this proposal in the archive. We've let Legal know about the question. Thanks for participating in the survey. -- DannyH (WMF) (talk) 18:20, 13 November 2017 (UTC)

    Linksto should be case-insensitive in the first character

      Done Completed while the survey was underway.

    • Problem: When using "linksto" with a title beginning with a lowercase letter on a wiki with $wgCapitalLinks set to true, no results appear at all.
    • Who would benefit: Users who want to find links as an alternative to WhatLinksHere, but do not want to force the first letter to be capitalized.
    • Proposed solution: The "linksto" keyword should behave the same as the other keywords. This means that "linksto:foo" (with an initial lowercase letter) should return the same results as "linksto:Foo" (with an initial uppercase letter).
    • More comments:
    • Phabricator tickets:

    DiscussionEdit

    Could you add an example (link) where this is currently being used ? —TheDJ (talkcontribs) 00:03, 10 November 2017 (UTC)

    @TheDJ: Go to en:Special:Search/linksto:main Page and you'll see what I mean here. A proposed solution is at https://phabricator.wikimedia.org/rMW8c9fc89ce3d7e0b5064981623dab7fde770af4b2. GeoffreyT2000 (talk) 15:35, 11 November 2017 (UTC)
    Since the above patch has been merged, this wish is resolved. Max Semenik (talk) 19:18, 13 November 2017 (UTC)

    Improve TemplateData to ease description of lexical items

      Withdrawn by proposer [4]

    • Problem: Currently editing a Wiktionary article is difficult for new comers, as the structure of article is often rigid and heavily rely on many templates.
    • Who would benefit: Every contributor willing to change an article on a Wiktionary without having to cross a difficult learning curve or the need to often probe the documentation to remember how things are supposed to be wrote. Also, while suggestion made here are proposed with a clear goal, many other projects would probably benefit from this. Although, this result would not be expected as a direct result of the proposed solution, every Wiktionary version remaining free to use whatever they prefer, but at least it would make it possible.
    • Proposed solution: There is already a current work in progress attempt on the French Wiktionary to gather every data related to the same lexical item into a single template. So far it relies on a Scribunto module and a template using TemplateData. But TemplateData have currently several caveats which makes it far less practice:
      • there is no way to limit an entry to a given set, ever static or dynamic
        • a static list should not be that much difficult to implement, rendered as a dropdown list in the template edit popup
        • a dynamic list would be probably more difficult, but extremely useful
          • to avoid duplicate information like list of supported languages and their corresponding ISO code, which are already in a Scribunto module
          • even based on static list, it's interesting to be able to filter some entries, for example grammatical gender and number sets vary from one language to an other, once the user chose a language, only the relevant cases should be proposed
      • each field can be associated with a short descriptive help, but wikicode included in it won't be parsed, so it's impossible to add internal link to a documentation page covering the subject in depth
      • as far as the current above mentioned attempt goes, the template pop up editor of the visual editor is slow and don't display anything during loading, giving the impression that the page crashed or that nothing is happening
      • there is no way to properly manage numbered list, both intertwined and flat numbered list. For example definition.1.1.description might be used for describing the first subdefinition of the first definition. So far TemplateData require to explicit every single numbered parameter, so no generic parameter can be created to make a template scalable.
      • Improve VE editor for intertwinned templates. So far only the first level templates are editable with the TemplateData, templates which are called in template parameters are displayed as wikitext in each parameter value, with no way to deepen edition with new modals.
    • More comments:

    Community discussionEdit

    Marking the pages as a "in progress" and users as "exist"

      Withdrawn by proposer (too many proposals)

    • Problem:
      • Edit conflicts
      • Any page in any project may need some time to work on.e.g:Page needs a lot of time to complete, or to respond to requests Page
      • Any user can be a existing (can read and reply to messages) or not
    • Who would benefit:
      • All
    • Proposed solution:
      • Marking:
        • the pages as a "in progress" (I think that Commons is the most site needs to this because the large number of deletions and speedy deletion requests)
        • the users as "exist":to know the user state (I think that Commons is the most site needs to this because of the warnings about the violation images)
    • More comments:
    • Phabricator tickets:

    DiscussionEdit

    The survey has a limit of three proposals per person; archiving this one at the proposer's request. -- DannyH (WMF) (talk) 21:33, 13 November 2017 (UTC)

    Disabling userpages creation by anonymous

      Withdrawn by proposer (too many proposals)

    • Problem:
      • Often, pages in user and user talk namespaces are created or vandalized by anonymous
    • Who would benefit:
      • All
    • Proposed solution:
      • Disabling pages creation by anonymous in these two namespaces
    • More comments:
    • Phabricator tickets:

    DiscussionEdit

    Preventing anonymous users from creating user pages (or similar rules as preventing all non-autoconfirmed from editing other users's pages except talk pages) can easily be done via abuse filters. The benefit is, that it's flexible in the way, that any local exceptions to the rules can be incorporated by simply editing the filter code. --Teslaton (talk) 17:29, 10 November 2017 (UTC)

    @ديفيد عادل وهبة خليل 2: you have more than 3 proposals in the survey. Please mark all of your other proposals as {{withdrawn}} else we'd have to remove them ourselves. Thank you. -- NKohli (WMF) (talk) 20:02, 10 November 2017 (UTC)

    Even if it doesn't go against Founding principles (and it would certainly go against enWikipedia's protection policy) there is no indication of a benefit here. On the contrary, sometimes IPs need to start an user talk page to communicate with someone or they are static but don't like making an account and then make an userpage for themselves. Jo-Jo Eumerus (talk, contributions) 10:31, 11 November 2017 (UTC)

    The survey has a limit of three proposals per person; archiving this one at the proposer's request. -- DannyH (WMF) (talk) 21:34, 13 November 2017 (UTC)

    Editing edit summaries

      Withdrawn by proposer (too many proposals)

    • Problem:
      • It is not possible to edit or correct edit summaries
    • Who would benefit:
      • All
    • Proposed solution:
      • Enable editing edit summaries by their writer or administrators
    • More comments:
    • Phabricator tickets:

    DiscussionEdit

    • A brilliant idea; I'd definitely support this.Bingobro (Meta-Chat) 15:45, 10 November 2017 (UTC)
      This was denied in phab:T12105 and phab:T15937, for the record. Jo-Jo Eumerus (talk, contributions) 10:34, 11 November 2017 (UTC)
      still the idea does have its merits(exp. typos, forgot to ad info, make statement 'x' clearer...IMO)--Ozzie10aaaa (talk) 10:57, 11 November 2017 (UTC)
      It's easier to see the benefits of the idea than to see it's costs. There would have to be a system that stores the edit history of the edit summaries and that adds complexity. ChristianKl (talk) 16:50, 11 November 2017 (UTC)
    • This would be nice to have feature, but I can imagine that the implementation will be a nightmare. --Vachovec1 (talk) 18:27, 12 November 2017 (UTC)
    • I note this was also proposed last year and the year before, and see also phab:T15937#2606108. This is probably never going to happen, as it would require adding history to the edit summaries so others can see who changed it, when, and how, and adding these edits to Special:RecentChanges so patrollers can watch for malicious edits to edit summaries. And people might also want edit summaries for their edit summary edits, and the ability to edit those summaries in turn, ad infinitum. Anomie (talk) 16:15, 13 November 2017 (UTC)

    The survey has a limit of three proposals per person; archiving this one at the proposer's request. -- DannyH (WMF) (talk) 21:35, 13 November 2017 (UTC)

    Add "MyGallery" options to "Special:ListFiles"

      Withdrawn by proposer (too many proposals)

    • Problem:
      • There are useful options on this page only, and can not be translated
    • Who would benefit:
      • All
    • Proposed solution:
    • More comments:
    • Phabricator tickets:

    DiscussionEdit

    The survey has a limit of three proposals per person; archiving this one at the proposer's request. -- DannyH (WMF) (talk) 21:36, 13 November 2017 (UTC)

    Ability to transfer images from Google Photos

      Withdrawn by proposer (too many proposals)

    • Problem:
      • Need to transfer own work photos from Google Photos to Commons
    • Who would benefit:
      • All
    • Proposed solution:
      • Ability to transfer images from Google Photos by URL2Commons
    • More comments:
    • Phabricator tickets:

    DiscussionEdit

    • (1) This is a simple configuration change that requires community consensus. No development work is necessary. (2) The potential for copyvios is too high. MER-C (talk) 12:55, 10 November 2017 (UTC)
    1. This proposal needs to be implemented
    2. Google Account can only be accessed by its owner and there is no difference between ways to upload a stolen image (If the picture is stolen, the method will not affect)

    Thank you --ديفيد عادل وهبة خليل 2 (talk) 14:39, 10 November 2017 (UTC)

    The survey has a limit of three proposals per person; archiving this one at the proposer's request. -- DannyH (WMF) (talk) 21:37, 13 November 2017 (UTC)

    Make files upload themselves without having to wait

      Withdrawn by proposer (too many proposals)

    • Problem:
      • Some files need a long time to upload (especially videos)
    • Who would benefit:
      • All
    • Proposed solution:
      • The possibility of closing the page while leaving the upload works on its own and when finished I get a notification (includes all tools)
      • Making the upload does not slow down the network
    • More comments:
    • Phabricator tickets:

    DiscussionEdit

    • This is not feasible. Web pages cannot instruct a browser to do stuff after said pages are closed because it's a client-side denial of service vulnerability. MER-C (talk) 12:58, 10 November 2017 (UTC)
    • What harm does leaving the browser open provide? If it's to limit network usage, then how are you still uploading it? Also as pointed above, this isn't even really possible-once the POST is issued, it needs to finish through to completion. Even if you had a browser plugin that took over the request so you could hide the tab, it'd still have to upload in the background. For very large files, you may want to look into chunked uploads via the API. 😂 (talk) 03:54, 11 November 2017 (UTC)
    • If I understand this correctly, it mean, creating a new desktop client for contributors to upload large files, with advanced features like upload only when idle?C933103 (talk) 21:23, 11 November 2017 (UTC)

    The survey has a limit of three proposals per person; archiving this one at the proposer's request. -- DannyH (WMF) (talk) 21:38, 13 November 2017 (UTC)

    Log for watching and its interpretation

      Withdrawn by proposer (too many proposals)

    • Problem:
      • The need to remember the name of a page the user was watching
      • The need to remember the reason for watching
    • Who would benefit:
      • All
    • Proposed solution:
      • creation of a log for registration watching pages and its interpretation
    • More comments:
    • Phabricator tickets:

    DiscussionEdit

    The survey has a limit of three proposals per person; archiving this one at the proposer's request. -- DannyH (WMF) (talk) 21:38, 13 November 2017 (UTC)

    Favorite logs (Watching logs)

      Withdrawn by proposer (too many proposals)

    • Problem:
      • Sometimes, the user cares about specific logs and does not care about the rest
    • Who would benefit:
      • All
      • Creating a page includes important logs to the user
    • Proposed solution:
    • More comments:
    • Phabricator tickets:

    DiscussionEdit

    @ديفيد عادل وهبة خليل 2:- The problem statement is not clear. Can you elaborate on the problem please? You can type in your native language and we can find someone to translate if you are not comfortable with English. -- NKohli (WMF) (talk) 18:57, 10 November 2017 (UTC)

    The survey has a limit of three proposals per person; archiving this one at the proposer's request. -- DannyH (WMF) (talk) 21:39, 13 November 2017 (UTC)

    Put terms of watching

      Withdrawn by proposer (too many proposals)

    • Problem:
      • Sometimes, undesirable pages added to watch list (by archiving or moving)
    • Who would benefit:
      • All
    • Proposed solution:
      • Exception of some cases (Such as a specified scope or pages with titles that contain specific words Such as "archive") of addition
    • More comments:
    • Phabricator tickets:

    DiscussionEdit

    • @ديفيد عادل وهبة خليل 2:: This proposal is not clear. When/how are undesirable pages added to watchlist? Also, please note that you are only allowed 3 proposals in the survey. You need to withdraw the rest. -- NKohli (WMF) (talk) 18:55, 10 November 2017 (UTC)
      • @NKohli (WMF): I added additional words --ديفيد عادل وهبة خليل 2 (talk) 19:20, 10 November 2017 (UTC)
      • If a page on your watchlist is moved, then both the old and new title wind up on your watchlist. The complaint here seems to be that, if someone vandalizes a page by moving it to an inappropriate title, anyone who had it on their watchlist winds up with the inappropriate title on their watchlist as well. Anomie (talk) 16:45, 13 November 2017 (UTC)

    The survey has a limit of three proposals per person; archiving this one at the proposer's request. -- DannyH (WMF) (talk) 21:39, 13 November 2017 (UTC)

    Watching pages when adding specific text

      Withdrawn by proposer (too many proposals)

    • Problem:
      • Sometimes the user likes to add pages to the wathlist when adding specific text.For example:d:Q4847311
    • Who would benefit:
      • All
    • Proposed solution:
      • Adding a place to this page for the text required
    • More comments:
    • Phabricator tickets:

    DiscussionEdit

    @ديفيد عادل وهبة خليل 2: - I'm not clear what this proposal means. Can you not watch the page by clicking the watch checkbox when saving page? Or the icon on top? What specific text are you referring to? Also, a reminder that you are limited to 3 proposals only. Thanks. -- NKohli (WMF) (talk) 19:24, 10 November 2017 (UTC)
    @NKohli (WMF): e.g. I like to watch the pages when using {{Delete}} and I need this page to be automatically watched when I add the template.Thank you --ديفيد عادل وهبة خليل 2 (talk) 19:50, 10 November 2017 (UTC)
    Okay. But do you think everyone will also like the same? Different editors have different workflows and others may not like it when pages get automatically watched. -- NKohli (WMF) (talk) 19:55, 10 November 2017 (UTC)
    Can this be done by having the template add works to a category, and then watching the category? —Beleg Tâl (talk) 01:23, 12 November 2017 (UTC)
    This seems like a duplicate of 2017 Community Wishlist Survey/Watchlists/More Options for Auto-Watching‎. Anomie (talk) 16:51, 13 November 2017 (UTC)
    The survey has a limit of three proposals per person; archiving this one at the proposer's request. -- DannyH (WMF) (talk) 21:39, 13 November 2017 (UTC)

    Watching included pages

      Withdrawn by proposer (too many proposals)

    • Problem:
      • It is a difficult thing to follow changes in the nominations pages
    • Who would benefit:
      • All
    • Proposed solution:
      • Adding a button for wathing included pages (in proiect namespace) and adding a button (in the watchlist and beside "Add this page to your watchlist") to show and hide these edits
    • More comments:
    • Phabricator tickets:

    DiscussionEdit

    @ديفيد عادل وهبة خليل 2:. What do you mean by "included pages"? -- NKohli (WMF) (talk) 19:20, 10 November 2017 (UTC)
    @NKohli (WMF): See "MediaWiki:Centralnotice-templates-included".Thank you --ديفيد عادل وهبة خليل 2 (talk) 19:24, 10 November 2017 (UTC)
    I still don't understand. You want to watch transcluded pages/templates? -- NKohli (WMF) (talk) 19:26, 10 November 2017 (UTC)
    @NKohli (WMF): I mean pages whose names are between {{}} --ديفيد عادل وهبة خليل 2 (talk) 19:43, 10 November 2017 (UTC)
    Those are templates and not pages. Why would you want to watch templates? They don't change frequently and are mostly code. -- NKohli (WMF) (talk) 19:54, 10 November 2017 (UTC)
    @NKohli (WMF): The target is the nomination pages which voters are interested in following --ديفيد عادل وهبة خليل 2 (talk) 20:37, 10 November 2017 (UTC)
    You will watch thousands of transcluded pages. IKhitron (talk) 11:59, 13 November 2017 (UTC)
    I suppose the idea is that someone could use the proposed option on 2017 Community Wishlist Survey/Watchlists and they'd automagically see all changes to every idea-subpage transcluded on that page, rather than having to manually watchlist each idea-subpage. The proposal as written is referring to pages like w:en:Wikipedia:Requests for adminship where something similar is done. Anomie (talk) 16:49, 13 November 2017 (UTC)

    The survey has a limit of three proposals per person; archiving this one at the proposer's request. -- DannyH (WMF) (talk) 21:40, 13 November 2017 (UTC)

    Linking with Wikidata with the creation

      Withdrawn by proposer (too many proposals)

    • Problem:
      • It is not possible to link the page with Wikidata except after the creation
    • Who would benefit:
      • All
    • Proposed solution:
      • Merge d:Special:SetSiteLink with creation page (Make this page appears automatically on creation page) to make creation and linking occur together
    • More comments:
    • Phabricator tickets:

    DiscussionEdit

    The survey has a limit of three proposals per person; archiving this one at the proposer's request. -- DannyH (WMF) (talk) 21:41, 13 November 2017 (UTC)

    Make Wikidata obviates templates

      Withdrawn by proposer (too many proposals)

    • Problem:
    • Who would benefit:
      • All
    • Proposed solution:
      • Making Wikidata properties (1 2 3 4) appear Side link to the main topic automatically
      • Dispensing this template
    • More comments:
    • Phabricator tickets:

    DiscussionEdit

    The survey has a limit of three proposals per person; archiving this one at the proposer's request. -- DannyH (WMF) (talk) 21:42, 13 November 2017 (UTC)

    Search for properties in items

      Withdrawn by proposer (too many proposals)

    • Problem:
      • Length of items (sometimes) and the difficulty of finding a property
    • Who would benefit:
      • All
    • Proposed solution:
      • The ability to search for properties in items
    • More comments:
    • Phabricator tickets:

    DiscussionEdit

    • It seems to me like you have made way more than the 3 proposals that are allowed by the Community Wishlist Survey rules. As far as this proposal goes, you don't really explain what you are seeking. Control+F can be used in every webbrowser to search a page. ChristianKl (talk) 14:25, 11 November 2017 (UTC)
    The survey has a limit of three proposals per person; archiving this one at the proposer's request. -- DannyH (WMF) (talk) 21:42, 13 November 2017 (UTC)

    Automatically merge items when redirecting locally

      Withdrawn by proposer (too many proposals)

    • Problem:
      • When merging pages locally, We need to go to Wikidata and merge items
    • Who would benefit:
      • All
    • Proposed solution:
      • Automatically merge items when redirecting locally without going to Wikidata
    • More comments:
    • Phabricator tickets:

    DiscussionEdit

    • Do not endorse. this will lead to a lot of wrong merges because Wikidata often has a valid need for having both items. Users should check Wikidata before merging. ChristianKl (talk) 16:22, 10 November 2017 (UTC)
      • @ChristianKl: We can make this optional.Thank you --ديفيد عادل وهبة خليل 2 (talk) 16:52, 10 November 2017 (UTC)
        • How does that change anything? It's necessary to go to Wikidata to check whether the merge makes sense and you want to let people merge without going through that step. ChristianKl (talk) 17:00, 10 November 2017 (UTC)

    The survey has a limit of three proposals per person; archiving this one at the proposer's request. -- DannyH (WMF) (talk) 21:43, 13 November 2017 (UTC)

    Removal from the implicit permissions automatically

      Withdrawn by proposer (too many proposals)

    • Problem:
      • Sometimes the user has permission and implicit (indirect) permission (Such as administrator and rollbacker)
    • Who would benefit:
      • Bureaucrats
    • Proposed solution:
      • Removal from the implicit permissions automatically when changing userrights
    • More comments:
    • Phabricator tickets:

    DiscussionEdit

    The survey has a limit of three proposals per person; archiving this one at the proposer's request. -- DannyH (WMF) (talk) 21:43, 13 November 2017 (UTC)

    The possibility of undeletion images and categories automatically

      Withdrawn by proposer (too many proposals)

    • Problem:
      • Previously deleted images entering into Public domain and thus requested for undeletion
      • not used categories are need to undeletion when using
      • The need to c:Category:Undeletion requests
    • Who would benefit:
      • All
    • Proposed solution:
      • The possibility of Selection "undeletion automatically" (With the year selected in the images) when deletion images and categories
      • Dispensing c:Category:Undeletion requests
    • More comments:
    • Phabricator tickets:

    DiscussionEdit

    The survey has a limit of three proposals per person; archiving this one at the proposer's request. -- DannyH (WMF) (talk) 21:44, 13 November 2017 (UTC)

    The possibility of removeing links to pages with deletion

      Withdrawn by proposer (too many proposals)

    • Problem:
    • Who would benefit:
      • All
    • Proposed solution:
      • Button to remove links to pages with deletion
    • More comments:
    • Phabricator tickets:

    DiscussionEdit

    The survey has a limit of three proposals per person; archiving this one at the proposer's request. -- DannyH (WMF) (talk) 21:44, 13 November 2017 (UTC)

    Private protection

      Withdrawn by proposer (too many proposals)

    • Problem:
      • The existence of userpages do not need to be edited by any user (except their owners)
    • Who would benefit:
      • All
    • Proposed solution:
      • Establishment of the level of protection to prevent editing except by the owner and administrators (like "Edit other users' CSS files" and "Edit other users' JavaScript files")
    • More comments:
    • Phabricator tickets:

    DiscussionEdit

    The survey has a limit of three proposals per person; archiving this one at the proposer's request. -- DannyH (WMF) (talk) 21:44, 13 November 2017 (UTC)

    Deleting "Talk page of a nonexistent or deleted page" automatically

      Withdrawn by proposer (too many proposals)

    • Problem:
      • Keeping "Talk page of a nonexistent or deleted page"
    • Who would benefit:
      • Admins in all projects
    • Proposed solution:
      • Deleting these pages automatically with the deletion of the original page
    • More comments:
    • Phabricator tickets:

    DiscussionEdit

    • As an admin, I rarely want the talk page deleted. It could for example be that I delete an article, and the longer explanation to or discussion behind the decision to do is available on the talk page and should be kept there. To automatically do this, you'd want the admins on the train before technical development. /Julle (talk) 15:05, 10 November 2017 (UTC)

    Different projects have different policies. For example on the Finnish Wikipedia we have a policy to delete talk pages of non existed pages, but sometimes we want to keep them for example if there was an important discussion. Stryn (talk) 16:54, 11 November 2017 (UTC)

    • Our policy is always keeping talk pages of deleted pages, so the people could know why the page was deleted. IKhitron (talk) 12:07, 13 November 2017 (UTC)

    Possible solution: If there exists talk page for page, admin should be warned (talk page for this page exists, do you want to delete it too?) and should select checkbox. JAn Dudík (talk) 13:04, 13 November 2017 (UTC)

    The survey has a limit of three proposals per person; archiving this one at the proposer's request. -- DannyH (WMF) (talk) 21:45, 13 November 2017 (UTC)

    Sort translation pages by size

      Withdrawn by proposer (too many proposals)

    • Problem:
      • The large number of translation pages
      • The length of some translation pages
    • Who would benefit:
      • All
    • Proposed solution:
      • The ability to sort translation pages by size to translate short pages first
    • More comments:
    • Phabricator tickets:

    DiscussionEdit

    The survey has a limit of three proposals per person; archiving this one at the proposer's request. -- DannyH (WMF) (talk) 21:45, 13 November 2017 (UTC)

    Discussing edits

      Withdrawn by proposer (too many proposals)

    • Problem:
      • It's easy to thank the others, but it is difficult to object or discussion of a particular edit
    • Who would benefit:
      • All
    • Proposed solution:
      • The presence of a button next to thanking button to send a message to the owner of the edit in a specific text (Then we write the details manually) for discussion
    • More comments:
    • Phabricator tickets:

    DiscussionEdit

    • This sounds useful. Downtowngal (talk) 02:16, 12 November 2017 (UTC)
    • We already have this. It's called "talk pages". Anomie (talk) 16:16, 13 November 2017 (UTC)

    The survey has a limit of three proposals per person; archiving this one at the proposer's request. -- DannyH (WMF) (talk) 21:46, 13 November 2017 (UTC)

    Prospective edit

      Withdrawn by proposer (too many proposals)

    • Problem:
      • Some edits the user wants to make should be done later
    • Who would benefit:
      • All
    • Proposed solution:
      • The ability to edit with the delay of the save to a certain day.At the start of the day, I receive a notification
    • More comments:
    • Phabricator tickets:

    DiscussionEdit

    The survey has a limit of three proposals per person; archiving this one at the proposer's request. -- DannyH (WMF) (talk) 21:46, 13 November 2017 (UTC)

    The possibility of moving from editing page to editing section

      Withdrawn by proposer (too many proposals)

    • Problem:
      • Sometimes the user enters editing page and finds that he needs to edit only a section (Especially in long pages)
    • Who would benefit:
      • All
    • Proposed solution:
      • The appearance of "edit" beside text editing area
    • More comments:
    • Phabricator tickets:

    DiscussionEdit

    • Why? If you discover you only need to edit one section after opening the full page in the editor, then just make your edits to the one section instead of messing around with trying to re-open the editor from the editor and probably losing whatever edits you've already made. If the only reason is the automatic edit summary, it's generally easy enough to copy the section header text in between "/*" and "*/". Anomie (talk) 16:19, 13 November 2017 (UTC)

    The survey has a limit of three proposals per person; archiving this one at the proposer's request. -- DannyH (WMF) (talk) 21:46, 13 November 2017 (UTC)

    Make beta.wikiversity subdomains for each target language

     N This proposal contradicts an established policy.

    • Problem: Currently all Wikiversity versions which are in incubation phase are mixed up in the same Mediawiki instance. This makes it more difficult to track progress of each version, and sometime create minor problems like template name being already taken but coded in an other language.
    • Who would benefit: Every version of Wikiversity still in incubation and willing to make the move.
    • Proposed solution: Allow subdomain like zh.beta.wikiversity.org
    • More comments: beta.wikiversity.org might stay as a global instance for users unwilling to make such a move, just as wikisource.org stayed in place for some works.
    • Phabricator tickets:

    DiscussionEdit

    And, why not to propose zh.wikiversity.org instead of zh.beta.wikiversity.org?--Juandev (talk) 21:10, 9 November 2017 (UTC)

    Because, like other linguistic versions mixed on beta, it still didn't reach the criteria for going out of incubation. I would personally not have any problem with putting directly as sub-domain any language as soon a one person show an interest for creating it. But I don't fix this rules. Maybe there are excellent reason to do it this way, but I'm not aware of them. --Psychoslave (talk) 23:20, 9 November 2017 (UTC)
    Sub-subdomains are problematic. URLs would need to be something like zh-beta or beta-zh or whatever. No real opinion on the proposal otherwise. 😂 (talk) 03:18, 11 November 2017 (UTC)
    Can you explain what would be so problematic with subdomains? But would it be the only problem, zh-beta.wikiversity.org would still be better. Also wikiversity:zh:Sample should preferably lead to the page Sample on whatever the domain for zh beta would be. --Psychoslave (talk) 16:08, 12 November 2017 (UTC)

    How about beta.wikiversity.org/wiki/Wv/zh like wikipedia incubator? C933103 (talk) 18:32, 11 November 2017 (UTC)

    How would that solve any of the problem mentionned, which is consecutive to put everything under a single Mediawiki instance? --Psychoslave (talk) 16:08, 12 November 2017 (UTC)
    On incubators, there are tools that would allow filtering activity per languages and allow users set the language they're focusing on. By using same structure as incubator then I assume those tools should also be usable? Also you forgot to sign your name and have only added the date. C933103 (talk) 21:10, 12 November 2017 (UTC)
    Just having a look, it seems that stuff are still mixed up. For example starting typing "template:" in the search bar, templates are listed with language code prepended. That makes template use even more cryptic which is not fine for contributors. Nonetheless I'm interested to know what are the tools you are speaking about, at the very minimal outcome of this proposal, they could be installed on beta.wikiversity.org too. --Psychoslave (talk) 08:11, 13 November 2017 (UTC)

    ArchivedEdit

    We have Incubator/Beta Wikiversity precisely so that we don't have to set up domains for languages that don't have community/content yet. Since this proposal requests a wiki for every beta language, it's not different from "let's create wikis in all languages that have one person supporting it", which goes against our language proposal policy. Thanks for participating in our survey, though! Max Semenik (talk) 22:29, 13 November 2017 (UTC)

    Watch particular user edits

     N Declined in a previous survey

    • Problem:

    A need for persistent watching of suspected user or IP edits, so you can check them in real time instead of remembering all the addresses and reaching the contribution pages from time to time.

    • Who would benefit:

    Patrollers and admins. The feature will not be available for users that are not patrollers.

    • Proposed solution:

    Adding all their edits to your watchlist, they are spread among all others there. Bolded like any other edit, until you have opened the diff page. To add or remove a user, click on the regular star on the user page or on the user talk page, which will not only bring you revisions to these pages, but also the user's own edits. So that you do not get millions of edits you do not need, and so that there will not be conflicts in the community, only users who are not autopatrolled will enter the list, because there is no point in checking the rest, that is, only new registered and anonymous. On the watchlist page itself, along with the rest of the filters, a filter will be set to show and hide user edits that I watch so that anyone who wants to can distinguish. And this filter will also appear in preferences, for persistent setting. These user names, or IP numbers, will have a new CSS class, so you can write a simple gadget that changes the formatting of names, or their edits, to anyone who wants to - background color, highlighting etc.

    • More comments:

    I do not think it's worth creating a special page for these edits instead of incorporating them into the regular watchlist for the following reasons: The first is comfort - if it's somewhere else, we'll be there less than when it's all in the same place. The second - the chance that it will be implemented as a separate page is falling dramatically, because this is a new feature rather than an existing feature expansion. Another reason is technical - the mess for edits to pages you watch done by people you watch at the same time. Where does it belong? What happens if we open the edit by watching people, we have lost all previous edits of this page in the regular watching, the page has already been marked as seen, and there is no way back. That is, it will make us miss a lot of edits in the usual watchlist.

    • Phabricator tickets:

    DiscussionEdit

    Thank you, Anomie. But I do not see in your links something about the restrictions I added exactly to avoid any kind of abuse. The wrong people will not have this feature, and the right people will not have it about their colleagues, only new on anonime users. Don't you think it solves the problem? I can't see any possible abuse using these characteristics. IKhitron (talk) 17:41, 13 November 2017 (UTC)
    Hi IKhitron, we did talk in 2015 about whether we could build this just for admins, and determined that wasn't enough. Here's a quote from the statement we published:
    "We could make this tool available to admins, which was suggested by several people during the survey. However, a lot of vandal fighters and mentors are not administrators. Also, to be honest, as active Wikimedians, we’re aware of many cases where admins have been part of personal conflicts. While the vast majority of trusted users would of course use it in good faith, it would create the perception of admins having a tool that could be used for stalking, which is invisible and inaccessible to other users and beyond their control. We’ve been strongly discouraged from doing this."
    We won't be able to build this feature, so I'm going to archive your proposal. Thanks for participating in the survey. -- DannyH (WMF) (talk) 01:09, 14 November 2017 (UTC)
    Do you really think that admin can stalk an anonym, DannyH? And it's worse than this admin will delete many articles, something he can do know? Thank you. IKhitron (talk) 01:28, 14 November 2017 (UTC)
    Yes, it's possible that an admin can do something that's unfair. If they delete a lot of articles, that's part of a public log that people can use to raise questions. If an admin follows a new user around and disrupts every edit that they make, that's much harder to track -- an outside person wouldn't see it, but the user that's being targeted definitely would. This feature definitely would be helpful for the majority of people who would use it in good faith. Unfortunately, we know that some people would use it in an unfair way, even admins. -- DannyH (WMF) (talk) 19:02, 14 November 2017 (UTC)
    I see, DannyH. Thank you. IKhitron (talk) 21:01, 14 November 2017 (UTC)

    Live Clock

    • Problem: It would be nice to have a Wiki command {{Clock|Form|Country}}
    UTC date and time:
    Tuesday
    October
    9:22 pm UTC

    to include a live analog clock in Wikipedia pages.

    • Who would benefit: All Wiki Pages talking about a country or a city could include this watch.
    • Proposed solution: As Clock presentation one maybe could use the famous Swiss Railway Clock
       
      Actual time in X-Land
    • More comments:
    • Phabricator tickets:

    DiscussionEdit

    • Also I would love to have this on my userpage:) I don't know how technically feasible it is, given the issues with server caches, the way mediawiki deals with storing pages and other technical barriers that make it more or less impossible to have an accurate time on a wikipage. It might be a bit of a big ask. A Den Jentyl Ettien Avel Dysklyver (talk) 11:56, 9 November 2017 (UTC)
    • You can already do this in JavaScript. There is no need for Community Tech to implement it. MER-C (talk) 12:30, 9 November 2017 (UTC)
    How? (yep totally asking for my userpage) A Den Jentyl Ettien Avel Dysklyver (talk) 14:59, 9 November 2017 (UTC)
    @Hp.Baumeler and A Den Jentyl Ettien Avel Dysklyver: There are these existing templates on Enwiki, which could be copied to your homewiki w:en:Template:Clock, w:en:Template:Digital clock and date, w:en:Template:Calendar clock with Wikipedia stats and w:en:User:Shardsofmetal/Clock (analog), and a few more in w:en:Category:Clock templates. Quiddity (WMF) (talk) 17:53, 9 November 2017 (UTC)
    @Hp.Baumeler: Oh, I read the proposal and first comment too quickly. I now see that you specifically meant a template to use in article pages, and not userpages as the templates I linked above are intended for. However, technical editors at your local wiki should be able to help you create a template or infobox parameter for this, using JavaScript - see equivalent templates w:en:Template:Current minute in time zone for example code. Note, it would only work for readers who have JavaScript enabled. I will archive this proposal, as it doesn't require Community Tech to implement it. Thanks. Quiddity (WMF) (talk) 01:12, 14 November 2017 (UTC)

    Switching between dictionaries (religious, philosophical, scientific). Like switching between languages.

     N Requires community consensus

    • Problem: Any term refers to a dictionary. Currently, the Wikidata provides the user with terms from a mixture of dictionaries (religious + philosophical + scientific+common). The user can only switch between mixed dictionaries of different languages. He can not switch between dictionaries of one language (religious, philosophical, or scientific). But mixing dictionaries and increases chaos: worsens transitivity, leads to constant conflicts, struggle for the one whose dictionary should first point to the object being modeled (with the help of the Wikidata's virtual tool) (see human/Homo sapiens sapiens, god/God, origin of human, world, universe, etc.), 1/one, 2/two, etc.).
    • Who would benefit: Users who need transitivity.
    • Proposed solution: To make a choice of the dictionary necessary to the user (by analogy with a choice of the language necessary for the user). The user selects the language, then selects the dictionary (religious, philosophical or scientific) and makes a description. As a result, the same simulated object of the world (human/Homo sapiens sapiens) will only have one item (Q5).
      When you select a dictionary, the foreign link of the item (subclasses, properties, etc.) should be hidden. If you chose, for example, a religious dictionary, you should not see links to items that relate to the scientific and philosophical dictionaries. In this case, the concept of "neutrality" is not needed at all, for there will be no hostile points of view (they will remain each in their own dictionary).
    • More comments: Wikipedia does not have a switch even from one language to another. If the Wikidata will be able to switch between dictionaries (religious, philosophical, scientific, general), then Wikipedia will finally become atavism and rudiment, focused only on humans, but not on machine readability.
    • Phabricator tickets:

    DiscussionEdit

    What does the community think about this? Do you have consensus from those who are supposed to maintain this? Max Semenik (talk) 23:43, 10 November 2017 (UTC)

    I did not poll, I do not know how to poll all users who need transitivity. --Fractaler (talk) 17:45, 12 November 2017 (UTC)
    Do not endorse. I don't think the Wikidata community wants this, to the extent that "this" is even well-defined. ChristianKl (talk) 01:22, 13 November 2017 (UTC)
    Are you afraid of transitivity, because then the ideology of ontology based on properties will lose? Fractaler (talk) 17:59, 13 November 2017 (UTC)

    ArchivedEdit

    I've archived this proposal because it requires maintenance of the proposed system by the Wikidata community, and therefore consensus. Without consensus, we can't start implementing the software parts. Thanks for participating in our survey. Max Semenik (talk) 02:25, 14 November 2017 (UTC)

    Delete the 10000 articles every Wikipedia should have from the 10 largest language editions of Wikipedia

     N An obviously destructive idea

    • Problem: As an incentive to new authors, authors are notified, if their created article is linked from another article. But all the important articles, that are likely to get linked have been written years ago. These high value articles are also protected/guarded by old contributers against any change that is not liked by these valued authors. While being important articles, they often contain material, that by todays standards would not be included in an article.
    • Who would benefit: Everyone wanting to read high class articles.
    • Proposed solution: Delete all the articles from the list of 10000 articles, that all Wikipedias should have in the 10 largest Wikipedia editons.
    • More comments: These articles have all been havily reused on other websites, so nothing will be lost. The new created articles will be free of historic ballast and make way for a better Wikipedia.
    • Phabricator tickets:

    DiscussionEdit

    • This should be declined. --Izno (talk) 13:53, 14 November 2017 (UTC)
    • IMO an out of scope proposal (about wiki content which is maintained by communities, not about anything technology/software related), hence this proposal is very likely to be ignored. --AKlapper (WMF) (talk) 17:05, 14 November 2017 (UTC)

    ArchivedEdit

    Nope. Just nope. Max Semenik (talk) 23:16, 14 November 2017 (UTC)

    Add en-us as a separate language

     N Proposes social/community change rather than a technical feature

    • Problem: The need to recognise that American (e.g. color) is not always the same as international standard English (e.g. colour). Currently many items in Wikidata are given English (en) names that are not used universally in English, but are uniquely American, and not used by (and are often detested by) English speakers in the rest of the world. Wikidata recognises en-ca for names that are uniquely Canadian and en-gb for names that are uniquely British, but does not admit the distinction of en-us for names that are uniquely American. This is a surprisingly frequent problem with the vernacular names of animals and plants, where one name is near-universal in English except for USA, where a different name is used.
    • Who would benefit: English speakers worldwide outside of the USA as reusers of Wikidata (e.g. lists of vernacular names on Commons)
    • Proposed solution: Create en-us as an additional language, so that uniquely American names can be indicated as such and no longer be passed off as universal English
    • More comments: This would help resolve the long-standing problem of American imperialism on wikidata, whereby uniquely American names are imposed as 'standard English' names on English speakers in the rest of the world (England, Ireland, Australia, New Zealand, South Africa, etc., etc.) against their wishes.
    • Proposer: MPF (talk) 12:34, 9 November 2017 (UTC)

    DiscussionEdit

    • Given that this doesn't take much development, how about going the usual way of adding a language of creating the phabricator ticket? ChristianKl (talk) 16:47, 9 November 2017 (UTC)
    • "American imperialism". You know a proposal isn't serious when it requires namecalling. --Izno (talk) 21:13, 9 November 2017 (UTC)
    • How is sociological assessment "namecalling [sic]"? 142.160.131.202 22:34, 10 November 2017 (UTC)
    • I think it's already possible to have separate labels for en-US, en-GB, en-CA, and en-AU. Simply set up your {{#Babel:}} with those langauge variants. Deryck C. 23:19, 9 November 2017 (UTC) Okay I was wrong. Deryck C. 19:36, 10 November 2017 (UTC)
    • @Deryck Chan:It's possible for en-GB, en-CA but not for en-US or en-AU. Those would have to be added and our general process for doing so is a phabricator ticket. If there are disagreements about whether we want to add them, the forum would be somewhere on Wikidata. ChristianKl (talk) 16:17, 10 November 2017 (UTC)
    • While I share the concern about the symptom, I'm not sure it's really a technical problem, but more an editorial one about accepted language granularity. That is, the problem surely go far beyond en-US, as I would expect that even within US you will find regional linguistic variations. Actually, even in small town you might find notable dialectal variations. So surely recognize en-US would be fine, but this wouldn't solve the underlying problem. --Psychoslave (talk) 09:20, 12 November 2017 (UTC)
    • Having looked more into the issue, it's an issue that's entirely about policy. The Wikimedia Language Committee seems to have the opinion at the start of the year that en-US shouldn't be added. This leaves either the possibility to convince them to accept it or to change Wikidata policy to remove the jurisdiction about the decision from them. There's nothing the Community Tech Team can do about either. ChristianKl (talk) 01:20, 13 November 2017 (UTC)
    Yes, this is a policy matter rather than a technical proposal. Community Tech can't work on this, so I'm going to archive the proposal. Thanks for participating in the survey. -- DannyH (WMF) (talk) 00:11, 15 November 2017 (UTC)

    Language

     N Proposes social/community change rather than a technical feature

    • Problem:

    Questionnaires, announcements etc. only in English

    • Who would benefit:


    • Proposed solution:

    Also in other tongues, like French or German

    • More comments:
    • Phabricator tickets:

    DiscussionEdit

    ArchivedEdit

    This proposal is about a social/organizational change and therefore not suitable for our technical survey. Thanks for participating. Max Semenik (talk) 18:25, 15 November 2017 (UTC)

    Create global translation administrators

     N Proposes social/community change rather than a technical feature

    • Problem: Some wikis have much more active translation admins than others
    • Who would benefit: Every non-English speakers of the community.
    • Proposed solution: The idea would be to make global translation administrators on every WMF wikis with the translation extention on it. It would make the translation system faster, more efficient and flexible without sacrificing safety. After 6 month of inactivity, they would lost their rights.
    • More comments: A local translation admin with experience could ask Stewards these rights.
    • Phabricator tickets:

    DiscussionEdit

    This is not the purpose of 2017 Community Wishlist Survey. We can already do this, creating a new gloal user group. It was already discussed. Matiia (talk) 21:46, 9 November 2017 (UTC)

    ArchivedEdit

    As explained above, we already have the technical means to do this, however there is no community consensus. As soon as there is consensus, this will be done. Thanks for participating in our survey. Max Semenik (talk) 22:29, 15 November 2017 (UTC)

    Photoshop wiki

     N Out of scope for the Community Tech team, too big

    • Phabricator tickets:

    DiscussionEdit

    There is plenty of free software to do this stuff already. I use both Gimp and Darktable for this kind of thing, and there is also Inkscape for SVG work -- Thennicke (talk) 02:30, 11 November 2017 (UTC)

    @Thennicke: We want a tool belong to us and translatable.Thank you --ديفيد عادل وهبة خليل 2 (talk) 08:48, 12 November 2017 (UTC)
    Beware NIH syndrome. Tools already exist, let's not reinvent the wheel. Anomie (talk) 16:27, 13 November 2017 (UTC)
    I concur with thennicke and anomie. The tools gimp, inkscape, darktable, imagemagick and others are opensource, they belong to everybody, so also to the wiki community. I am an occasional contributor to some wikipedia graphic labs and I find those tools are sufficient for the work needed here. Regards--Basquetteur (talk) 17:17, 13 November 2017 (UTC)
    @Thennicke, Anomie, and Basquetteur:
    1. These tools are not translatable; therefore, only a small group of contributors will benefit
    2. We want one tool to help us improve any file--ديفيد عادل وهبة خليل 2 (talk) 06:38, 14 November 2017 (UTC)
      Sure they're translatable. For example, here is a page about The Gimp's current translation status, and here is a document about how to contribute translations for Inkscape. As for "one tool", it's often better to have multiple tools that are good at one thing each than to have one tool that's mediocre at everything. Anomie (talk) 14:30, 14 November 2017 (UTC)

    ArchivedEdit

    This is a huge undertaking that our team doesn't have the resources for. Additionally, there are lots of free graphics tools so the benefit from the proposed solution will be marginal at most. Thanks for participating in our survey. Max Semenik (talk) 00:26, 16 November 2017 (UTC)

    Ne plus utiliser a priori la notion de "harcèlement" ou de "harassment" mais définir clairement le problème supposé ou constaté

     N Proposes social/community change rather than a technical feature

    • Problem: Utiliser un terme aussi connoté, et connoté négativement, que "harcèlement" (en français) ou "harassment" (en anglais), dans la présentation d'une controverse, induit une certaine lecture qui oriente les opinions, soit sur le contributeur visé, soit sur celui qui le vise. Que d'autres contributeurs puissent par la suite suggérer, et non pas affirmer, que ça puisse être du harcèlement, est acceptable, que le contributeur rapportant le cas le fasse l'est moins. Disons, ce n'est pas aux parties concernées de définir une imputation aussi subjective. Les cas ressortant de faits évidents (tels que répéter trois fois une annulation de contribution) sont aisément qualifiables, ceux ressortant d'un sentiment le sont moins. (merci à quiconque voudra traduire en anglais ou en “globish” selon compétence)
    • Who would benefit: Tous les contributeurs.
    • Proposed solution: Aucune pour l'initiateur de cette proposition (disons, la proposition est la solution proposée).
    • More comments:
    • Phabricator tickets: L'initiateur de cette proposition ignore complètement ce que peuvent être des “Phabricator tickets” et n'a certainement pas l'intention de le découvrir, parfois l'ignorance est salvatrice.
    • Proposer: Olivier Hammam (talk) (“Ma Pomme” pour les poteaux) 05:34, 16 November 2017 (UTC)

    DiscussionEdit

    This isn't a technical proposal. It's not for the Community Tech team to tell communities how to define certain words or how to interact with each other – we can only do technical development on technical proposals. /Johan (WMF) (talk) 16:05, 16 November 2017 (UTC)

    New user right: Project sysop

     N Proposes a change in policy, rather than a technical feature

    • Problem: Many language versions of the sister projects have a small community and no or just a few active admins. In my case I am very active on Wikivoyage, I am admin and bureaucrat on four language versions. But I can not help other small Wikivoyages. I need admin rights for deleting spam and installing/configuring features. People ask me for help but I can not. If I apply for admin right on e.g. Vietnamese WV, it is limited to one or three month. I have to reapply on and on. This process makes me tired. Even my adminship on WV/uk is limited although I finished an application on this wiki. My global sysop application was denied due to no inter wiki skills, but I have no time to edit in other projects just to get these needed inter-wiki skills. A sysop right for a whole project (like Wikivoyage) would be extremly useful to help the small wikis and roll out own features (like our maps or listings editor)
    • Who would benefit: All small wikis.
    • Proposed solution: New user right.
    • More comments:
    • Phabricator tickets:
    • Proposer: DerFussi 08:32, 16 November 2017 (UTC)

    DiscussionEdit

    ArchivedEdit

    This is a policy proposal, and as such it's out of scope for our survey. Regardless, thanks for participating! Max Semenik (talk) 19:45, 16 November 2017 (UTC)

    أرجو أن أرى فقرة بعنوان "سؤال الأسبوع" في الصفحة الرئيسية لويكيبيديا العربية "كما في ويكي الأخبار :)

     N Proposes social/community change rather than a technical feature

    • Problem: المشكلة
    • Who would benefit: من الذي قد ينتفع
    • Proposed solution: الحل المقترح إنشاء فقرة "سؤال الأسبوع" أو "سؤال اليوم" للاستفادة من معلوماتهم السابقة
    • More comments: تعليقات أخرى تم إنشاء ذلك في "ويكي الأخبار" بالنسخة العربية حيث يتم تقييم الإجابة بعد أن يجيب الزائر على إحدى خيارات السؤال
    • Phabricator tickets: تذاكر فابريكاتور

    DiscussionEdit

    @A3bdula3ziz: This proposal sounds out of scope to me, as no software development is required. The Arabic Wikipedia community could just introduce this if they wanted, after discussion on w:ar:ويكيبيديا:الميدان? --AKlapper (WMF) (talk) 15:04, 10 November 2017 (UTC)

    Create a tool for merging global accounts

     N Not technically feasible

    • Problem: There is no way to merge global accounts now. During the SUL finalisation it happened often, that one contributor ended up with more global accounts. There can be other reasons as well, why one person has more than one accounts, and would like to merge them. As a bureaucrat and recently a global renamer I received several requests from many users in the last 10 years to merge their accounts, and I promised them that it will be possible soon (it is relative, but in some years), and I was waited for this feature as it was planned in the frame of the SUL finalization. Until end of last year when the developers announced that this feature doesn't work trustfully and won't be deployed.
    • Who would benefit: Contributors, who has more (global) accounts and would like to merge them.
    • More comments: Before the voting phase I would like to see if this request is technically possible or not. Please investigate if this is simply impossible for Wikimedia wikis or we need "only" to improve our software/hardware infrastructure to solve the problems.
    • Proposer: Samat (talk) 12:39, 18 November 2017 (UTC)

    DiscussionEdit

    @Legoktm (WMF), Hoo man, Keegan (WMF), MarcoAurelio, and Nemo bis: I would appreciate your expert opinion on this topic. Samat (talk) 12:39, 18 November 2017 (UTC)

    We worked a lot on this but irreversibly broke accounts trying to merge them, see phab:T104686. For the tool, see further phab:T156584 and the tag usermerge on Phabricator. Best, —DerHexer (Talk) 13:23, 18 November 2017 (UTC)
    I think I know the earlier cases and the current situation, but this means only that it is currently not working and disabled. It is not clear for me, that the request is absolute not possible or just relative ( = hard to solve). Samat (talk) 14:04, 18 November 2017 (UTC)
    @Samat: You will not get an answer. It is a question of cost and benefit. What is the benefit? For some time now all new account are global. Only very old account would profit, and of those only that account that are still active, and of those only the ones that still want it. Let's say for the sake of the argument, that these are 200 people who benefit. What is the cost? It has been tried before, accounts have been irreversibly broken. Before it is tried again you need to test a new solution. You cannot test on production, so you will not break any more accounts. You need to create a replica for testing: 800+ wikipedias, with dozens of millions of users, with billions of edits. This test environment would need a hardware as big as that of production. That would cost millions, So instead you will run it on a smaller hardware. It will still run, but slow. The test of a single unification might take 2 days to complete. To test all 200 accounts may take 400 days. But if after 399 days of testing the system breaks, you have to correct the unification software and than start over. The correction might work, but in the end you may find another error, and you start again... Yes it is possible, No it will never be done. --𝔊 (Gradzeichen DiſkTalk) 23:57, 18 November 2017 (UTC)
    Thank you for your explanation. It is sad, but rational. Samat (talk) 00:30, 19 November 2017 (UTC)
    The tool exists, but there's a lot of legacy in the databases that prevent the tool from working on old accounts sadly, which are the ones that would really benefit from this. See phab:T49918#1933044 for details. That said, I'd love that now that we know the issues, try to work on fixing them if at all possible. —MarcoAurelio (talk) 20:30, 19 November 2017 (UTC)

    Hi Samat, it looks like this proposal isn't really technically feasible. I'm going to archive this before the voting phase. Sorry for the sad answer; thanks for participating in the survey. -- DannyH (WMF) (talk) 17:38, 20 November 2017 (UTC)

    Brainstorming for wiktionaries

     N Wishlist Survey isn't a good place for brainstorming

    • Problem:

    It is impossible from the current form of all wiktionaries to create a pdf book for:

      • lang to lang (definitions only, ex. Italian-English)
      • specialized dictionary of lang (ex. Greek medical dictionary, Magyar etymological dictionary)

    Also it is impossible to view a wiktionary only in the above mentioned way.

    • Who would benefit:

    Readers?

    • Proposed solution:

    Create a page for proposes on how to achieve this.

      • by creating gadgets?
      • by creating new mediawiki extentions?
      • ...

    Maybe one or more trial new (lang)projects that will collect (temporarily) data from some selected wiktionaries in order to make there trials.

    • More comments:

    Most wiktionaries differ in the way they present data. It is difficult to create a common gadget. That's why I am not proposing a gadget but a place to discuss problems and solutions specific to that direction.

    • Phabricator tickets:

    DiscussionEdit

    Hi Xoristzatziki: This is an interesting question, but the Wishlist Survey isn't the appropriate place for a brainstorming session. I'm going to archive your proposal; thanks for participating in the survey. -- DannyH (WMF) (talk) 17:53, 20 November 2017 (UTC)

    Science templates

    • Problem: Generally, all edits need a reference. But science is arithmetics, so F= °C, miles= km and meter= feet conversion templates are allowed.

    For example, cristalline minerals with a solved structure have a position for each atom. Chemical formulas need to be charge-balanced, but copies and typos make errors and these errors live forever (there are ions, but their half-life is less than one second). I think that in the next 25 years we should check more data on Wikidata. A scientist makes many experiments, he publishes some experiments, the papers are cited in a secondary literature, the secondary literature is cited in Wikipedia. The sources for errors are unbelievable infinite. Cristal structure, atomic volume and chemical formula are interlocked through arithmetics. There are many possible errors, at no time is everything right.

    • Who would benefit: science articles.
    • Proposed solution: the laws of physics should get more templates and bots.
    • More comments:
    • Citation (CNMNC Newsletter 39 (August and September, 2017)): "After the approval of the new mineral magnesiobeltrandoite-2N3S (IMA2016-073; see CNMNC Newsletter 34 (October and November, 2016)) the authors became aware that the approved chemical formula of the mineral was not charge-balanced."
    • Citation (rruff.info/ima): "Note that chemical formula is not charge-balanced in this report. The formula from the 1987 paper is kept."
    • Hogarth D D (2006) Fluoro-potassic-magnesio-arfvedsonite, KNa2Mg5Si8O22F2, from the Outaouais region, Quebec, Canada, The Canadian Mineralogist 44, 289-289.
    • Phabricator tickets:

    DiscussionEdit

    • How is this problem not solved by creating the templates and Lua modules yourself and having a community-run RFC for a find and replace? No development work is necessary. MER-C (talk) 12:50, 10 November 2017 (UTC)
      • This problem is huge (strategic). Science is arithmetics, Wikidata building must aim for interlocking its data. For example, the chemical formula would need a periodic table as data in the background. We do not have cristallographic data of a mineral structure, this would be a huge data input. Sure a programmer can make initial steps with templates and lua modules (maybe, the initial step should be physics). It is "just" a wake up call, and strategy is meta. --Chris.urs-o (talk) 05:53, 11 November 2017 (UTC)
    • @Chris.urs-o: If I understand correctly, you're talking about things like being able to, "list all statements citing a source that cites a specific journal article that was retracted"1 - if that is correct, see d:Wikidata:WikiProject Source MetaData and WikiCite for the people already working towards this. If I've misunderstood, please explain in a bit more detail. Thanks! Quiddity (WMF) (talk) 23:36, 13 November 2017 (UTC)
      • It is about strategy. Science is arithmetics. A chemical formula of a mineral should be charged-balanced. The measured density and the calculated density (atomic volume and mass) of a mineral structure should be the same; and so on... The physics of many numbers (data) should be interlocked to find out any typos. Something must be done in the future. --Chris.urs-o (talk) 04:54, 14 November 2017 (UTC)
        • @Chris.urs-o: Ah, now I think I understand. You are proposing something more akin to wolframalpha. This would be to help with various things within the existing content projects, such as prevent typing errors (perhaps by highlighting when an editor has typed something physically impossible, e.g. Al + O2 -> Al2O4 (should be Al203, per)). -- If that is correct (?) it is a grand idea, but much too big in scope for this wishlist process. I recommend starting a new page at Computational engine or similar, to give more detail to the idea and more time for slow discussion. I'll move this proposal to the archive section in a day or two. Cheers :) Quiddity (WMF) (talk) 20:31, 17 November 2017 (UTC)
          • Ok, you are right. The literature has typing errors as well. --Chris.urs-o (talk) 21:11, 17 November 2017 (UTC)
    • Are you basically asking for arithmetic-based Wikidata constraints? --Tgr (WMF) (talk) 05:43, 18 November 2017 (UTC)

    Fixed markup for citation with in text attribution

     N Proposes a change in the way that wiki communities design their templates, not a technical feature

    • Problem: Citation markup for {{harvtxt}} and {{harvcoltxt}}, didn't work as they should. There are a lot of advices in the Template talk (here) and (here), but it would be better if there is a fixed markup to use these kind of citations with in text attribution.
    • Who would benefit: All registered users.
    • Proposed solution: Fixed markup to use these templates.
    • More comments:
    • Phabricator tickets:

    DiscussionEdit

    • This appears to be out of scope as a wikitext problem, not a software development problem. MER-C (talk) 04:32, 13 November 2017 (UTC)
    • Yeah, this should be handled by the communities, not by a technical fix. I'll archive this proposal; thanks for participating in the survey. -- DannyH (WMF) (talk) 18:08, 20 November 2017 (UTC)

    Search book about subject of article in Russian State Library

     N Proposal doesn't make sense

    • Problem:

    Many articles in Wikipedia have very shot list references, but in modern digital libraries there are many book about subject of this articles

    • Who would benefit:

    user save time, they have got direct links to book

    • Proposed solution:

    title of many articles in Wikipedia are the same as title of classification indexes in library classification system. So it is possible to send request to library system with title of article as subject request and have got list of digital book.

    • More comments:

    In Russian State Library, for example, classification system is published as Linked Open Data and all indexes could be requested as

    PREFIX text: <http://jena.apache.org/text#>
    PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
    SELECT
        ?concept
        ?notation
        ?prefLabel
        ?hiddenLabel
        ?broader
    WHERE {
      ?concept text:query (skos:hiddenLabel '"subject in Russian"') ;
          skos:notation ?notation ;
        skos:prefLabel ?prefLabel ;
        skos:hiddenLabel ?hiddenLabel ;
        skos:broader ?broader .
    } LIMIT 1
    

    As I know many national libraries have API or published their metadata as Linlked Open Data. That is why I suggest to use it as additional tools for enrichment Wkipedia

    • Phabricator tickets:

    DiscussionEdit

    ArchivedEdit

    This proposal doesn't make much sense to me: references are where you took that information from, not where to look for more. Thanks for participating in our survey. Max Semenik (talk) 18:11, 20 November 2017 (UTC)

    Bluebook Citation Template

      Done Feature already exists

    • Problem: For articles about legal topics, many editors would prefer to use a legal citation style. The most common such style is Bluebook. Currently we must write Bluebook style citations by hand. See the Bluebook article for examples.
    • Who would benefit: Editors who contribute to articles on legal topics. We might also attract more attorneys to contribute to articles if our citation options include a lawyer-friendly choice.
    • Proposed solution: Put forth a request to Wikipedians who possess citation-creation talent asking if one (or more) would be so kind as to create a Bluebook citation style. (Of course, editors would not be required to use Bluebook citation style for articles on legal topics, it would simply be an option.)
    • More comments: There is at least a bit of precedence for this request in that we have a citation template for citing cases {{cite court}} that conforms to Bluebook citation style, and the inventor fields used with the {{Citation}} template result in an almost-Bluebook citation format. (See patent in the Citation template#Examples table.)
    • Phabricator tickets:

    DiscussionEdit

    Good golly Miss Molly! In looking for something else related to legal citation, I stumbled across a Bluebook journal template and a Bluebook website template. So, I reckon my proposal is superfluous, unless someone can think of any other Bluebook templates (books?) that might be needed. Mark D Worthen PsyD (talk) 04:32, 16 November 2017 (UTC)

    Related: WikiCite is an initiative to move citation data into Wikidata so it's machine-readable and can be presented in arbitrary formats. --Tgr (WMF) (talk) 06:20, 18 November 2017 (UTC)

    Hi Markworthen: It looks like you've solved the problem. :) Thanks for participating in the survey. -- DannyH (WMF) (talk) 18:10, 20 November 2017 (UTC)

    Replace or supplement mobile pencil icon with "edit" in square brackets and A/B test editing uptake

     N Proposal is for design and research, out of scope for Community Tech

    • Problem: The pencil icon is not necessarily a call to action, and may be partially responsible for less editing on the mobile web interface.
    • Who would benefit: Mobile users interested in editing.
    • Proposed solution: Replace or supplement the mobile presentation's pencil icon with "[edit]".
    • More comments: This is not intended to be a subjective design decision proposal, but rather an objective measurement of which choice results in more editing.
    • Phabricator tickets:

    DiscussionEdit

    Hi James Salsman: This isn't a technical proposal, it's a design decision by another team. I'm going to archive this proposal; thanks for participating in the survey. -- DannyH (WMF) (talk) 18:36, 20 November 2017 (UTC)

    @DannyH (WMF): would you please restore it to the mobile team proposals? It's not intended to be a proposal for human design judgement, but a UI change based on objective A/B testing of which output causes greater numbers of edits. James Salsman (talk) 08:59, 21 November 2017 (UTC)
    James Salsman: Coming up with alternative icons and testing them is a project for a design researcher. It's just not something that the Community Tech team is able to do. Sorry to give you a disappointing answer. -- DannyH (WMF) (talk) 19:56, 21 November 2017 (UTC)
    No problem, thanks for trying! James Salsman (talk) 11:51, 24 November 2017 (UTC)

    Upload-Wizard should remember the uploaders name

      Doing... Planned by a product team

    • Problem:

    Whenever I upload a self-taken picture to Commons with the Default-Uploaderpage ("Upload-Wizzard"), the name with the name of the author contains my username but I want my real name to be specified there. So every time I have to replace my username by my real name. It's especially annoying since the auto-fill of the Browser does not work in this field.

    • Who would benefit:
    • Proposed solution: Since the name of user rarely if at all changes it would make sense for the Upload-Wizzard to remember the given name.
    • More comments: Could be saved in Cookie or on server-side, I don't care but please save it.

    DiscussionEdit

    • Endorse, in fact there should be several options like “upload with your signature” (WikiSignature), or any way you like it, like for example “Joseph Smith (b. 1973)” in case someone finds that important, this should be a custom option in preferences. --Donald Trung (Talk 🤳🏻) (My global lock 😒🌏🔒) (My global unlock 😄🌏🔓) 12:04, 12 November 2017 (UTC)
    • Endorse Vera (talk) 20:48, 12 November 2017 (UTC)
    • +1. I have a 'Creator:' template, so that should be remembered, too. And obviously overwriteable, if the user is uploading third-arty images. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:27, 15 November 2017 (UTC)
    • Small issue but good idea. --Jarekt (talk) 14:31, 16 November 2017 (UTC)
    • And remember not to link to the entire name, maybe? What I want for Commons is to have both my name and my user name, but only link to the user name: "Johan Jönsson (Julle)". /Julle (talk) 15:24, 16 November 2017 (UTC)
    • This already has a Phab ticket and a patch, which is being addressed now. https://phabricator.wikimedia.org/T154154 RIsler (WMF) (talk) 00:55, 18 November 2017 (UTC)
    • Endorse, · · · Peter (Southwood) (talk): 09:48, 18 November 2017 (UTC)
    • As RIsler (WMF) said above, the good news is that this is currently being worked on. :) You can see the progress at phab:T154154. I'm going to archive this proposal. -- DannyH (WMF) (talk) 18:42, 20 November 2017 (UTC)

    Auto format on save

     N Out of scope for Community Tech

    • Problem:

    The syntax of wiki source code can be formatted differently. If there would be a “coding guideline“ for wiki code, it would be uniform and easier to read. The coding guideline would affect both HTML syntax and wiki syntax. This would concern unneeded white space at the end of a line, spaces in tags or in table syntax, for example. The HTML parts of the source code could get consistent with XTHML.

    • Who would benefit:

    every editor

    • Proposed solution:

    When a edit is saved the source code will be formatted automatically accordind to the guideline. The coding guideline could be developed and applied incrementally.

    • More comments:
    • Phabricator tickets:

    DiscussionEdit

    Hi Heikolino1010: We're going to have to decline this proposal as being too big for our team to work on. This would require constant work as the communities make new decisions on the guidelines, and every wiki community would want something different. I'm going to have to archive this proposal. -- DannyH (WMF) (talk) 18:47, 20 November 2017 (UTC)

    Hi DannyH, thank you for your answer. I understand the problem and accept it. --Heikolino1010 (talk) 19:49, 20 November 2017 (UTC)

    Special character and charset bar above edit window

      Done -- feature already exists

    • Problem:

    Currently you have to scroll down below the edit window, if you want insert special characters, quotation marks, brackets or wiki markup.

    • Who would benefit:

    Everyone using the default editor

    • Proposed solution:

    The bar for special characters, quotation marks and wiki markup should be above the edit window. Or at least an option, to move it up.

    • More comments:
    • Phabricator tickets:

    DiscussionEdit

    The new toolbar does precisely that. Have you tried checking Enable the editing toolbar in your preferences in the Editing tab? Max Semenik (talk) 19:57, 15 November 2017 (UTC)

    Yeah, this functionality already exists. I'm going to archive this proposal; thanks for participating in the survey. -- DannyH (WMF) (talk) 18:49, 20 November 2017 (UTC)

    Automatic translations of Infoboxes

     N Not feasible for Community Tech

    • Problem: The translation of InfoBox standards like Speciesbox, chembox, Infobox biography takes long time and looks with no value added. Since the field are standards, the translation can be automatic cross wiki languages.
    • Who would benefit: All user doing articles translation cross wiki languages.
    • Proposed solution: Create a link in edit menu related with automatic translation of Infobox standards.
    • More comments: Development will improve the translations produtivity.
    • Phabricator tickets:

    DiscussionEdit

    Endorse. We need greater integration between languanges. This proposal is the very least we should aim to. B25es (talk) 19:26, 11 November 2017 (UTC)

    Are you talking about ContentTranslation? Doesn't it do that already if you have added the English parameter names via TemplateData? --Tgr (WMF) (talk) 07:43, 18 November 2017 (UTC)

    Hi SA RS BRASIL: Unfortunately, this proposal isn't feasible for our team -- infoboxes aren't actually standard across languages, so the first step would be synchronizing all infobox templates. You can see this page on Wikidata for more info: Wikidata:WikiProject Infoboxes. Thanks for participating in the survey. -- DannyH (WMF) (talk) 19:12, 20 November 2017 (UTC)

    Transwiki template

     N Out of scope for the team

    • Problem: Various same templates are used on different project usually imported a day from Wikipedia project. But template on Wikipedia where communities are more active are up dated while templates on other projects are not if administrator don't care about it.
    • Who would benefit: Every project users
    • Proposed solution: Creating a transwiki template function witch provide the use of Wikipedia's template on all project but without hindering template already present on projects to avoid traditional community protesting reaction to change.
    • More comments:
    • Phabricator tickets:

    DiscussionEdit

    Potentially related links: mw:Manual:$wgEnableScaryTranscluding, mw:Wikimedia Developer Summit/2017/Cross-wiki templates, translatable, reusable, manageable, phab:T6547, phab:T91162. --AKlapper (WMF) (talk) 20:40, 8 November 2017 (UTC)

    Other potentially related: phab:T22153, phab:T121470 Trizek (WMF). (talk) 09:27, 9 November 2017 (UTC)

    Maybe close to 2017 Community Wishlist Survey/Wiktionary/Share conjugation (among other things) templates on www.wiktionary.org proposal? Noé (talk) 19:45, 9 November 2017 (UTC)

    • Yes please!! Centrally hosted templates and Lua modules will solve the decade-long jumble that Wikidata is persuading us to solve. Deryck C. 21:48, 11 November 2017 (UTC)
    • I was always a big fan of this idea, but as a community developer i've encountered so much inter wiki problems lately, that i'm beginning to doubt the value in this. I see an increasing demand for control within wiki's and centralising things will put a lot more burden on individual template and module authors to balance the requests of those communities. We will thus see many forks, which will just move the problem to an area with less clear governance structures. Instead, maybe we should create a tool or something that makes it easier to compare versions/age/differences of these between wikis ? —TheDJ (talkcontribs) 15:09, 15 November 2017 (UTC)
    • The biggest problem with having global gadgets/templates is the fact that it's currently not possible to localize them. I like TheDJ's idea. Even something to do easy exporting/importing of templates between wikis (one-click buttons to "Update" templates by copying them from another wiki, for example) seems like a better idea for now until someone comes up with a brilliant idea for how we can localize templates and gadgets without making the wikis totally unusable for everyone. -- NKohli (WMF) (talk) 01:25, 18 November 2017 (UTC)
    • Localization is not hard (just use messages; see also T156210), but the visual flexibility of templates would be lost through centralization. Maybe the way to go is to centralize Lua modules but not templates? Large wikis seem to be moving towards mostly Lua-driven templates for the more complex use cases anyway, and for a library there are good ways to handle local variations. --Tgr (WMF) (talk) 11:48, 18 November 2017 (UTC)

    Hi Lionel Scheepmans: Unfortunately, this proposal is too big for our team; it's already been in the top 10 in a previous survey, and we had to decline. Sorry about that! Thanks for participating in the survey. -- DannyH (WMF) (talk) 19:32, 20 November 2017 (UTC)

    Ok Danny thanks. Lionel Scheepmans Contact French native speaker, sorry for my dysorthography 19:56, 20 November 2017 (UTC)

    Voice edit

     N Out of scope for Community Tech

    • Problem:

    Reading Wikipedia by (smart) mobile phone is convenient for many use cases. However editing Wikipedia on mobile phone is hard, partly because of the keyboard on (smart) mobile phone. Voice input in mobile phone would be a lot faster, but some specific functionality - such as wiki link - is not support natively.

    • Who would benefit:

    Most editors, who may find voice input is easier in a more mobile / ubiquitous computing world, in major languages with Speech-to-Text (STT) supports advanced enough (Vietnamese, my native language, is one of such languages)

    • Proposed solution:

    Support voice input for mobile - integrating with default voice input of the mobile OS (Android - Google service by default, iOS - Apple service by default) or can be setup by user to use their preferred STT service .

    By "support voice input", I mean, for example, Wikipedia application can allow certain "voice syntax" for wiki link. The syntax, beside default definition, can be setup by user to their preference.

    • More comments:
    • Phabricator tickets:

    DiscussionEdit

    Consider regional languages too-- Shagil Kannur (talk) 05:10, 11 November 2017 (UTC)

    An interesting idea. Worth to look deeper into it. If the devs think thay can make it work, why not? --Vachovec1 (talk) 18:34, 12 November 2017 (UTC)

    The way voice editing experiences like this have historically worked is that the person records what they want written, and then someone else transcribes it and makes any corrections necessary. Nowadays, voice recognition is generally good enough that the first person can use text-to-speech for automated transcription, but it will always require human checking due to the error rate. The only areas where human checking is not required are areas where small errors are not critical, and only short bits of speech are recorded to allow the user to easily correct themselves, such as Alexa, Siri, Duolingo, and similar. A fully text-to-speech driven environment, where the user also uses text-to-speech to correct previous errors, is possible, but tends to be so cumbersome to use that people only use them if they have no choice, such as blind users. Developing software solutions for this that work in a performant manner on mobile devices in the web browser is extremely hard, which is why the operating systems of phones typically include this in an integrated fashion. General text-to-speech solutions already exist in most modern mobile phones, and even in older or lower-spec phones used in emerging communities. Making a system that allows the user to use wikitext on top of that adds extra complexity, even ignoring the user customisation aspect. In short, this proposal has obvious value, but I think it's such a large undertaking that I don't see it happening within the scope of this wishlist. --Dan Garry, Wikimedia Foundation (talk) 12:35, 17 November 2017 (UTC)

    At WMSE we plan to have a project that will result in a tool for collecting speech data. This would be a first step in creating an open source ASR-solution for MediaWiki. It will be a follow-up to our current project Wikispeech, that allows the user to have an article read out loud. Keep an eye on the page for updates! /Sebastian Berlin (WMSE) (talk) 13:52, 20 November 2017 (UTC)

    Yes, as Deskana (WMF) said above, this is too big for the Community Tech team. I'll have to archive. Thanks for participating in the survey. -- DannyH (WMF) (talk) 19:33, 20 November 2017 (UTC)

    Additional Filters for Page History

    • Problem: Currently, when looking into the page history I can only filter for date and for tags. I can´t for example even filter for my own edits.
    • Who would benefit: Everyone looking into page histories.
    • Proposed solution: Add more filter options into the interface: show/hide my own edits (or if it's not deemed controversial, more generally show/hide selected account's edits), show/hide reverted edits, show/hide minor edits, show/hide bot edits, show/hide deleted edits (this filter would be of course for admins only), maybe others (see also the phabricator task linked below).
    • More comments:

    DiscussionEdit

    Please archive this as duplicate of 2017 Community Wishlist Survey/Miscellaneous/Add filters to edit history pages. --Vachovec1 (talk) 22:18, 18 November 2017 (UTC)

    Archived, thanks. Max Semenik (talk) 19:42, 20 November 2017 (UTC)

    Render external links in edit summaries

    • Problem: When an external link such as [https://www.google.com/ Google] is used in an edit summary, it renders as plain text instead of showing a link.
    • Who would benefit: Users who would like to make it easier to visit links.
    • Proposed solution: Make the external link syntax in wikitext also work in edit summaries as well.
    • More comments:

    DiscussionEdit

    Hi GeoffreyT2000: Unfortunately, there are spam and security risks involved in this idea -- somebody could put a malicious external link in an edit summary, and only oversighters are allowed to suppress other people's edit summaries. I'm going to archive this, thanks for participating in the survey. -- DannyH (WMF) (talk) 19:43, 20 November 2017 (UTC)

    Administrators can also revdelete other people's edit summaries. Legoktm (talk) 00:12, 26 November 2017 (UTC)

    Link mailing lists to on-wiki pages

    • Problem: The Wikimedia mailing lists are separated from on-wiki discussion pages, and many who participate in one won't participate in the other, leading to fragmented conversations.
    • Who would benefit: All who participate in discussions on topics where mailing list threads overlap with on-wiki discussions.
    • Proposed solution: Provide a system for two-way mirroring between mailing list posts and comments on a wiki page, so when a post is sent to the mailing list, a copy of the post is added to the wiki page, and when a comment is added to the wiki page, a copy of the comment is sent to the mailing list. In both cases, the posts should be automatically formatted appropriately for the medium and inserted into the relevant thread.
    • More comments: Many elements of this will likely be quite complicated, especially formatting mailing list replies to strip extraneous text and using that text to find the placement of the comment on the wiki page, but it's quite important to fix the current situation of discussions being split across forums, in my opinion.
    • Phabricator tickets:

    DiscussionEdit

    Hi Yair rand: Unfortunately, there are so many email services, and wikitext is so complicated, that this just isn't feasible for our team. I'm going to archive this. Thanks for participating in the survey. -- DannyH (WMF) (talk) 19:49, 20 November 2017 (UTC)

    Very much honor ideas which consolidate and centralize discussion. -Booksnarky (talk) 08:06, 8 December 2017 (UTC)

    Deploy Template CSS to enable mobile friendly meta-pages

    • Problem:

    Most of the meta pages in almost all of the wikis aren't optimised for mobile in perticulare or different screen sizes in general. One of the main reason for that is, that reagular Editors ar not allowed to use full feater CSS with in the pages. For them inline styles are the only way to create something like a layout. But inline-styles can't handle Breakpoints, relative styling, cascading -all the stuff necessary to create a truly responsive Webpage.

    This results in a situation, where a lot of meta-pages looks bad or don't work at all on smaller devices - leaving almost half of our readers with broken interfaces. A good example for this realy unsaitisfing situation are the german WikiLovesMonuments-Pages, that where accessed on mobile by half to 2/3rds of the readers, but failed on these plattforms, due to the limitations of inline styles.

    • Who would benefit:

    All Readers not using Desktops The Editors designing meta-pages

    • Proposed solution:

    Deploy the Template-CSS-Extension to all Wikipedias ASAP (we really need that for the upcoming WLE and WLM campaings latest)

    • More comments:
    • Phabricator tickets:

    Project TemplateStyles

    DiscussionEdit

    Hi @Martin Kraft:, this project is already being worked on by the Reading team. I'll close this proposal since another team is already on it. Thanks for your proposal. -- NKohli (WMF) (talk) 19:53, 20 November 2017 (UTC)
    @NKohli (WMF): Any information on a realistic release date for the extension on German Wikipedia? // Martin Kraft (talk) 11:02, 27 November 2017 (UTC)
    I'll ping Tgr (WMF) about that since I don't work on that team or project. -- NKohli (WMF) (talk) 12:28, 27 November 2017 (UTC)
    Probably December for wikis which opt in early (see T168808), not sure after that. Please add any relevant deadlines your community has to T133410. --Tgr (WMF) (talk) 19:30, 27 November 2017 (UTC)

    Making Meta pages translatable by default

    • Problem:

    Current system is difficult to understand, hard to find and not user friendly. Only true insiders know what has to be done to make things multilingual in Meta.

    • Who would benefit:

    Everyone, but mainly the community, who could have a culturally richer and more diverse system.

    • Proposed solution:

    Making everything translatable by default.

    • More comments:
    • Phabricator tickets:

    DiscussionEdit

    • It sound like you are asking you to make the system easier rather than just applying the current tool more widely as it is currently. I do agree with making it easier to use. See for example Phab:T131516 and numerous other tasks saying the same from a different point of view. –Nikerabbit (talk) 09:32, 15 November 2017 (UTC)
    • I agree on the sentiment. To make sure that "everything" also contains important content, we also need to make sure that e.g. Wikimedia Foundation content doesn't move to untranslatable spaces outside of the wikis. Currently an efficient multilingualism doesn't seem to be a criterion in communication decisions, see Talk:Wikimedia_Foundation_website/2017_update#Multilingualism. --Nemo 11:29, 15 November 2017 (UTC)
    • The translation markup makes pages very hard to edit, makes template updates impossible without templateadmin rights, breaks various editors etc. It is bad to the point that some people claim their documents to be in a perpetual draft state just to prevent others from translating them. Only high-value pages should be subjected to that kind of maintenance burden. --Tgr (WMF) (talk) 00:19, 19 November 2017 (UTC)
      I believe that per our values a better conclusion is that the system must be improved to reduce maintenance burden so that it can be used wherever needed. –Nikerabbit (talk) 08:51, 20 November 2017 (UTC)

    I agree that making the Translate extension easier to use is a good proposal, but that's not what this proposal is asking for. Making the existing translate system automatic would be unfeasible for the team. I'm going to archive the proposal. Thanks for participating in the survey. -- DannyH (WMF) (talk) 19:59, 20 November 2017 (UTC)

    Provide Editors with online private space

    • Problem: Currently users must store large amounts of data on their own computers/smartphones/whatever even when such data relates directly to their wiki work. Ideas are sometimes lost when a user has no access to their regular storage media, but not everyone can afford or has the freedom to carry their own individual storage gadgets around
    • Who would benefit: Users working on long term projects which they prefer to keep private for the time being / the wikis those users contribute to
    • Proposed solution: Provide a private namespace where editors can store private information which they do not want to share with the rest of the world until it is ready for publication
    • More comments: This idea has been plagiarized from (the defunct?) Yahoo Groups where users were provided various online storage spaces which could be designated as private. It was great because it allowed participants to store information no matter where they were editing from: home, work, school, etc.
    • Phabricator tickets:

    DiscussionEdit

    This proposal seems somewhat vague. What kind of data are you talking about? Private drafts, private file storage? How do we avoid it becoming a new way to store copyvios? Some Wikipedia Zero users are already using us as their free Youtube - wouldn't having private storage only make this problem worse? Max Semenik (talk) 21:37, 18 November 2017 (UTC)

    We already have private storage for ContentTranslation and Phabricator drafts, and stashed uploads, so a new private area wouldn't really make that problem worse. OTOH as long as the private storage is not really integrated with the workflow (the way e.g. drafts are), why not just one of the many external solutions (Dropbox, Google Doc, whatever) instead of investing effort into something that will have a fraction of that functionality? --Tgr (WMF) (talk) 22:51, 19 November 2017 (UTC)

    No. MER-C (talk) 03:13, 19 November 2017 (UTC)

    • phab:T161952 seems related off the cuff; I'm fairly certain I've seen some dedicated discussion to this before 2017, though I'm not going to go hunt. --Izno (talk) 04:35, 19 November 2017 (UTC)

    Is this a page which would only be viewable by the user and admins? In that case I think that copyvios would be less of a concern, and might be covered by the "private research" exemptions in some territories. Availability of the page would need to be restricted to "regular editors" by some criteria. AlasdairW (talk) 15:43, 19 November 2017 (UTC)

    • Hi Ottawahitech, I think this is too complicated for our team to take on. There are potential legal concerns, and we're going to have to decline. Thanks for participating in the survey. -- DannyH (WMF) (talk) 20:55, 20 November 2017 (UTC)

    Improve DNS- and TSL(SSL)security

    • Problem: Wikipedia is used around the world. Unfortunately not every country is a democracy and a constitutional state, but many countries are dictatorships and/or have no citizen rights (or not enough). Many of these countries (and a few of the democratic too) try to spy their own burghers, and which Wikipedia pages somebody reads (or what he writes about his leaders) is of course interesting for these bad countries.

    While Wikipedia uses TLS (also knows as SSL) since a few years, this is not enough. Because many of these bad countries run default-trusted Certification Authorities (CA), which are able to generate certificates for every domain they like – including Wikipedia.

    • Who would benefit: In theory every users of Wikipedia (reader and writer), but especially users in non-free-countries.
    • Proposed solution: Implement DNSSEC for the DNS of the Wikipedia-domains as a first step. Than add TLSA-records (also known as DANE) to the DNS to secure the TSL. Then the users can install a plugin in their browsers that will warn them if somebody tampers with the TSL-certificate.
    • More comments: The work (without testing and documentation) should need less than 1 day. I can offer help, if needed.
    • Proposer: DaB. (talk) 20:52, 6 November 2017 (UTC)

    DiscussionEdit

    • Contrary to the proposer's claim that this is a very easy thing to do, the WMF operations team considers this a serious amount of work because our current DNS server - gdnsd - doesn't support this. Max Semenik (talk) 23:34, 6 November 2017 (UTC)
      That sounds like a great opportunity to improve our infrastructure while also supporting 3rd party free software. :) Having the primary author of the said software onboard can only help, right?--Strainu (talk) 13:22, 7 November 2017 (UTC)
    • The author of gdnsd (BBlack) opposes DNSSec and has no plans to implement it. S/he points to this page as to why DNSSEC is a terrible thing. --stranger195 (talkcontribsguestbook) 09:44, 9 November 2017 (UTC)
    • Speaking of which I recall there were a period of time that Wikipedian in China was asking for exemption or deferral in SSL connection on Chinese Wikipedia because at the time Wikipedia article on some topics can still be accessed within mainland China as long as there are no targeted keywords but it would be inaccessible at all if HTTPS connection is usedC933103 (talk) 23:47, 12 November 2017 (UTC)
    • Maybe better to frame this as a problem statement (preferably in such a way that the average voter can understand what the problem is) instead of suggesting a specific solution? There are alternatives other than DNSSEC/DANE (e.g. HPKP preload, although HPKP is has its own problems and we don't plan to do it either) or - to some extent - Expect-CT. --Tgr (WMF) (talk) 21:01, 18 November 2017 (UTC)

    ArchiveEdit

    The Operations team doesn't have resources to work on DNSSEC and we at Community Tech can't do it on our own. Additionally, DNSSEC is an outdated standard on its way out. Its browser support only decreases because it's pretty much predates proper TLS and have never been developed further. TLS itself was designed to handle unsafe DNS so there's virtually no extra security that DNSSEC would add in any case. Thanks for participating in our survey. Max Semenik (talk) 21:16, 20 November 2017 (UTC)

    Establish global volunteer availability registry

    • Problem: Many smaller wikis are starved for volunteers / many editor volunteers are starved for work they are interested in performing
    • Who would benefit: smaller/ lesser-known wikis that suffer a shortage of certain types of volunteers / editor volunteers who are looking for new challenges
    • Proposed solution: Proposed solution: establish a central registry where editors can post their qualifications/ limitations / requirements, sort of like a job website, and allow editors to shop for new/additional volunteer jobs.
    • More comments: Am I making sense?
    • Phabricator tickets:

    DiscussionEdit

    Does this require any software development? If so, what kind of development? Can this be achieved with a simple wiki page? Max Semenik (talk) 23:45, 9 November 2017 (UTC)

    It's an interesting proposal, Ottawahitech :) My team has been inviting contributors to all kinds of volunteer paths for a long time now, from tech ambassadors to tech translators, from visual editor experts to Structured Data Commons enthusiasts. I think we still need better integration into Wikimedia Resource Center, and your proposal probably also goes into that direction. Elitre (WMF) (talk) 15:42, 13 November 2017 (UTC) PS: The "simple wiki page" would still need design, usability tests, etc.

    Hi Elitre, I have not had a chance yet to look into any of your links which look really interesting, but wanted to reply here first. I have been participating in some less well travelled wikis in the last couple of months and sometimes it feels like travelling in foreign lands. After the hectic pace of en.wikipedia I first thought it was a piece of cake to participate in wikis where one can count the number of daily recent edits on one’s fingers (sometimes also toes). That was until I discovered that some of those wikis have histories (and ghosts who come alive) that must be unravelled before one is allowed to participate…
    Back to the topic at hand, matching volunteers to wikis that need them. Yes it is a complex problem. Just like employers always complaining about how they just cannot find "qualified" workers, and at the same time unemployed people are complaining that employers who are said-to-be-hiring but do not even acknowledge people who submit a resume.
    I am not sure who should take the intiative to post a request: the wiki that needs workers , or the editors looking for (additional) work. Admins who run wikis are way too busy and rarely have the time, let alone the awareness of their need, to think about what type of volunteers they want and what qualifications those volunteers need. Just like employers who rely on their social network when picking new employees, they are more likely to rely on editors they already know and try to poach them, instead of getting editors who are available…
    Oops, my TLDR-meter has expired long ago, thanks for pinging me. Ottawahitech (talk) 13:53, 14 November 2017 (UTC) Please ping me
    I believe your request may also be related to existing efforts. The first that comes to mind, for example, is Community Capacity Development. I will also ping User:Asaf (WMF) in case he wants to weigh in. Best, Elitre (WMF) (talk) 14:35, 14 November 2017 (UTC)

    Hi Ottawahitech: This isn't really a technical request; it's more about building community support for an initiative. We're going to have to archive this. Thanks for participating in the survey. -- DannyH (WMF) (talk) 21:12, 20 November 2017 (UTC)

    Transition from templates to metadata

      Good idea, but not feasible until we have multi-content revisions available.

    • Problem: как опознать статью, имеющую те или иные свойства, например: содержащую орисс или копивио, слишком короткую, не имеющую иллюстраций, являющуюся заготовкой по такой-то теме, избранную или добротную, являющуюся дизамбигом и т.д.? Никак По шаблонам, вписанным прямо в код статьи! Такое решение, во-первых, неочевидно, во-вторых, легко вандализируется, в-третьих, не позволяет искать статьи по параметрам. Как мне найти все заготовки статей о горах, имеющие размер больше 5 КБ и не имеющие источников? Или как найти все добротные статьи без иллюстраций? Или все дизамбиги больше 10 КБ? Никак, это абсолютно невозможно. Существует некий инструмент поиска по пересечению категорий, но он откровенно убог и позорен, это уровень урюпинского колхоза "Красный Пусть", а не самого посещаемого в мире сайта.

    Translation: how to identify an article having certain properties like whether it contains original research or copyright violation, too short, lacking illustrations, being a stub, featured or good article, disambiguation page, etc? You can't By templates right in page text! Such solution is unobvious, easy to vandalize and doesn't allow you to search articles by parameters. How do I find all stubs about mountains having size over 5kb and having no sources? Or how do I find all good articles without illustrations? Or all disambiguations over 10kb? You can't, it's absolutely impossible. There's a certain category intersection tool, but it's not suitable for the world's most visited website.

    • Who would benefit: все редакторы и читатели. Translation: all editors and readers.
    • Proposed solution: предлагается уичтожить все шаблоны заготовок, дизамбигов, статусных статей, а также плашки с предупреждениями. Вместо этого предлагается создать параметры статей, которые редактировались бы отдельно от исходного кода (или параллельно с ним).
    1. Автоматические количественные параметры: статистические данные, которые невозможно править вручную. Например: размер статьи в байтах и символах, число правок в истории, средний размер правки, дата создания и т.д.
    2. Ручные бинарные параметры: свойства, принимающие значения "да/нет" (или 1/0, кому как привычнее). Содержит ли статья рекламный стиль? А машинный перевод? Была ли на ЗЛВ? Предлагалась ли к удалению? Если указан параметр "да", то над статьёй появляется соответствующий небольшой значок (если параметр некритичен, например, факт прежнего выноса к удалению, но не появляется). Эти параметры могут иметь свойства. Например: параметр "заготовка" или "дизамбиг", выставленный в положение "да", может иметь свойство "тема". Остальные параметры в качестве свойства могут иметь поле для произвольного комментария. Если параметр "вынесено к удалению" стоит в положении "да", то над статьёй появляется аккуратная красная полоса со ссылкой на дискуссию.
    3. Ручные многофакторные параметры: устанавливаются вручную и имеют несколько значений. Например: статус статьи (ДС/ХС/ИС/ИСП/нет), уровень важности (низкий/средний/высокий/высший) и т.д. Ручные параметры могут редактироваться всеми участниками, но некоторые можно защитить до администратора во избежание вандализма или случайных ошибочных действий.

    Одновременно с этим запускается поиск по параметрам, где можно будет искать статьи по произвольному набору параметров.

    Translation: I propose to eliminate all the stub, disambiguation, article status and issue templates. Instead, I propose to create article parameters that would be editable separately from wikitext (or concurrently with it).

    1. Automatic numeric parameters: statistical values that are impossible to change by hand. For example, article size in bytes and characters, number of edits, average edit size, creation date, etc.
    2. Manual binary parameters: properties that take "yes"/"no" values (or 1/0, whichever is most convenient to one). Does this article contain promotional language? What about machine translation? Have in been shown at Did You Know? Have it been nominated for deletion? If a parameter is set to "yes", a small sign appears above the article (if the parameter is non-critical e.g. whether it was nominated for deletion, it doesn't appear). These parameters could have properties. For example, a "stub" or "disambiguation" parameter could have a topic property. Other parameters could have an arbitrary comment field. If the "was nominated for deletion" parameter is set to yes, a neat red bar with a link to discussion appears above the article.
    3. Manual multifactor parameters: set by hand and can have one of multiple values. For example, article status (featured/good/none), importance (low/medium/high/top) etc. Manual parameters can be edited by by all editors but some could be admin-protected to avoid vandalism or mistakes.

    At the same time release parametric search that would allow searching by arbitrary set of parameters.

    • More comments:
    • Phabricator tickets:

    Community discussionEdit

    Article metadata requests like that are probably dependent on the ongoing Multi-Content Revisions project (see especially the "Use Cases" section), which is huge and complex. This might be a better wish for next year's wishlist IMO. --Tgr (WMF) (talk) 23:41, 18 November 2017 (UTC)

    @Фред-Продавец звёзд: Agreed. This is a great idea, but it requires Multi-Content Revisions which won't be available for a while. Hopefully we'll be ready to do this by next year's survey. Please repropose it then! Ryan Kaldari (WMF) (talk) 21:30, 20 November 2017 (UTC)

    Who to whom in the Flow

    • Problem: In the big discussions in the Structured Discussions (Flow), the conversation turns into a wall of text. And it is not easy to understand who is talking to whom, since the answer to the last comment in the branch and the answer to the first message of the branch will be the last comment in the branch.
    • Who would benefit: Readers of discussions
    • Proposed solution: Store in the comment data about clicking on which "Reply" it was created. When you hover over the child comment, additionally show the author's nickname of the parent comment (when you click on it to scroll to the parent comment) and highlight the parent comment. e.g.
    • More comments:

    DiscussionEdit

    • Just getting rid of the atrocious system of ‘structuring’ the Structured Discussions would help a lot more in solving issues with understanding the system. No other comment system does have an approach more complicated than this add-on (not an extension) on wiki engine. stjn[ru] 15:42, 11 November 2017 (UTC)
    • It would help if replying to the last message in the flow would actually indent instead of simply a new message C933103 (talk) 23:56, 12 November 2017 (UTC)
    • I like this idea, and it is very common in other discussion systems as well, that there is an indicator of who you are replying to, or even allowing you to quote a particular fragment. I'd welcome such a change. Indentation is limited and people don't consider how that works on mobile viewports, so I do not consider indentation a complete solution to this problem. —TheDJ (talkcontribs) 13:35, 15 November 2017 (UTC)
    • The first half of this wish seems to be T174371 (that was one of the Q1 goals; can't really tell what state that ticket is in though). Doing the recording bit ASAP seems common sense to me; it is impossible to backfill that so we are losing data every day it is not deployed. (The other half feels to me like an important thing but not particularly urgent compared to things like search support, human-readable page titles, proper history... ) --Tgr (talk) 04:43, 19 November 2017 (UTC)
      • Yes, this is mostly done (I.e. it is storing the "reply-to" accurately in the database), and final fixes are being worked on. I'll archive this proposal (but leave your other proposal open) as it only relates to the backend changes. I'll ask the team to update those tasks for clarity. Quiddity (WMF) (talk) 22:25, 20 November 2017 (UTC)
        • @Quiddity (WMF): It's mostly about the frontend. I would like to see clearly the relationship between the post-original and the post-reply. In contrast, the task T167928 says only "is not displayed for now". --Sunpriat (talk) 00:38, 21 November 2017 (UTC)
          • @Sunpriat: Sorry, I was unclear and incomplete. I meant: your other proposal, 2017 Community Wishlist Survey/Miscellaneous/Multilevel Structured Discussions, better encompasses any frontend changes (plus everyone (including the team) already wants to fix the current frontend output). It is not needed for anyone to vote on this, for something like this to be done - how exactly it gets changed, is a more complicated discussion than a single wishlist idea can resolve. I hope that helps clarify. Quiddity (WMF) (talk) 01:07, 21 November 2017 (UTC)

    Integrate Pattypan and Quick Statements (Placeholder)

     
    Mapping for Commons artwork template vs Wikidata item for a painting

    Since it was proposed under Wikidata, I assume it should be left there, but the main issue was proposed last year under the Commons group here: 2016_Community_Wishlist_Survey/Categories/Commons#Upload_wizard_for_uploading_artwork

    • Who would benefit: Commons uploaders and Wikidata item curators for paintings and other artworks
    • Proposed solution: The title says it all; but maybe it should also say "Commons UW & Quick Statements". Basically you want an easy way to upload the metadata of an image to both Wikidata and Commons at the same time (given there is generally overlap for 90% of the metadata, the stuff not in overlap could be defined in some sort of "user profile" or "upload campaign".
    • More comments: please comment on the initial proposal under Wikidata; this is just a placeholder
    • Proposer: Jane023 (talk) 11:35, 15 November 2017 (UTC) (for findability)

    DiscussionEdit

    Please comment on the initial proposal under the group heading Wikidata, not here 2017 Community Wishlist Survey/Wikidata/Integrate Pattypan and Quick Statements

    Archived as a duplicate. Max Semenik (talk) 22:32, 20 November 2017 (UTC)

    UTRS for Wikimedia Commons.

    • Problem: Currently if someone is blocked on Wikimedia Commons with their
    • Who would benefit: Everyone, (1) the blocked users have another way to appeal, (2) the Stewards as they are the only option Wikimedia Commons blocks can be appealed to if users can’t do this locally, basically serving as a substitute arbitration committee for Wikimedia Commons, and (3) every Wikimedia project, as they’re all dependent on Wikimedia Commons for their imagery and other free and open files, and having good photographers and other people return would greatly benefit any lover of (visual) knowledge.
    • Proposed solution: Create a UTRS for Wikimedia Commons, this one would work practically the same as the one on English Wikipedia. This would immediately be an option between contacting administrators locally and contacting “the stews”.
    • More comments: I'm personally not a fan of the system (as administrators can only basically give one answer which is the w:en:WP:SO without ever addressing a single point), but if this gets any users who would've otherwise not been able to appeal their blocks unblocked and help have more good photographs uploaded then even if this would only get 1 (one) photographer unblocked it would be an amazing thing.
    • Phabricator tickets:

    DiscussionEdit

    Hey Donald Trung, you'd probably want to briefly explain what a UTRS is and how it works. Those not familiar with it on English Wikipedia will probably not support something they don't understand what it is. (: /Johan (WMF) (talk) 23:06, 9 November 2017 (UTC)

    • Do you have a consensus from the Commons community that they want it? Otherwise, there's nothing for developers to act upon. Max Semenik (talk) 00:28, 10 November 2017 (UTC)

    Ping Donald Trung – see comments above. /Johan (WMF) (talk) 16:05, 20 November 2017 (UTC)

    ArchivedEdit

    No evidence that Commons administrators are interested in this. Thanks for participating in our survey. Max Semenik (talk) 23:02, 20 November 2017 (UTC)

    Category title in suitable language

    • Problem: I'm french user (sorry for my English). In Commons, my account specifies the french language. But, the categories titles are displayed only in the language used by the creator of the category (I speak about categories, but the problem is similar for other elements). I can understand this behavior when there is no information about translation, but if contributors (like me) fill the locale models like {{Translation table}} or {{fr}}, these texts are not taken in account for title display (only in content) or search.
      For concrete case, if I search "category:Heraldry", I find. If I search french equivalent "catégorie:Héraldique", I can't find the category. If I search "category:Héraldique", I find a duplicated category. If I search in the search tool, I can find the relevant category at the 371st position.
      For me, this problem encourages users to create duplicated categories in different languages and it is not a good thing for contributors and visitors speaking only one language. It is not pleasant to search in Commons with a bilingual dictionary in the hands.
      The problem is also the same in the list of subcategories. It will be preferable to see the translated version of the category title instead of the original title.
    • Who would benefit: Contributors and visitors will be interested by this feature.
    • Proposed solution: I think that the problem is linked to the data structure of Commons. Maybe it is possible to define the list of models usable for translation and use them.
    • More comments:In fact, I would like to see a similar behavior to Wikidata where it is possible to search, find and see the elements with a text in my language (when defined of course).
    • Phabricator tickets:

    DiscussionEdit

    I think this problem will be fixed next year. If the tech team will follow their road map, they should test to apply Wikidata on Commons in 2018. Than offcourse category would be in whatever language.--Juandev (talk) 20:44, 9 November 2017 (UTC)

    The Structured Data on Commons team is planning to implement structured data fields in late 2018 as part of the Structured Data on Commons program. Many of the currently unstructured fields will be structured and translatable, (depending on what the Commons community wants, but it might look something like this.) In that case, for a file that depicts heraldry, the field for "Depicts" would display as "Heraldry" in English, and "Héraldique" in French, (as long as both languages are listed in the item for heraldry). Abittaker (WMF) (talk) 19:32, 13 November 2017 (UTC)

    Hi Jpgibert: As Abittaker says, the Structured Data on Commons team is already working on this! I'm going to archive this proposal. Thanks for participating in the survey. -- DannyH (WMF) (talk) 23:12, 20 November 2017 (UTC)

    Extension:Translate for Wikimedia Commons images

    • Problem: There are Over 365 000 images on Wikimedia Commons with no description. Many more are without descriptions in various languages. Adding these descriptions is painfully slow, but the Translate extension used well in Translatewiki can make a) adding descriptions much simplier, b) translating descriptions even more simplier. With such a thing implemented (and yes, it is already present on Meta, where it serves really well.
    • Who would benefit: Wikimedia Commons editors and translators.
    • Proposed solution: Installing the Translate MediaWiki extension on Wikimedia Commons. Making it possible so that Special:Translate can display files from a selected category with possible editing windows for new translations.
    • More comments:
    • Phabricator tickets:
    • Proposer: Aktron (talk) 22:14, 8 November 2017 (UTC)

    DiscussionEdit

    The Translate extension is already installed and is in use on Commons for template internationalization (see for example the big blue button on Template:Welcome). However, file descriptions use a very different format, so the way it works there should be implemented. (Good idea though, if the developers can get it work.) --Tacsipacsi (talk) 22:19, 8 November 2017 (UTC)

      Question: Won't this be a non-issue with the integration of Wikibase in Commons? NMaia (talk) 00:51, 9 November 2017 (UTC)

    Yup, that is an unknown space, how file editing will work after data integration.--Juandev (talk) 09:39, 9 November 2017 (UTC)
    As per my understanding, Wikibase will make the data more structured, but not easier to translate large number of descriptions. Integration with the Translate extension would still be useful. –Nikerabbit (talk) 15:24, 9 November 2017 (UTC)
    Well if I am thinking again about it, Wikibase will structure date, which can be structured. So e.g. categories and they (WMF) will hopefully develope the way how to add translations to different languages just within WMC. But in the case of descriptions, they have no way to change this object, so here could be integrated the technology of Translatewiki (which is realy good :-)--Juandev (talk) 20:37, 9 November 2017 (UTC)
    The Structured Data on Commons team is planning to implement translatable fields in late 2018 as part of the Structured Data on Commons program. Many of the currently unstructured fields will be structured, (depending on what the Commons community wants, but it might look something like this.) So many of the fields, including the description, could be translatable within Commons. Abittaker (WMF) (talk) 17:31, 13 November 2017 (UTC)

    ArchivedEdit

    This will be solved as part of Structured data work which is already prioritized, no need to vote on this. Max Semenik (talk) 23:14, 20 November 2017 (UTC)

    Image recognition and tagging

    • Problem: Image description and categorising is way too long work, that many users, don't do it.
    • Who would benefit: Wikimedia Commons, Wikipedia, contributors
    • Proposed solution: There are two solutions, which may be used alone, or combined. One is to retrieve some information from GPS. If the GPS is harvested by camera, it is usually not correct, but we can get an estimate for a place, where picture was taken (in which settlement (village, municipality)). This estimate may be written to the file description and from this estimate can be created a category. At the same time, we may tag those files with a template announcing this technology was used and this information should be controlled by a human. If the coordinates are set manually the guess is more precise more likely correct.

    The other technology is the image recognition provided e.g. by Google, which recognised basic objects (church).

    Combination of these technologies, may provide better recognition (Church of St. Peter).

    • More comments:
    • Phabricator tickets:

    DiscussionEdit

    As someone who categorizes images, I welcome any information that can be generated automatically from the GPS coordinates. Often the building or village name is not enough. Sometimes the city name is not enough. The Panoramio and Flickr tags are often not enough. I have to know the province or district or country name, and the only way to find that is to load a Google map. I agree that the automatically generated information should be tagged as temporary within the file, or alternatively the image should be placed in a category requiring human attention. Downtowngal (talk) 03:16, 9 November 2017 (UTC)

    Yup, thats correctly said: category requiring human attention.
    Anyway if you have a village name, we/they can automate to provide categories of higher administrative units, as we are able to write a code, which will do it.--Juandev (talk) 09:37, 9 November 2017 (UTC)
    Even having a country or region name would be useful in order to narrow it down. Commons has a huge backlog of uncategorized images and media, some of which could be auto-tagged based on GPS info, and then placed in commons:Category:Media_needing_category_review (or perhaps even location-based subcategories, for instance, "Media needing category review geotagged in India") for human review. Dragfyre (talk) 18:26, 9 November 2017 (UTC)
    I have been just a little bit digging in this area. Coders know two ways of recognition and tagging. One is provided by Google. They provide 1000 image/month/user in Google Cloud for free and than each image for some cents of USD. But I have seen around internet other companies, who work on recognition. As far as I know, they work for business and develop recognition for them. So the technology of image recognition is probably widely know. I don't think so, our devs of WMF would work on its own recognition bot, but we may test the technology on those 1000 free recognised images by Google and then if there is a high success rate WMF may negotiate a partnership and negotiate some mass usage.
    The other way of recognition is done somehow via search and I don't know much about it, how it works, I have seen just an example. I guess weather this harvest all available data and metadata about our image (image on Wikimedia Commons) and than using the algorithm to try to find out most probable depiction. But this is just guessing. Maybe they do it via coords, because there is free tool called Jeffrey's Image Metadata Viewer, which do this work using coords of the images and different map application, to name photographer position. In this case you get the house number. So the expample for the file.jpg might be: Czech Republic, Klatovy Region, Klatovy District, Train Street no. 44, i.e. Country, NUTS x, NUTS x, Street, House number.
    But the question is how precise is the automate coordination harvest. For those, who add coords, getting them from satellite imagery and adding also the way of which the photograph was taken, may this be very useful and precise. I wonder if we are able to write the address of the photographer position in words, that it might be possible to write other objects in words using POI (like Church of St. Peter). There is also a technology, which can show and write down all objects in the way in which photograph was taken. It can also remove non visible objects caused by elevation, but it probably is not ably to hide non visible objects, behind human construction. So, if there is a picture of house and there is a Church of St. Peter behind this house, but it is not visible on this image, because the house hides it, the code is able to say there is the Church in the range, but I am not sure if the code can also say that in this case is not visible, because there is a house in behind. This tool is called Hey Whats That!--Juandev (talk) 20:29, 9 November 2017 (UTC)
    In the case of location tagging, categorization needn't be too precise. Geotagging on some phones isn't always so accurate in the first place; if you're in an area with poor cell coverage, for instance, a photo you take might be tagged with a location that's several kilometres away from your actual position. In most cases, though, it'll at least be in the same country or region: The coordinates may not tell me the correct street or town it was taken in, but I may know it's in Maharashtra, which is in India. Even drilling down this far will help a great deal with categorization. Dragfyre (talk) 18:34, 10 November 2017 (UTC)
    I support Dragfyre's suggestion of location-based subcategories "media...geotagged in India." For popular names like "San Fernando," that tells us which country it is in. It directs people with expertise in that country to work on that subcategory. However, for countries with many English-speaking Wikipedians who participate as uploaders and categorizers, a lower level subcategory (state, province, region) would speed up categorization. If I know that all the images are in, for example, Florida, my work will be faster than if I only know they are in the United States. I have a question about this proposal. Often people upload several images from one location. Will there be a way for the categorizer to know that images 4, 19 and 25 tagged "Florida" are from the same upload, without looking at each individually? Can we at the same time be shown a map with the geotagged but unclassified images pinpointed, like Open Street Map? Downtowngal (talk) 01:50, 10 November 2017 (UTC)
    A map would be a huge plus, but at the same time, I think I'd be happy with a tool that does the categorization. I seem to remember that there are some geotagging tools that will show you all the images in a certain category on a map. I'll have to look it up. Dragfyre (talk) 18:40, 10 November 2017 (UTC)
    I want to add something to my comment. The tool used should harvest information from Google or another map that provides all the information (village name, region name, etc.) in English. Why? I want the English spelling of place names, because most of the time Commons categories use English spelling of place names. I don't want a map that uses only the local language, like OpenStreetMap, and generates names with their local language spelling. That is not much help. Downtowngal (talk) 01:37, 10 November 2017 (UTC)
    As long as Google's API is usable for these purposes, I suppose. There might be a possibility of incorporating data from Wikidata, too; locations there are generally tagged with their coordinates. Dragfyre (talk) 18:40, 10 November 2017 (UTC)
    I just had an idea. Is it possible to sort the images in "media needing category review geotagged in India" by coordinate? I think that ability would be useful to a person who categorizes images. That way, all the images from a single village will be close together. Downtowngal (talk) 01:58, 10 November 2017 (UTC)
    Good idea. Dragfyre (talk) 18:40, 10 November 2017 (UTC)
    To sort images from Florida by uploader should be possible. Such options have allready "Perform Batch Task".--Juandev (talk) 22:09, 10 November 2017 (UTC)
    But I want to sort only images from Florida that have not already been categorized. If the uploader has been active earlier, some of their uploads may already be categorized. Can I restrict my sorting to images in "media needing category review geotagged in Florida"? Also, please remember that the tools should be easy to use for people who are not IT specialists and who are not native speakers of English. I am a layperson and I am afraid to "perform batch task" because if I make a mistake I don't know how to fix it.