Wikimedia Meta-Wiki

Community Wishlist Survey 2017/Archive

< Community Wishlist Survey 2017

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 discussion edit

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

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

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:

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

Community discussion edit

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

Archived edit

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

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 discussion edit

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

@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 discussion edit

Archived edit

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

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 discussion edit

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

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 discussion edit

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

User watchlist

 N Declined in a previous survey

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

Community discussion edit

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

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

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 discussion edit

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

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

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

    Archived edit

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

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

    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 discussion edit

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

    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:

    Discussion edit

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

    Voting edit

    → 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 discussion edit

    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

    Discussion edit

    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:

    Discussion edit

    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.

    Discussion edit

    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:

    Discussion edit

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

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

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

    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:

    Discussion edit

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

    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:

    Discussion edit

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

    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:

    Discussion edit

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

    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

    Discussion edit

    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:

    Discussion edit

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

    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:

    Discussion edit

    @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)[reply]
    This is an example of notes.--Juandev (talk) 21:04, 8 November 2017 (UTC)[reply]
    @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)[reply]
    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)[reply]

    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:

    Discussion edit

    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:

    Discussion edit

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

    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:

    Discussion edit

    Could you add an example (link) where this is currently being used ? —TheDJ (talk • contribs) 00:03, 10 November 2017 (UTC)[reply]

    @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)[reply]
    Since the above patch has been merged, this wish is resolved. Max Semenik (talk) 19:18, 13 November 2017 (UTC)[reply]

    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 discussion edit

    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:

    Discussion edit

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

    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:

    Discussion edit

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

    @ديفيد عادل وهبة خليل 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)[reply]

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

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

    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:

    Discussion edit

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

    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:

    Discussion edit

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

    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:

    Discussion edit

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

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

    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:

    Discussion edit

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

    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:

    Discussion edit

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

    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:

    Discussion edit

    @ديفيد عادل وهبة خليل 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)[reply]

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

    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:

    Discussion edit

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

    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:

    Discussion edit

    @ديفيد عادل وهبة خليل 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)[reply]
    @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)[reply]
    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)[reply]
    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)[reply]
    This seems like a duplicate of 2017 Community Wishlist Survey/Watchlists/More Options for Auto-Watching. Anomie (talk) 16:51, 13 November 2017 (UTC)[reply]
    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)[reply]

    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:

    Discussion edit

    @ديفيد عادل وهبة خليل 2:. What do you mean by "included pages"? -- NKohli (WMF) (talk) 19:20, 10 November 2017 (UTC)[reply]
    @NKohli (WMF): See "MediaWiki:Centralnotice-templates-included".Thank you --ديفيد عادل وهبة خليل 2 (talk) 19:24, 10 November 2017 (UTC)[reply]
    I still don't understand. You want to watch transcluded pages/templates? -- NKohli (WMF) (talk) 19:26, 10 November 2017 (UTC)[reply]
    @NKohli (WMF): I mean pages whose names are between {{}} --ديفيد عادل وهبة خليل 2 (talk) 19:43, 10 November 2017 (UTC)[reply]
    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)[reply]
    @NKohli (WMF): The target is the nomination pages which voters are interested in following --ديفيد عادل وهبة خليل 2 (talk) 20:37, 10 November 2017 (UTC)[reply]
    You will watch thousands of transcluded pages. IKhitron (talk) 11:59, 13 November 2017 (UTC)[reply]
    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)[reply]

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

    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:

    Discussion edit

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

    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:

    Discussion edit

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

    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:

    Discussion edit

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

    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:

    Discussion edit

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

    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:

    Discussion edit

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

    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:

    Discussion edit

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

    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:

    Discussion edit

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

    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:

    Discussion edit

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

    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:

    Discussion edit

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

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

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

    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:

    Discussion edit

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

    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:

    Discussion edit

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

    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:

    Discussion edit

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

    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:

    Discussion edit

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

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

    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:

    Discussion edit

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

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

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

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

    Archived edit

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

    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:

    Discussion edit

    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    I see, DannyH. Thank you. IKhitron (talk) 21:01, 14 November 2017 (UTC)[reply]

    Live Clock

    • Problem: It would be nice to have a Wiki command {{Clock|Form|Country}}
    UTC date and time:
    Tuesday
    April
    8:21 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:

    Discussion edit

    How? (yep totally asking for my userpage) A Den Jentyl Ettien Avel Dysklyver (talk) 14:59, 9 November 2017 (UTC)[reply]
    @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)[reply]
    @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)[reply]

    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:

    Discussion edit

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

    I did not poll, I do not know how to poll all users who need transitivity. --Fractaler (talk) 17:45, 12 November 2017 (UTC)[reply]
    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)[reply]
    Are you afraid of transitivity, because then the ideology of ontology based on properties will lose? Fractaler (talk) 17:59, 13 November 2017 (UTC)[reply]

    Archived edit

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

    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:

    Discussion edit

    Archived edit

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

    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.

    Discussion edit

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

    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:

    Discussion edit

    Archived edit

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

    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:

    Discussion edit

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

    Archived edit

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

    Photoshop wiki

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

    • Phabricator tickets:

    Discussion edit

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

    @Thennicke: We want a tool belong to us and translatable.Thank you --ديفيد عادل وهبة خليل 2 (talk) 08:48, 12 November 2017 (UTC)[reply]
    Beware NIH syndrome. Tools already exist, let's not reinvent the wheel. Anomie (talk) 16:27, 13 November 2017 (UTC)[reply]
    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)[reply]
    @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)[reply]
      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)[reply]

    Archived edit

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

    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.

    Discussion edit

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

    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:

    Discussion edit

    Archived edit

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

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

     N Proposes social/community change rather than a technical feature

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

    Discussion edit

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

    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.

    Discussion edit

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

    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)[reply]
    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)[reply]
    @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ſk✉Talk) 23:57, 18 November 2017 (UTC)[reply]
    Thank you for your explanation. It is sad, but rational. Samat (talk) 00:30, 19 November 2017 (UTC)[reply]
    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)[reply]

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

    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:

    Discussion edit

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

    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:

    Discussion edit

    • 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)[reply]
      • 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)[reply]
    • @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)[reply]
      • 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)[reply]
        • @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)[reply]
    • Are you basically asking for arithmetic-based Wikidata constraints? --Tgr (WMF) (talk) 05:43, 18 November 2017 (UTC)[reply]

    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:

    Discussion edit

    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:

    Discussion edit

    Archived edit

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

    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:

    Discussion edit

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

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

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

    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:

    Discussion edit

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

    @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)[reply]
    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)[reply]
    No problem, thanks for trying! James Salsman (talk) 11:51, 24 November 2017 (UTC)[reply]

    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.

    Discussion edit

    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:

    Discussion edit

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

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

    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:

    Discussion edit

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

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

    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:

    Discussion edit

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

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

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

    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:

    Discussion edit

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

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

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

    • 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)[reply]
    • 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 (talk • contribs) 15:09, 15 November 2017 (UTC)[reply]
    • 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)[reply]
    • 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)[reply]

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

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

    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:

    Discussion edit

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

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

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

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

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

    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:

    Discussion edit

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

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

    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:

    Discussion edit

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

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

    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:

    Discussion edit

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

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

    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

    Discussion edit

    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)[reply]
    @NKohli (WMF): Any information on a realistic release date for the extension on German Wikipedia? // Martin Kraft (talk) 11:02, 27 November 2017 (UTC)[reply]
    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)[reply]
    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)[reply]

    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:

    Discussion edit

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

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

    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:

    Discussion edit

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

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

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

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

    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.

    Discussion edit

    Archive edit

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

    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:

    Discussion edit

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

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

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

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

    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 discussion edit

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

    @Фред-Продавец звёзд: 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)[reply]

    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:

    Discussion edit

    • 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)[reply]
    • 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)[reply]
    • 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 (talk • contribs) 13:35, 15 November 2017 (UTC)[reply]
    • 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)[reply]

    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

    Discussion edit

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

    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:

    Discussion edit

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

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

    Archived edit

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

    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:

    Discussion edit

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

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

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

    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:

    Discussion edit

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

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

    Yup, that is an unknown space, how file editing will work after data integration.--Juandev (talk) 09:39, 9 November 2017 (UTC)[reply]
    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)[reply]
    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)[reply]
    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)[reply]

    Archived edit

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

    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:

    Discussion edit

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

    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    Good idea. Dragfyre (talk) 18:40, 10 November 2017 (UTC)[reply]
    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)[reply]
    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. Downtowngal (talk) 22:40, 10 November 2017 (UTC)[reply]
    You could make a decent CAPTCHA out of this. MER-C (talk) 07:04, 10 November 2017 (UTC)[reply]

    Hey all, the Structured Data on Commons team is planning to implement image recognition in 2019 as part of the Structured Data on Commons program. Abittaker (WMF) (talk) 17:01, 13 November 2017 (UTC)[reply]

    Archived edit

    Per Abittaker above. Since this work is already scheduled, no point in voting. Thanks for participation in our survey. Max Semenik (talk) 23:26, 20 November 2017 (UTC)[reply]

    I see that image recognition is scheduled, but does that also include the idea of auto-adding images to categories based on the coordinates included in EXIF data? Dragfyre (talk) 14:49, 29 November 2017 (UTC)[reply]

    Translation in proper Devanagari script

    • Problem: improper pronunciation and translation in Devanagari
    • Who would benefit: Hindi and Sanskrit speakers
    • Proposed solution: improving the pronunciation by breaking words into sounds example शनिः श्+अ+न+ि+ः by this we can understand and pronounce words in Sanskrit easily
    • More comments: please add more Indian literature in context of Wikipedia
    • Phabricator tickets:

    Discussion edit

    I suppose it should be achievable by using a font that do not compose on user's end?C933103 (talk) 00:03, 13 November 2017 (UTC)[reply]

    @07Kaustubh: It's not clear what is being asked for. Can you tell us where this pronounciation will be added? Adding Indian literature is something that will go on Wikisource and not Wikipedia. -- NKohli (WMF) (talk) 20:03, 16 November 2017 (UTC)[reply]

    Unfortunately I have to archive this proposal since it's not clear what's being asked for and the proposer has not replied back. Thank you. -- NKohli (WMF) (talk) 23:41, 20 November 2017 (UTC) [reply]

    Head line numbering

    • Problem: Tables of contents of lengthy articles have automatically numbered entries (such as 1, 1.1, 1.1.1, 1.1.2, 1.1.3, 1.2, 1.3, 2, 2.1, ...) automatically taken from the (sub)headlines of the article itself. But the headlines in the articles themselves don't have the automatically assigned numbers. Thus, for finding, e.g., "1.3.7" from the table of content, you can't go by the numbers, you must go by the content. Possible, but awkward
    • Who would benefit: All readers
    • Proposed solution: Add the numbers used in the table of content also to the headlines in the article.
    • More comments: Am I the first to propose this? Haven't seen it before.
    • Phabricator tickets:

    Discussion edit

    I am absolutely sure that a gadget already exists for this. --AKlapper (WMF) (talk) 19:22, 10 November 2017 (UTC)[reply]
    I'd be happy to learn what/where/how this gadget is. Seems to be "a lttle bit hidden". But even if an optional gadget exists, I consider it better making it standard. Proper headline numbering supports keeping the orientation and navigating within the article. Best regards --Pfeiffer3f (talk) 08:49, 12 November 2017 (UTC)[reply]
    This already exists. Go to Special:Preferences#mw-prefsection-rendering, scroll down to the "Advanced options" box, and check "⧼tog-numberheadings⧽". Anomie (talk) 17:45, 13 November 2017 (UTC)[reply]
    Ah, OK, I see, thank you. It does what I mean. Is there a reason why it is not default? I consider it preferable and would assume "it costs nothing" and I see no other disadvantages. Vice versa, the present default (having the numbering in the table of content, but not in the text itself) makes no real sense to me. But maybe there is s.th. I am not aware of. Best regards --Pfeiffer3f (talk) 10:55, 14 November 2017 (UTC)[reply]
    The big disadvantage is that it breaks with reading and provides no value for most of our readers. It's a valid preference to have but I don't this it should be enabled by default. Max Semenik (talk) 18:30, 15 November 2017 (UTC)[reply]

    Automatic suggestions for categories

     
    The image description is: "Railjet 793 on the Tauern Railway south of Bad Hofgastein.". The categories of this image are: "Bad Hofgastein", "ÖBB Railjet control cars" and "Tauern Railway in Salzburg (state)"
    • Problem: It takes too much time to find suitable categories for images.
    • Who would benefit: Everyone who categorises images.
    • Proposed solution: Utilising the position data and the image description, categories which could be fitting to an image should be automatically suggested. This mechanism should i.e. search for images that were taken nearby in order to use the categories added to these images and analyse the image description in order to suggest categories. In the example added to this suggestion, all of the categories could have been suggested using the image description simply by suggesting categories whose name appears in the image description. An optimisation would be possible by using the position data, i.e. for suggesting the subcategory "Tauern Railway in Salzburg (State)" instead of the main category "Tauern Railway". Adding categories manually simply takes time. In general, i'd suggest that improvements to image uploading and handling should be made available not only for the upload client on Commons, but also for the Lightroom plugin.
    • More comments:
    • Phabricator tickets:

    Discussion edit

    We are exploring a similar feature as part of Structured Data on Commons. However, current ideas revolve around the concept of suggested "tags", which will be structured "depicts" properties which in turn reference Wikidata items. We'll look into expanding the functionality for categories as well, although it's not a priority at the moment. RIsler (WMF) (talk) 19:09, 20 November 2017 (UTC) [reply]

    Create a widget for external website consultation of video

    • Problem: The Web is full of video widgets that allow to consult in place a video which is stored on a different server domain. Most of them use a video on demand service provider among the most populars. People don't have the reflex to upload to Commons, even if the video have clearly pedagogical values and that they are fine with sharing it under a free license. Although many other factor are admittedly entering in this result, not being able to easily integrate a Commons widget in their own website might be a criteria for rejecting Commons as a video hosting service. That is sad, as we directly lose many occasion of gathering more video content. But even more detrimental is the fact that we lose many occasion of making people aware that they can share their pedagogical videos on Commons. Indeed, an easy to use external widget is not just an attractive feature for this users, it's also a way to attract a lot of audience, and consequently many new potential contributors.
    • Who would benefit:
      • Everybody on the web looking for a video on demand service provider that comes with such a feature for their pedagogical videos.
      • The Commons project and community, as it could gain a lot of visibility and new contributors.
    • Proposed solution:
      • implement a widget of external consultation, which of course include a link to the Commons relative page and maybe a "About Wikimedia Commons" link. Possibly push the Commons logo at some place/point to strengthen the promotional value of the widget.
      • make this widget extremely easy to use through copy/paste of code snippet accessible everywhere the video appears so users can disseminate Commons video wherever they want on the web.


    • More comments:
    • Phabricator tickets:

    Discussion edit

    • We actually do have this, but we don't promote it much, because its rather unstable. But if on commons, you go to "Use this file", and copy paste the HTML code:
    <iframe src="https://commons.wikimedia.org/wiki/File%3APetrSU_English_2017.ogv?embedplayer=yes" width="1024" height="576" frameborder="0" ></iframe>

    Then this can be embedded into another page. The Wikimedia blog uses it. But as stated, its a bit flaky and additionally, we are terrible at Commons at encouraging usage of our material to begin with. We seem to focus on collecting rather than reusing. —TheDJ (talk • contribs) 10:52, 13 November 2017 (UTC)[reply]

    • Great news, thank you. Then I think this proposal should be turned into improve this feature to fix its unstability. For the problem of promoting reuse, it's not a technical problem. But Community Liaisons might consider the problem. @Trizek (WMF):, @Qgil-WMF:, et alia, may we discuss the topic somewhere? --Psychoslave (talk) 11:28, 13 November 2017 (UTC)[reply]
      • <hobby horse>It would be great to see support for something like oembed (T27854) and/or opengraph for Wikimedia urls. When I copy and paste a URL into a non-Wikimedia site or social media I'd love to see an automagical expanded player ala every other media provider on the 2017 Internet. ಠ_ಠ </hobby horse> CKoerner (WMF) (talk) 22:56, 13 November 2017 (UTC)[reply]
      • I don't know any details, but I expect the Structured Data on Commons program to make Commons content not only easier to find, also easier to promote. @SandraF (WMF):. Qgil-WMF (talk)
      • As mentioned above, one of the (many) goals of Structured Data on Commons is to improve our reuse scenarios. Once we have structured data in place, we'll start building out tools that take advantage of it. Reuse/embed work is currently scheduled for 2019, and our plans include ways to improve both the tech side and address the problem of promoting Commons and its content. For example, one approach may be to have a Wordpress widget for this in addition to our own tool (which, as TheDJ mentions, exists now but could use some improvement). RIsler (WMF) (talk) 18:59, 20 November 2017 (UTC)[reply]
    We're archiving this proposal for the reasons above. Thanks for participating in the survey. -- DannyH (WMF) (talk) 01:22, 21 November 2017 (UTC)[reply]

    A more user-oriented search bar

    • Problem: The search bar currently shows the most probable pages ranked by number of hits.
    • Who would benefit: All Editors
    • Proposed solution: It would be good if the search bar could be oriented to the page most edited by me (ex: on typing User:F on Wikipedia the search bar should first show my name)
    • More comments: This can be adapted for anons to be a page which will be similar in topic( in the same category) to pages which they have clicked on before
    • Phabricator tickets:

    Discussion edit

    Archived edit

    I've spoken to our search team and they said that while it's theoretically possible, it's going to be a huge effort and they can't do this at the moment. Because our team doesn't have the expertise to work on this proposal on our own, it can't be done. Thanks for participating in our survey. Max Semenik (talk) 01:17, 21 November 2017 (UTC) [reply]

    Allow disabling referrer info

    • Problem: For those unfamiliar with HTTP Referral Headers (or w:HTTP referer), an HTTP referrer is some part of developer tool that helps an external website trace an info of the transferring website that a user was transferring from. For example, if a user goes to w:en:White House article and then clicks a link to an official website (https://www.whitehouse.gov/), that (official) external website would collect a datum saying that a user was transferred from that previous website. The WMF's current referrer policy is "origin-when-cross-origin" (phab:T87276), meaning that an external website, like the White House website, would read just the full domain, like "https://en.wikipedia.org/".

      However, some (if not many) Wikimedian users feel not secure enough by the current policy whenever they click links to external websites, especially via browsers that support referrer policies. Browsers would still give referrer info to external websites. Therefore, this year at the en.WP village pump discussion, the majority favored having their referrer info muted out, i.e. "no-referrer", which would conceal the header info from an external website, especially when the website wants to trace the info of the transferring/origin website (i.e. where the user was transferred from). However, one of the WMF staff says that there are no plans to change the referrer policy anytime soon out of concerns over impact on "technical efforts" or aggregated/non-personal statistical data (or something like that).

    • Who would benefit:

      Logged-in editors who are using browsers that (partially or fully) support referrer policies but do not have add-ons/extensions optimized for those browsers to suppress referrer info (i.e. referrer control), e.g. MS Edge;

      those logged-in editors who do not want external websites to find out their activities in any Wikimedia project (like Wikipedia), even when using a browser that supports a referrer control add-on, like Google Chrome, and even when only the full domain is reveal while using a browser that supports WMF's current referrer policy;

      logged-in users who would want to use a public computer that does not have extensions modifying/suppressing referrer info

      (if multiple-option solution is possible) those logged-in editors who would prefer to reveal their full URL to external websites (due to IE11's lack of support for referrer policies, the IE11 already reveals full URL to "https" external websites).

    • Proposed solution: If a multiple-option solution is impossible, how about a gadget instead as part of user preferences settings to opt-in/opt-out the referrer info? If a user is using a browser that supports referrer policy, a user would select an option that should support "no-referrer" and/or "never", depending on various browsers.

      On the other hand, if a multiple-option solution is possible, how about a user preference setting that allows an individual user to select any type of referrer policy for browsers that support either referrer policy (newer or older)

    • More comments: I originally thought I fully understood which browsers supported referrer policies. However, re-reviewing the proposal and comments, I realize that I should have known and thought more. Still, I think it's disheartening that MSIE11 doesn't support referrer policies, including either no-referrer or never. Also, MS Edge and Apple Safari support just an older draft of referrer policy, but that policy would not help those browsers recognize the WMF's current referrer policy. Therefore, during the Proposal phase, a Phabricator task was filed.

      Meanwhile, a user script to suppress referrer info was provided (under #Discussion section). I'm not sure how it helps whole communities, but it might be a good use in case that this proposal doesn't pass. Especially when the proposal passes, users should be notified that all versions(?) of Internet Explorer do not support referrer policies at this time, especially the "no-referrer" or "never" policy.

      Note that this proposal concerns just the logged-in editors. Unless I'm proven wrong, matters regarding referrer info of logged-out users are out of the scope of the Wishlist and can be discussed at other appropriate venues. Even when the matters are within the scope, any proposal regarding referrer info of logged-out users would not receive huge support, and the WMF would have repeatedly ruled the change of referrer policy.

      Referrer controls add-ons for browsers supporting them have been suggested as alternatives to this proposal. There have been reviews toward those add-ons, mostly good (but some bad). However, they are for users who don't want their Internet activities to be gathered by any website. What Internet users do in general is too broad for and not part of this proposal. Re-edit: I downloaded the extensions and tested them out. See details at the #Discussion section.

      Moreover, the default browsers has historically been either Microsoft Internet Explorer, Microsoft Edge, or Apple Safari, depending on which operating system (OS) you installed, like w:Microsoft Windows or w:macOS. If a browser that you have as part of the OS package doesn't support a such add-on, you must via the browser download a browser that supports such extensions.

      The WMF staff members can explain better than I what referrer info is and how referrer policies are made and which browsers support a referrer policy.

    Old version of the proposal

    Collapsing messy proposal (click to expand or collapse)
    * Problem: HTTP referrer info is detected by simply clicking an external link to a website, risking privacy compromise and spamming which would help external websites (i.e. "https" websites as WMF's current policy has referrer info suppressed from "http" websites) detect where a user was clicking a link from. Even suppressing the https→http referrer info does not make a Wikimedian user feel more secure. Rather, if a user reads a Wikipedia article like the w:White House or w:Central Intelligence Agency and then clicks an external link to an external website, like an official White House website or an official CIA website, another https website would still track a Wikimedian user's "origin"(?) activities, putting a Wikimedian at risk of being tracked. The majority at this year's enWP RFC discussion favored the "silent referrer" option (i.e. never sending domain info to other website), while some others favored sending either the full domain option, like "en.wikipedia.org" (actually, the current status quo is "origin-when-cross-origin" per phab:T87276), or full URL referrer option. However, one of the WMF staff says that there are no plans to change the policy about referrer info anytime soon out of concerns over impact on "technical efforts".
    • Who would benefit: Users whose browsers (such as Microsoft Internet Explorer and Microsoft Edge) don't disable referrer info and/or don't support add-ons to disable referrer info, those who want to reveal info to external websites (i.e. if they want to enable the referrer info), and others other Wikimedian users.
    • Proposed solution: Instead of proposing a policy change, I would like to propose two solutions for users' preferences settings.
      1. Primary solution: multiple option referrer info can offer silent referrer info, full URL, full domain, and partial domain (e.g. "wikipedia.org") and maybe more (according to this site) as options for a user to choose in the Preferences settings.
      2. Alternative solution: a gadget to simply disable/opt-out referrer info by (probably) clicking a box in the settings.
    • More comments: The HTTP referrer is not easy to describe in simple words, and I'm not sure whether the general public knows what "HTTP referrer" is. I was told that browsers (if not websites, including external ones) can still detect IP addresses, regardless of how referrer info is sent.

    Discussion edit

    @George Ho: Rephrasing the summary for clarity is welcome. "Referrer info" already exists, so you probably don't ask for it to be added/supported. :) "Allow disabling referrer info" or something like that? --AKlapper (WMF) (talk) 12:27, 7 November 2017 (UTC)[reply]

    Renamed the title, Andre. BTW, thanks for the clarity suggestion, but I don't know which part of summary to re-clarify. --George Ho (talk) 16:19, 7 November 2017 (UTC)[reply]
    "Allow disabling referrer info" is already much clearer, thanks a lot! :) --AKlapper (WMF) (talk) 16:24, 7 November 2017 (UTC)[reply]

    I'll caution commenters that the linked enwiki discussion is very large, disorganized, and full of errors, misinformation, and FUD. A summary of the salient facts:

    • By default, when following a link browsers may include "referrer" metadata in the request. Many sites use this data for various analytics purposes, e.g. to identify external sites that drive traffic to inform decisions about partnerships.
      • For links from sites served over HTTP, this data consists of the full URL of the page containing the link.
      • For links from sites served over HTTPS to HTTPS targets, this data consists of the full URL of the page containing the link.
      • For links from sites served over HTTPS to non-HTTPS targets, no referrer data is sent. This is sometimes called "dark traffic".
    • When Wikimedia wikis were changed to HTTPS-only in 2013, this caused all traffic from our wikis to non-HTTPS sites to become "dark traffic". In some cases this is a significant amount of those sites' traffic.
    • Web standards provide a solution: a site can instruct the browser on which of certain predefined options it would like the browser to use when sending referrer data. Most browsers honor these requests. Popular browsers such as Firefox and Chrome have addons that allow users to instruct the browser to ignore website requests.
      • In 2015, Wikimedia wikis began using this mechanism to request that browsers send only the domain of the page (the "origin", in technical web-standards terminology) as the referrer data in all cases. This was seen as a good compromise between privacy and visibility for the global Internet ecosystem. The Wikimedia Foundation's Security and Legal teams both approved this decision.
    • Then we come to the enwiki discussion. It was driven by a heavily one-sided presentation, inaccurate technical information (e.g. that Wikimedia itself actively sends this referrer data, that some options were even possible, the actual current behavior with respect to HTTPS destinations, that spammers have no workaround for the withholding of referrer data), presentation of options that are more complex and worse for privacy as if they were better for privacy (e.g. collecting data that would be vulnerable to subpoena and data retention orders), irrelevancies, and heavy bludgeoning with hypothetical situations where people affected would be well advised to use other solutions to apply to all their web browsing (e.g. the above-mentioned addons) rather than relying on one website (Wikipedia) to do the "right" thing.

    This proposal itself begins with some similar issues, including suggesting impossible options ("partial domain") and irrelevancies (IP addresses, phab:T172009, and many of the linked search results). HTH. Anomie (talk) 14:31, 7 November 2017 (UTC)[reply]

    Struck out the irrelevancies that you mentioned, Anomie. --George Ho (talk) 16:19, 7 November 2017 (UTC)[reply]

    Anomie and AKlapper, if the multiple-options solution is impossible, I will soon strikethrough the "primary solution" and revise the proposal to just a gadget to enable/disable referrer info. Sounds good? --George Ho (talk) 23:57, 7 November 2017 (UTC)[reply]

    I haven't looked at technical feasibility for offering a user preference to make it configurable. The impossibility I referred to is the fact that there is nothing at https://www.w3.org/TR/referrer-policy/#referrer-policies that allows for "partial domain". The options available are:
    • No referrer.[5][6]
    • No referrer for HTTPS→HTTP, full URL for HTTPS→HTTPS.[7]
    • Full domain (e.g. "en.wikipedia.org").[8][9]
    • No referrer for HTTPS→HTTP, full domain (e.g. "en.wikipedia.org") for HTTPS→HTTPS.[10][11]
    • Always send the full URL.[12]
    In all cases it's possible to make an exception, sending the full URL for local links (e.g. links from one page on enwiki to another page on enwiki). The current setting on Wikimedia wikis uses this exception, FYI. Anomie (talk) 15:09, 8 November 2017 (UTC)[reply]
    Modified the "primary solution" proposal. May I leave in struck text, or must I remove it? --George Ho (talk) 19:06, 8 November 2017 (UTC)[reply]

    (Note that the "one of the WMF staff" mentioned above is the CTO, so that answer is as authoritative as it gets.)

    It seems fairly pointless to provide something like that as a user option. Installing the appropriate browser extension is not any harder then enabling the appropriate user, provides real privacy (why would you want to suppress referrers for Wikipedia but nothing else?), does not require you to be logged in to Wikipedia, does not require splitting the cache (would not be a problem right now but eventually we want to serve cached pages to logged-in users as well) and does not consume WMF development resources that can be put to better use. --Tgr (WMF) (talk) 00:41, 19 November 2017 (UTC)[reply]

    I sincerely disagree, Gerzo. Installing an add-on for a browser is not a valid reason to be reluctant to create a user option to suppress referrer info. Moreover, offering such a user option is not pointless, even when add-ons suppressing referrer info are provided for browsers and even when browsers offer settings to enable/disable referrer info, like Opera browser. Installing an add-on/extension is the concern for users who browse multiple websites via Internet. However, what other websites do to users does not and should not affect this proposal. If it does and should, I would have agreed with your arguments.

    Also, we should not be like other websites that do not allow disabling referrer info, especially ones that don't offer user options to suppress referrer info. True, the user option is for Wikimedia projects, like Wikipedia, Wiktionary, and Wikidata, not non-Wikimedia websites; however, we shouldn't be too dependent on add-ons or Opera, should we? True, logged-out users would still be tracked by going to "https" external websites; moreover, they would not obtain this option. Also, they can download referrer controls for their own browsers. However, this proposal does not concern logged-out users. If it were, the proposal would have been totally different and out of the scope of the Tech Community because it would require policy change (right?), which the WMF's Chief Technology Officer (CTO) ruled out.

    Also, this proposal is about allowing logged-in users to modify/disable referrer info, not about using add-ons for browsers during web surfing. Why else denying logged-in users something that would benefit them besides "consum[ing] WMF development resources"? (I don't know what you mean "better use", but I have heard complaints about VisualEditor and MediaViewer. Are still they examples of "better use"?) Furthermore, this proposal (I hope) can apply to other projects, like Wiktionary, if that's possible. There are reasons to create a user option: 1) many people in the enWP discussion chose "silent referrer info", even when the CTO says that policy change is unneeded; 2) this proposal would benefit users who would be reluctant to download a non-Microsoft browser; 3) the proposal would benefit users who do not want their activities in Wikimedia projects to be tracked. If there is no reason to create a user option, I would not have proposed the option in the first place. I propose it, and I believe that this proposal would work unless the majority would oppose it.

    Speaking of add-ons, as said before, Internet Explorer and MS Edge neither support such add-ons to suppress the info nor have browser settings to disable the referrer info. Google Chrome, Opera, and Mozilla Firefox can suppress referrer info via add-on or setting, but a user must download either of the browsers via initially installed browser, like MS Edge. Also, having more than one browser would eat up hard disk memory more. BTW, I found a referrer control add-on for the old version of Apple Safari, not the latest version of it. I am unsure whether another add-on, created almost a decade ago, supports the latest version. –George Ho (talk) 08:44, 19 November 2017 (UTC)[reply]

    IE does not support referrer policies at all. Edge and Safari only partially supports them (we probably should do something about that; filed T180921). The other browsers all have plugins. (And if you care about privacy you should use a browser which cares about privacy. We are not helping anyone by giving them a false pretense of privacy when real options exist.) Anyway if you feel strongly about weakening your own privacy and really want a user script for this it's as simple as $(function() { $('head').prepend('<meta name="referrer" content="no-referrer" /><meta name="referrer" content="never" />'); }); --Tgr (WMF) (talk) 22:13, 19 November 2017 (UTC)[reply]
    Re-reading the proposal, I see some misleading statements, so I struck out some other statements and added some underlined ones. Therefore, this proposal should clearly concern the privacy of logged-in Wikimedians. I appreciate your giving out the user script that can suppress the referrer info. However, would that risk creating a lot of pages of user scripts? If this proposal is turned down, what if 50 or 500 or 5000 users want to use the above script into their own user script pages, leading to 50 or 500 or 5000 pages of them? Would that create a lot of bytes of data within the Wikimedia servers? –George Ho (talk) 01:33, 20 November 2017 (UTC)[reply]
    The enwiki DB is something like 100GB currently. I wouldn't be overly worried about that extra 0.001GB or so.
    I feel the description of this task is getting more and more confusing and FUDdish. Some examples of hypothetical harm (e.g. how will I be negatively affected when I click on the White House link and the White House learns I visited them from Wikipedia?) would be more helpful. --Tgr (WMF) (talk) 03:33, 20 November 2017 (UTC)[reply]
    Can you point out which part of the description is more confusing and FUDish, so I'll modify the info more? Thanks.

    Anyway, the CIA's privacy policy and the White House's explain that they collect data of activities. I read how the White House shares info and found out that normally it doesn't share such info to others. However, access is restricted to selected "employees, contractors, and vendors", and info may be shared with other government agencies per request by law enforcement or in case that the security of the official website is threatened. However, I could not find how CIA shares automatically gathered info of visitors who surf from other websites, but I found out why CIA gathers the info. I found another section saying, "Anyone using this Web site expressly consents to such monitoring." While the White House is discreet on disclosing or not disclosing any info, (to me unless I'm wrong) the CIA doesn't tell a user how the CIA shares info about activities of users who visit its official website. Also, the CIA doesn't mention "referrer" or "referer" anywhere in the Site Policies page.

    If the two are not enough, how about surfing from the w:National Rifle Association to its official website? Somehow, this revision still contains the "http" URL link; however, the link redirects from "http" address to the "https" address. The NRA's Privacy Policy says that it gathers info from websites that refer to that website, but it doesn't say how the NRA shares the info. The CIA and NRA would find out speculate/assume that, even when only the full domain is provided as a header, users were transferred from Wikipedia articles would refer to their own respective official websites, and either organization would or would not share any referrer info with others at discretion, though their websites do not say how info is shared. Speculations about sharing info would arise, but they are mere speculations, right?

    Nevertheless, how does https→http (redirect)→https referrer info work if https→http referrer info is concealed from unsecured "http" websites? --George Ho (talk) 04:30, 20 November 2017 (UTC); edited, 07:00, 20 November 2017 (UTC)[reply]

    --- If you want speculated harm, I would say that CIA or NRA would use referrer info of originated websites that refer to their own official websites. I don't know what either organization would do to Wikipedia articles, and I don't know which part of info from those articles either organization would use. Other examples are clicking from w:Democratic Party (United States) to its official website. The DNC's privacy policy reveals whether to treat info as either personal or "aggregate only" and how they share any personal info to selected parties. The DNC says, "Nothing herein restricts the sharing of aggregated or anonymized information, which may be shared with third parties without your consent." On the other hand, the GOP's says that it treats referrer info as part of "aggregated data" and as anonymous data, but the GOP's website also relies on Google Analytics. Probably those organizations would promote their own goals to Wikimedians. Hmm... at least PFLAG doesn't collect referrer info unless for special(?) purposes. --George Ho (talk) 04:51, 20 November 2017 (UTC); edited, 04:53, 20 November 2017 (UTC)[reply]
    --- How does Google share such info of Wikimedian users who click one of links, like Google Books, used as a source to cite an info? If a referrer info is non-"personally identifiable", then it can be shared publicly. The 2012-2015 version said that aggregated data may have been publicly shared. One of 2010 versions doesn't mention(?) how referrer info was shared; let's compare other past privacy policies. --George Ho (talk) 05:37, 20 November 2017 (UTC)[reply]
    --- I saw some other websites saying that they treat referrer info as part of aggregated data. --George Ho (talk) 05:39, 20 November 2017 (UTC)[reply]

    Gerzo, I re-read one of your comments and the website that you gave out and was previously mentioned in the en.WP discussion, and I realized that MS IE11 doesn't support referrer policies. Therefore, I decided to collapse the original (but messy) descrption of the proposal. I'll re-expand the newer description soon. --George Ho (talk) 08:44, 20 November 2017 (UTC)[reply]

    Regarding the https→http traffic data, I tested websites with developer tools on Google Chrome and MS IE11. IE11 does conceal "https" referrer info away from "http" websites. On the contrary, according to the browser developer tools, Google Chrome gives referrer info to any external website, either https or http. --George Ho (talk) 12:02, 20 November 2017 (UTC)[reply]

    @George Ho: Remember when I said the enwiki proposal suffered from bludgeoning of the discussion and irrelevancies? It seems you're starting to do the same thing now in this discussion section, with all this digression into the posted privacy policies of various random websites.

    I also fail to see why (as stated in your new proposal) someone would be concerned about websites seeing "https://en.wikipedia.org/" as referrer info but wouldn't be concerned about websites seeing referrer info from any other website, or why someone worried about referrer info would insist on using a browser that does not give them the ability to suppress it globally merely because it happens to be the default browser included with their OS. You seem to be asserting both of these points as givens. Anomie (talk) 14:51, 20 November 2017 (UTC)[reply]

    At first I was reluctant to download the extensions. However, I guess privacy policies are not convincing enough. Therefore, I downloaded Keepa.com's referrer control extension. I made filters. However, the filters didn't help block a referrer info sent to The Guardian. The Guardian site still retrieves the info. They also didn't help while clicking from one article to ICIJ. Nonetheless, it can block any referrer info sent from one Wikimedia/Wikipedia page to another Wikimedia/Wikipedia page. I'll do some most tests on this extension and other extensions soon. --George Ho (talk) 18:26, 20 November 2017 (UTC)[reply]
    --- Wait... After a few more tests, the filters do work. At first, I thought I have to insert site filters individually. However, I realized that the extension has settings to block referrer info for all sites. However, I have to download the extension for an individual computer, like a private PC. I haven't seen yet public computers filtering out referrer info. If public computers in some or many places (e.g. libraries and cafes) don't use any extension, referrer info can still be transferred. Must I try a public computer? --George Ho (talk) 18:37, 20 November 2017 (UTC)[reply]
    --- I tested ScriptSafe and find it also useful, but the settings say that selecting an option to suppress referrer info in all domains would lead to issues. I am unsure what the Japanese extension does, but the language is Japanese, which I do not understand. Therefore, I did not download and test it. --George Ho (talk) 19:14, 20 November 2017 (UTC)[reply]

    Basically as I understand the claim of the current proposal is:

    • Some Wikimedians feel unsafe because of the White House learning that they have arrived from an (unspecified) Wikipedia page when they visit its pages.
    • Said Wikimedians do not feel unsafe about the White House learning their IP address, browser, operating system etc. (if they did, they would be using Tor or other privacy-protection technologies and the issue would be moot); it's specifically the referrer that's making them feel unsafe.
    • Said Wikimedians do not feel unsafe about the White House learning how they arrived (possibly including the full URL) if they visit its pages through any other website (if they did, they would use some browser setting/plugin to disable referrers on all domains and the issue would be moot); it's specifically visiting via Wikimedia sites that's making them feel unsafe.

    To be quite frank I have serious difficulty believing this. --Tgr (WMF) (talk) 01:00, 21 November 2017 (UTC)[reply]

    George Ho: Victoria Coleman, the WMF's Chief Technology Officer, posted a response in September that said that the Foundation has no plans to change the referrer policy. The Community Wishlist Survey is not an appropriate place to relitigate that decision. I'm going to archive this proposal. -- DannyH (WMF) (talk) 01:20, 21 November 2017 (UTC)[reply]

    Modify leading for users who disable enhanced editing toolbar

    • Problem: Those using the Enhanced RefToolbar (aka RefToolbar 2.0), i.e. most users, can see w:leading space (or "line-spacing") on the editing window/screen bigger. However, those who disable the Enhanced (Ref)Toolbar can see leading on the window smaller as always since the debut of Wikimedia projects. This makes the text within editing window less readable and less easy to edit for those who disable the Enhanced toolbar. The issue was previously addressed at Meta-wiki's Tech venue, which contains a link to screenshots showing the difference between the two versions.
    •  
      Under Enhanced toolbar (2010 WikiEditor)
    •  
      Under classic toolbar (2006 WikiEditor)
    •  
      Toolbar(s) disabled (2003 WikiEditor)
    • Who would benefit: Users who disable the Enhanced (Ref)Toolbar in various projects
    • Proposed solution: Increase the leading ("line-spacing") from 1.1em to 1.5em (or something similar to the editing window with the Enhanced toolbar). If done, the text within the editing window would be for those users more readable and easier to edit.
    • More comments:
    • Phabricator tickets:

    Discussion edit

    Do you mean the WikiEditor editor? If so, you want to modify the 2003 editor. I’m not sure if it’s worth adding more CSS to it—this is the most basic editor, so size may be an important factor. (The 2006 editor, with which the old RefToolbar works, is currently being deprecated, and will be removed in the near future.) —Tacsipacsi (talk) 14:53, 7 November 2017 (UTC)[reply]

    Yes, the 2003 editor, Tacsipacsi. I'm unsure about the 2006 editor as removing it is planned, but I am using it and hope that it can be adjusted also before being removed from all projects. --George Ho (talk) 16:23, 7 November 2017 (UTC); Partially struck, 07:45, 20 November 2017 (UTC)[reply]
    Removing this is postponed again and again, but last update says 2017Q4 (i.e. anytime this year), while the results of this survey will be ready as late as the middle of December, so the toolbar may be removed even before it becomes clear whether this proposal is supported at all. (You can use custom CSS in the meanwhile.) However, the exact date of the toolbar removal makes no difference as if this change is made, it doesn’t make sense to add this CSS to the toolbar and leaving the toolbarless interface still without readable textbox, it should be applied—or not applied—for both the 2003 and the 2006 editor (if the latter is still alive). —Tacsipacsi (talk) 20:18, 7 November 2017 (UTC)[reply]
    I modified the title of this proposal to make it more clear what it is referring to. Hope that's OK. Kaldari (talk) 06:33, 8 November 2017 (UTC)[reply]

    I have decided to disable the toolbar, shifting to the 2003 WikiEditor, which omits the use of toolbars. In other words, I must type in wiki-coding and must manually type in the code (~~~~) to sign in my posts. --George Ho (talk) 07:45, 20 November 2017 (UTC)[reply]

    Pages Created upgrade

      Done Feature already exists

    • Problem: 8 to 10 clicks needed to see the first version
    • Who would benefit: Everyone who wants an quick overview
    • Proposed solution: The Pages Created tool https://xtools.wmflabs.org/pages/ should get a direct link to the first version of the article. At this time, it shows the first versions size and the current size of the article. I suggest to make the origin size to be a link to the articles first version.
    • More comments:
    • Phabricator tickets:

    Discussion edit

    Misleading inconsistency of interface design with the data model

     N Out of scope for Community Tech

    • Problem: The way item pages are structured and function on Wikidata give misleading ideas about the structure of the data, which in turn impedes the efficiency of (inexperienced) editors in interaction with the site:
      On a Wikidata item page, there is a second "+add statement" link if some statements are shown in a separate "Identifiers" section.
      This suggests that the statements go to separate bins when really both "+add statement" links are equivalent. (For some time, I went to special lengths to reach for that other link, which surprisingly didn't have a hotkey...) If you add a statement, at first it gets shown appended to either one or the other section.
      The "Identifiers" section is not a subsection of the "Statements" section; both headings are on the same level. This implies that under "Identifiers" there are no statements but something different, which contradicts the "add statement" link label.
    • Who would benefit: esp. new and inexperienced editors, every visitor of a Wikidata item page
    • Proposed solution: The "+add statement" links should be visually separated from individual sections. And there should only be one. (The upper is more confusing.) So:
      • One "add statement" link should be at the top of the page, before any (section) headings, in line with the "Read" and "View history" links, in consistency with Wikipedia's big "Edit" button and the "Add new section" links on the modernized talk pages on some Wikimedia wikis. This would have other advantages too, like not having to scroll around to find the "+add" link at some arbitrary position.
      • Maybe the visual grouping of statements should be done differently. The section heading could be turned into something more like an annotation. At least the second section heading should become a subheading of the first. Maybe background tint and annotations can replace the headings, or other visual effects that don't imply a split as much. ...
      • The "edit" link of the box of multilingual labels and descriptions should be clearly grouped together with its box and not stray to the page top as much, implying it to allow editing the whole page and then surprisingly opening edit tools in some box somewhere below. The solitary description line following the page heading actually belongs into that box, too...
    • More comments:
    • Phabricator tickets:

    Discussion edit

    Hi Reseletti: I agree with you that the interface on Wikidata needs a real redesign. Unfortunately, it's out of the scope of the Community Tech team -- this is a project that needs to be led by the designers working on the Wikidata team. So I'll have to archive this proposal as out of scope -- sorry about that, because it is a good and important idea. :) Thanks for participating in the survey. -- DannyH (WMF) (talk) 19:12, 21 November 2017 (UTC) [reply]

    Release VE on Talk pages

     N Out of scope for Community Tech

    • Problem: Currently VE is disabled on talk pages without any proper reason. This makes editing, especially for new users, more complicatted.
    • Who would benefit: Everyone, but especially new users.
    • Proposed solution: As I said in the headline: Simply enable VE on talk pages, it's possible.
    • More comments:
    • Phabricator tickets:

    Discussion edit

    Why do you need VisualEditor on talk pages? VisualEditor is for content editing, not for discussions. If you want to ease usage of talk pages for newcomers, you need Flow Structured Discussions. AFAIK, it can be turned on anywhere on request. --Tacsipacsi (talk) 22:47, 6 November 2017 (UTC)[reply]

    Agreed. Structured Discussions is ideal for this. NMaia (talk) 23:27, 6 November 2017 (UTC)[reply]

    Hey, VE here, although those, who want to push the weak forum impersonation Flow by prohibiting VE on talk pages claim it's impossible on such pages. I could even indent with colons, which they proclaim to be impossible with the VE. A wikipage is a wikipage is a wikipage.

    No Flow is a bad way, it completely breaks the look and feel of wikipages and creates a deep rift between up to now all in all similar. It makes formerly flexible semi-structured discussions, that could easily be edited in different structures if needed, into completely inflexible forumesque pages, that lack proper structure in longer discussions. Flow is a dead-end-street, unfortunately ruthlessly pushed by some paid people inside the WMF, even with measures as denying VE on talk pages without any proper reason. Grüße vom Sänger ♫(Reden) 05:30, 7 November 2017 (UTC)

    There are projects with VE enabled for project namespace = commuity discussions (Village pump etc.). And there are problems with formatting (VE uses <blockquote> instead of ::::. So VE should support discussion. JAn Dudík (talk) 08:28, 7 November 2017 (UTC)[reply]

    I think this would be rather controversial, and thus I don't think it's a good one for the community tech team to take on. It's not the 'interpret what each community thinks about this'-team. —TheDJ (talk • contribs) 17:21, 7 November 2017 (UTC)[reply]

    The persistent error is forgetting that a page-is-a-page, and that anything can appear anywhere. The error is the idea that "Article pages are supposed to be content edited in VE, and Talk pages are supposed to be chats edited in Flow". I am no fan of VE, but VE has valuable uses. If I want to edit a table on a talk page, it is extremely disruptive that VE is deliberately crippled to not allow it. I have to take the absurd workaround of copying the table to a non-talk page, pasting in the table to edit in VE, swapping to wikitext mode, copying the wikitext, quitting-without-saving, then returning to talk to paste in the edited table. Any and all "content" can be copied to talk pages to discuss and work on. The idea that talk pages don't contain "content" is just plain wrong. This error is one of the main reasons that Flow was such a flop. Flow was built on the idea that Talk pages are supposed to be chatboards. Talk pages are a wiki-workplace. Alsee (talk) 06:44, 8 November 2017 (UTC)[reply]

    What about making it optional for those who want it to be? --Artix Kreiger (Message Wall) 15:30, 8 November 2017 (UTC)[reply]
    Having preferences is technically cumbersome in comparison to giving everybody the same setting, I guess. I think that Flow is the better alternative although discussion should be had on removing infinite scroll, allowing it to use the same markup as regular wikiediting and offering assistance for people who e.g run archivebots and would need to modify their bots. Jo-Jo Eumerus (talk, contributions) 16:37, 8 November 2017 (UTC)[reply]
    Flow is an extremely dumbed down, completely inflexible, single-purpose forum impersonation only suited for chit-chat, not for discussions about content, article structuring etc. The only asset it has is that it's shiny new bling, not boring maintenance of existing software, and that's why it's pushed by the WMF.
    Unless Flow will one day be as flexible and as manageable as current wikipages, it's not worth anything. And a wikipage is a wikipage is a wikipage, regardless whether it's article-, user- or talk-page, all behave in the same way, all are editable in the same way, all have the same look-and-feel. Except the deliberate and hostile exemption of VE from talk pages. Grüße vom Sänger ♫(Reden) 16:53, 8 November 2017 (UTC)[reply]

    I realise that Visual Editor is not going to die, but it make writing training material a nightmare. Take the instruction. Open the editor- until recently you has to open Edit source for the project page and Edit for the talk page. That has been fixed on (en). Lets look at an image- Add local description and Add local description source are the options on (en) but normally we will want to View on commons and here there is no option to use VE just the option Edit which here does what Edit source does on (en). So can I suggest that these issues are thought about before they are implemented- and the implications to other projects.

    Further if I am on (de) I edit with Seite bearbeiten- but will wikiswitch to grab text such as a reference when replicating an article- (de) doesn't use VE so the obvious choice edit. So I am asking for the tabs to be consistent- Edit to mean edit everywhere and Visual edit used in the rare places where VE is allowed.--ClemRutter (talk) 20:52, 8 November 2017 (UTC)[reply]

    • I support this idea. At editathons I'm consistently seeing an increased willingness for non-scientists to engage with Wikipedia once I introduce them to VisualEditor. They stay and edit, only to be thrown off by the lack of a visual option on talk pages when they need to discuss something. If a Wikimedia project wants to enable VE for talk pages, let them do it. Deryck C. 22:13, 9 November 2017 (UTC)[reply]
    • I support this idea aswell. We do not need three ways to edit Wikipedia, two is enough. As this is controversial and we already have a VE team, this team may not be best to work on it though. Doc James (talk · contribs · email) 21:55, 13 November 2017 (UTC)[reply]
    • In Flow discussionpost can be edited in VE. The question remains in the indentation. VE automatically adds asterisk indentation by the Tab and the war of asterisks and colons will stop. And there is a new beta visual preview ... it would be interesting to compare versions use. --Sunpriat (talk) 09:50, 15 November 2017 (UTC)[reply]
      Wrong, not discussions can be edited in VE, only single posts can be edited in VE. There is no way to restructure a huge discussion, who answered whom is very hard to comprehend in huge discussions. Flow is only suitable for chitchat, not for real discussions. For real discussions flexible and adoptable talk pages are needed, and VE is only forbidden on talk pages to push Flow, no other valid reason was given. Grüße vom Sänger ♫(Reden) 16:34, 15 November 2017 (UTC)[reply]
    • This question is often brought up, despite the fact that I made the decision and documented it last year, in discussion with you. VisualEditor (VE) is designed to edit content — pages of prose, as used on Wikipedias, Wikiversities and Wikivoyages in particular, and to a lesser extent on other Wikimedia wikis. Every tool, every interaction, every habit is built to support that kind of editing, and thus make other kinds of editing harder. Providing users with an appropriate experience after enabling VE on talk pages would require major a rewrite of the software, and changes to the fundamentals of the editor which would make it worse for editing content. Either we would have the editor work in some mixture of code that works poorly for both, or we would add complexity, confusion and slowness by trying to act differently in different contexts, destroying user trust in the system "just working". There are definitely problems with the current ("legacy") discussion system, and I understand why people have problems with the structured discussions system too, but this "solution" doesn't fix either issue. We aren't going to ruin content editing to provide a shroud of bad discussion editing. Sänger, I know that you don't like my decision, but this isn't the way to convince me to change it. Jdforrester (WMF) (talk) 18:24, 15 November 2017 (UTC)[reply]
    A wikipage is a wikipage is a wikipage, full stop. You have not delivered a single argument until now. Grüße vom Sänger ♫(Reden) 20:15, 15 November 2017 (UTC)[reply]

    As you can see with this post, and this entire discussion, your decision is based on false assumptions. This edits prove beyond any doubt that VE is possible in a discussion, I'm just using it, so any pretense that it's impossible is just fake news. Grüße vom Sänger ♫(Reden) 17:14, 21 November 2017 (UTC)

    • @Jdforrester (WMF): I am wondering if there is a clear strategy/plan to handle the community pages and discussion pages in the future. From your answer I don't see this, but I hope you (generally: people working on this area at WMF/voluntarily) do have a view. This is a question which comes up time to time, and we need a direction to go straight. Current situation (different editing experience/surfaces on different pages) is not optimal at all. Samat (talk) 23:58, 17 November 2017 (UTC)[reply]
    @DannyH (WMF): my question wasn't an offense, I am really curious what is the strategy/plan for the discussion and community pages at the WMF. We are planning to introduce the Flow Structured Discussions now, but I heard that there isn't a real development/maintenance of it at the WMF team. I wouldn't push to introduce a surface which will be a technical dead end soon, which happened few years ago with LiquidThreads. Will Structured Discussions be the future of talk pages? I would like to see an easy to use surface which offers similar user interface and experience like VE/WikiTextEditor2017. If there is a public decision already about this issue, please link that me. If you have any information about it, please share with us. Thank you in advance! Samat (talk) 23:28, 20 November 2017 (UTC)[reply]
    No, it's not. -- NKohli (WMF) (talk) 01:16, 18 November 2017 (UTC)[reply]
    S/He, who can read, has a clear advantage ;) If I look at the header of this section, and look at what's done here, this is a discussion. But for those who desperately want the VE kept away from discussions, to push their pet project Flow, it cannot be one, that would be heresy. It's teh same with the new, completely unsubstantiated renaming of Flow to "Structured Discussions", as if current discussions were not structured. Of course they are, only in a more flexible way, restructurable according to the needs of the course of discussions, while Flow is an extreme rigid corset, suitable only for short chitchat. Grüße vom Sänger ♫(Reden) 10:12, 18 November 2017 (UTC)[reply]

    It was easy (despite the general problems with huge loading times in VE) to edit and indent this post in the right structure in this structured discussion here. As this is a perfect example for a discussion with VE, there is no validity in the private decision by one employee not to do as his employers, the communities wish. Grüße vom Sänger ♫(Reden) 17:14, 21 November 2017 (UTC)

    As Jdforrester (WMF) says, this has already been discussed and decided by the VisualEditor team. I'm going to archive this proposal. Thanks for participating in the survey. -- DannyH (WMF) (talk) 19:36, 20 November 2017 (UTC)[reply]

    And what jurisdiction has some employee of the community over community wishes? None whatsoever. This decision should be made by the community, not some bureaucrat, technical there is absolutely no problem with this proposal. It's just against the politics of some in-group in the WMF that wants to push Flow, whatever it takes. Grüße vom Sänger ♫(Reden) 21:49, 20 November 2017 (UTC)[reply]

    Sänger: The conversation about whether to use Structured Discussions on wikis is long-standing and difficult, both technically and socially. It's not a problem that can be solved by the Community Tech team. This comes up every year on the Wishlist Survey, and every year, we have to say that this is too big and too contested for the Community Tech team to tackle in a year. I know that that's frustrating for folks who want this debate to move forward. This survey isn't the right place for important large-scale debates. -- DannyH (WMF) (talk) 22:56, 20 November 2017 (UTC)[reply]
    Why should I believe this? It's simply switching it an, not more. A wikipage is a wikipage is a wikipage, full stop. It's not "too big", it's simply in the way of your pet project Flow, that you had the gall to rename to "Structured Discussions", while most discussions, that take place here and anywhere in the wikiverse are nearly perfectly structured, Flow has very little advantage in regard of real structure. It's only dumb bots, and I don#t are about dumb bots, that have some problems with the very obvious structure of talk pages. This decision is a deliberate decision to promote Flow, nothing else. Grüße vom Sänger ♫(Reden) 22:58, 20 November 2017 (UTC)[reply]
    What to do with talk pages is an important and long-standing debate. The Community Wishlist Survey is not a good vehicle for that debate. -- DannyH (WMF) (talk) 23:38, 20 November 2017 (UTC)[reply]
    And what has this to do with the simple, and technical easy, implementation of the current editor on a wikipage? There was no reason (or real world reason) given, why this should not be done. It was even proven (and is proven here in this discussion again) that it is possible, and only because some interested people fear its success, they don't enable it. I'm no developer, so I don't know whether the projects could enable it by themselves on all, or at least more, pages. I would definitely fear repercussions by those community servants, who confuse their job as servants of the community with some leadership role, perhaps not so extreme antiwikimedian like Erik did with his brutal implementation of superputsch, but they have de facto might, despite not having the legitimation.
    No, the question whether to enable VE on a wikipage is just a mater of minutes, whether Flow will really one day be capable to be useful on any page is a matter of years to come, up to now it's absolutely useless beyond meaningless chitchat. Grüße vom Sänger ♫(Reden) 05:17, 21 November 2017 (UTC)[reply]
    As I said, the survey isn't the right venue for this conversation. The Community Tech team can't act on this proposal; it's out of our scope. I'm going to archive this proposal. -- DannyH (WMF) (talk) 19:19, 21 November 2017 (UTC)[reply]
    This is wrong, and you know that this is wrong. It's nothing big, it's just the release of one of the two mayor editors on another wikipage, that#s just the same as any other wikipage. That it works was proven here in this discussion, that is editable with VE, so any claim of it being not possible is a false claim, if repeated after this prove of possibility it would be a deliberate lie. Grüße vom Sänger ♫(Reden) 20:44, 21 November 2017 (UTC)[reply]

    @Sänger: I am not a developer neither, but in my understanding the problem is not, that it is not possible to switch on the VE on talk pages. But VE has no advanced features for discussions (automatic signature, indention, cannot follow who answered to whom, notifications etc.), and developing this for VE means that it will be more complex and even slower for the content pages. I don't think that a community wish can change this. Samat (talk) 21:20, 21 November 2017 (UTC)[reply]

    It's just another editor, to be precise the current normal one for newbies, on another wikipage. The other stuff is something for later, that could (and should) be done, but as an editor it's not conceivable to withhold it from these wikipages. The wikitext-editor has as well no advanced features, but it's used nevertheless. And Flow is completely unusable up to now for real discussions, it's just a pre-alpha test for a forum impersonation, suitable for meaningless chitchat. Grüße vom Sänger ♫(Reden) 21:30, 21 November 2017 (UTC)[reply]
    This proposal is out of scope for Community Tech. We know that we can't work on it, and it would be misleading to allow people to vote on it. -- DannyH (WMF) (talk) 21:52, 21 November 2017 (UTC)[reply]
    What is "the scope of community tech", if such a simple thing like deployment of an existing editor on an existing wikipage is too far beyond it? Why do you do a survey about tech stuff and the WMF at all? Grüße vom Sänger ♫(Reden) 21:55, 21 November 2017 (UTC)[reply]
    I am guessing: Community Tech does not implement changes to a software whose developers and maintainers (who need to fix any future issues with it, after all) have said they don't want these changes. Jo-Jo Eumerus (talk, contributions) 09:01, 22 November 2017 (UTC)[reply]

    Watch only a section of a page or of a talk page

     N Out of scope for Community Tech

    • Problem: If you are only interested in one section, for example, in user discussions, you must always watch the whole page. Especially when that is a well-used page, it is hard to find the changes that you really want to observe.
    • Who would benefit: registered users
    • Proposed solution: It should be possible to watch a page for newly created sections, and it should be possible to watchlist specific sections. If a watched-section is removed, or if the software loses track of the section for any reason, this would count as a watched-edit and the user can view what happened. If timed expiration of watchlist entries becomes available, a watched section which no longer exists should get automatic timed removal from the watchlist.
    • More comments: This was already wished for in 2016; Watch only a section.
    • Phabricator tickets: task T2738
    • Proposer: --Gnom (talk) 22:09, 6 November 2017 (UTC) and Alsee (talk) 09:09, 8 November 2017 (UTC)[reply]

    Discussion edit

    The proposal overlooked an important element. It should also be possible to watch for creation of new sections on a page. That would be a very low-noise way to watch a page, and when an interesting section appears it can be section-watched. Ping author Gnom to consider updating the proposal. Alsee (talk) 07:34, 8 November 2017 (UTC)[reply]

    Hi Alsee, thank you for your comment. If you would like to modify the wish, please go ahead. --Gnom (talk) Let's make Wikipedia green! 07:40, 8 November 2017 (UTC)[reply]
    Gnom, done. Pinged so you can review the change. Blank lines removed per LISTGAP. Alsee (talk) 09:14, 8 November 2017 (UTC)[reply]

    I would love the ability to just watchlist the leads of certain articles. So plus one to this. Doc James (talk · contribs · email) 22:19, 13 November 2017 (UTC)[reply]

    Archived edit

    I'm archiving this as it's just not technically feasible. Aligning wikitext with database is hard because it's too fluid and changing. Such feature will take a huge effort to develop and will need lots of maintenance, at the same time being painfully buggy. Thanks for participating in our survey. Max Semenik (talk) 01:12, 21 November 2017 (UTC)[reply]

    Hi Max Semenik, I don't see why "it's very hard to achieve" could be a reason to archive wishes in this survey. If it were, there would be no VisualEditor today, right? --Gnom (talk) Let's make Wikipedia green! 08:39, 21 November 2017 (UTC)[reply]
    This survey is for tasks that a small team, along with about 10 other tasks, could complete in a year. VisualEditor has had a large team for 5 years working on it. --Izno (talk) 14:04, 21 November 2017 (UTC)[reply]
    Couldn't this survey also yield "big" wishes that require a larger team and more time? I see no reason for such a limitation. --Gnom (talk) Let's make Wikipedia green! 14:52, 21 November 2017 (UTC)[reply]
    No, this is to set goals for our team only. Tackling projects that are too big would mean less attention to other proposals; we still would like to at least try to do the top 10. Max Semenik (talk) 19:01, 21 November 2017 (UTC)[reply]
    Unfortunately, enabling users to watchlist sections would require major architectural changes to MediaWiki. (Basically, MediaWiki has no real concept of sections other than a complicated hack to the editing interface that doesn't even work for VisualEditor.) This just wouldn't be feasible for us to work on and isn't likely to be feasible at all without a major rewrite of MediaWiki. Ryan Kaldari (WMF) (talk) 20:03, 21 November 2017 (UTC)[reply]
    Hi Ryan Kaldari (WMF), if this "wouldn't be feasible" for the Community Tech team, well shouldn't then a different team work on it, if the community finds this important? --Gnom (talk) Let's make Wikipedia green!
    No, the purpose of this survey is to find proposals for the Community Tech team to work on. Allowing people to vote for proposals that we know we can't work on would be misleading. -- DannyH (WMF) (talk) 21:50, 21 November 2017 (UTC)[reply]
    Assuming that Ryan Kaldari (WMF)'evaluation supersedes https://phabricator.wikimedia.org/T2738#2361293 and what comes after that: the task at hand would benefit from this explanation (...[it] isn't likely to be feasible at all without a major rewrite of MediaWiki), and maybe should be declined for clarity? --Elitre (WMF) (talk) 13:54, 27 November 2017 (UTC)[reply]

    Sección Xtool (Pages Created)

     N Proposal is a social/community concern, not a technical proposal

    • Problem: En la sección Xtool correspondiente a mi propia situación como el usuario AnselmiJuan, he observado que hace pocos días comenzaron a marcar también los artículos que otros usuarios me borraron, con la mención "deleted". Lo que observé hasta ahora, es la cita que a continuación se indica :
    • Padilla (apellido castellano) · (Deleted) -- fecha: 2017-11-01 15:28

    Imagino que en forma similar, allí también se incluirán las referencias a artículos iniciados y modificados por otros usuarios, y que yo mismo, actuando como usuario de Wikipedia, haya podido borrar ("deletear") por algunos de los procedimientos admitidos (borrado rápido, borrado con consulta a la comunidad, etc).

    Opino que esto abre muy interesantes posibilidades, para que de una manera cómoda y segura y completa, se llegue a poder determinar, por ejemplo, si un determinado usuario ha perseguido con insistencia a otro determinado usuario, borrando los artículos que él o ella hayan podido crear con anterioridad, o bien obstaculizando de alguna manera su tarea de ampliación y mejora de artículos, etc.

    Permitir que usuarios borren artículos creados por otros usuarios, es una tarea muy necesaria e importante, pues las falencias que en cuanto a redacción y referenciación pueda llegar a tener un determinado artículo, o la situación que en cuanto a falta de interés enciclopédico pueda tener un determinado artículo, etc, hacen que el mismo necesariamente deba ser eliminado lo más pronto posible. Pero, lo que puede llegar a ser abusivo e incluso arbitrario, es si un usuario persigue a otros usuarios (a uno solo o a varios), de una manera obsesiva y reiterada, y al menos en ciertos casos borrandoles artículos de sus respectivas creaciones en forma apresurada, y sin una buena argumentación técnica de respaldo.

    Machine translation feel free to improve

    Problem: In the Xtool section corresponding to my own situation as user AnselmiJuan, I noticed that a few days ago they started to mark also the articles that other users erased me, with the mention "deleted". What I observed so far, is the appointment that follows:

    Padilla (apellido castellano) · (Deleted) -- fecha: 2017-11-01 15:28

    I imagine that in a similar way, there will also be included references to articles started and modified by other users, and that I myself, acting as a Wikipedia user, could have deleted ("delete") by some of the admitted procedures (fast deletion, deleted with consultation to the community, etc).

    I think this opens up very interesting possibilities, so that in a comfortable and safe and complete way, you will be able to determine, for example, if a certain user has persecuted with insistence to another determined user, deleting the articles that he or she may have create in advance, or in some way hindering your task of expanding and improving articles, etc.

    Allowing users to delete articles created by other users is a very necessary and important task, because the shortcomings that a particular article may have in terms of writing and referencing, or the situation that in terms of lack of encyclopedic interest may have a a certain article, etc., they must necessarily be eliminated as soon as possible. But, what can become abusive and even arbitrary, is if a user persecutes other users (one or more), in an obsessive and repeated way, and at least in certain cases deleting articles from their respective creations in a hurried, and without a good technical argument of support.

    • Who would benefit: Nótese que de ninguna manera estoy criticando de forma genérica el que se borren artículos creados por otros usuarios, pues con notoriedad hay casos en que así debe procederse. Pero opino también que este mecanismo, en ciertos casos, puede encubrir abusos o arbitrariedades, e incluso enseñamiento, en especial, si esta manera de actuar se reitera respecto de artículos creados por un reducido número de articulistas.

    Machine translation, feel free to improve

    Note that in no way am I criticizing in a generic way the deletion of articles created by other users, because with notoriety there are cases in which this must be done. But I also think that this mechanism, in certain cases, can cover up abuses or arbitrariness, and even teaching, especially if this way of acting is reiterated with respect to articles created by a small number of writers.

    • Proposed solution: A través de las mejoras del software de manejo de artículos y de articulistas, en los diferentes idiomas soportados por Wikipedia, se han hecho últimamente diferentes avances, especialmente en la sección Xtool correspondiente a los diferentes usuarios registrados en Wikipedia. Pero esto señala y tipifica situaciones particulares caso a caso, que no necesariamente incluye todas ellas situaciones irregulares. En el caso de español, tal vez Argentina y España son las wikicomunidades nacionales que han actuado con mayor responsabilidad en cuanto a diferentes cuestiones, y las comunidades en las que además existe un buen plantel de wikipedistas que acompaña las decisiones y recomendaciones de las respectivas asociaciones nacionales. Es a ese nivel que pienso se podría actuar para tipificar algún tipo de abuso o de persecución de wikipedistas o de situaciones, sobre las que se pueda y se deba actuar.

    Machine translation, feel free to improve

    Through the improvements of the article and article management software, in the different supported languages by Wikipedia, different advances have been made recently, especially in the Xtool section corresponding to the different users registered in Wikipedia. But this indicates and typifies particular situations case by case, which does not necessarily include all of them irregular situations. In the case of Spanish, perhaps Argentina and Spain are the national wikicomunidades that have acted with greater responsibility in relation to different issues, and the communities in which there is also a good campus of Wikipedians that accompanies the decisions and recommendations of the respective associations national It is at this level that I think you could act to typify some type of abuse or persecution of Wikipedians or situations, on which you can and should act.

    • More comments: Hasta el cansancio muchos han señalado, por ejemplo, que los wikipedistas novatos son muy importantes en cuanto a la futura evolución de Wikipedia, tanto en cuanto a la cantidad de artículos nuevos, como en cuanto a la calidad de los mismos. Sin embargo, muchos wikipedistas también han señalado con insistencia que no tratamos a los wikipedistas novatos como se debe, o sea, que no les ayudamos a superar sus primeras falencias. Claro está, a través de las ayudas de Wikipedia, a través incluso de vídeos explicativos, etc, cualquier wikipedista, por más novato e inexpediente que sea, puede llegar a adquirir destrezas y conocimientos sobre Wikipedia, para así poder llegar a ser un wikipedista que tenga un buen desempeño. Y reitero, sobre la cuestión recién planteada respecto de los wikipedistas novatos, o sobre los cursillos de edición en Wikipedia, o respecto de los editatones y editatonas, etc, las wikicomunidades nacionales que en lo personal considero más preparadas para en español llegar a abordar algunas o todas estas cuestiones, son las comunidades wikipedistas de Argentina y España. A ellas debemos pedirles un esfuerzo especial por mejorar este tipo de situaciones, así como para descubrir abusos o procedimientos inconvenientes.

      A nivel práctico, propongo en particular interesar a las wikicomunidades de Argentina y España en actuar en el sentido antes señalado, y en particular, promoviendo una o varias reuniones en sus respectivos territorios pero abiertas a todos los wikipedistas que tengan un buen dominio del idioma español, para que en esas oportunidades se realice una lluvia de ideas, que permita profundizar en estos asuntos.

    Machine translation, feel free to improve

    Until the fatigue many have indicated, for example, that the novice wikipedia are very important in terms of the future evolution of Wikipedia, both in terms of the number of new articles, and in terms of the quality of them. However, many Wikipedians have also insistently pointed out that we do not treat rookie Wikipedians as they should, that is, that we do not help them overcome their first shortcomings. Of course, through the help of Wikipedia, through even explanatory videos, etc, any wikipedist, no matter how inexperienced or inexperienced, can get to acquire skills and knowledge about Wikipedia, in order to become a wikipedia have a good performance. And I reiterate, on the question recently raised about the novice wikipedia, or on the edition courses in Wikipedia, or on the editatons and editatonas, etc, the national wikicomunidades that in the personal I consider more prepared for in Spanish get to tackle some or all these questions, are the wikipedia communities of Argentina and Spain. We must ask them to make a special effort to improve this type of situation, as well as to discover abuses or inconvenient procedures.

    On a practical level, I propose in particular to interest the wikicomunidades of Argentina and Spain in acting in the sense indicated above, and in particular, promoting one or several meetings in their respective territories but open to all wikipedia who have a good command of the Spanish language , so that in those opportunities a brainstorm is made, that allows to deepen in these subjects.

    • Phabricator tickets:

    Discussion edit

    Estimado usuario User:MusikAnimal (WMF) (Leon Ziembra)
    Observo que eres de la Fundación Wikimedia, y que te desempeñas como ingeniero de software.
    Te felicito muy sinceramente tanto por tus desempeños técnicos como por tu dominio del idioma español.
    Yo domino el francés bastante bien, pues viví 8 años en París, en Francia, pero inglés apenas si puedo entender algunas cosas cuando leo, siempre que sea texto técnico y sencillo.
    Respecto de lo que tú me planteas, te diré que XTools no tiene nada equivocado. Al contrario, desde hace unos dos años, personalmente he seguido los avances y las mejoras realizados desde la Fundación Wikimedia en cuando a Wikidata, o sea las interwikis, así como en cuanto a herramientas tales como XTools, y solamente tengo cosas elogiosas para decir al respecto.
    Pero lo cierto es que con esta información de base, es posible hacer análisis y seguimientos muy interesantes en cuanto a cierto tipo de abusos o de comportamientos no éticos de un wikipedista en particular, y también sacar información de tipo estadístico sobre ciertos indicadores generales.
    Por ejemplo, la Wikipedia en portugués, ya están muy cerca a superar el millón de artículos, una buena cifra. Sin embargo, yo consulto con frecuencia esa Wikipedia pues el portugués y el español son muy parecidos, y un hablante en un idioma comprende lo que se dice cuando se habla en el otro idioma. Sin embargo, y dada mi experiencia, reconozco que en portugués hay muchos muchos artículos que son muy cortos pues apenas son un espozo, cosa que en español no ocurre tanto.
    En resumen, reconozco que herramientas como XTools no están preparadas para sacar conclusiones de tipo estadístico, o referentes a abusos cometidos por un determinado wikipedista, ni en el idioma español, ni en el idioma inglés, ni en ningún idioma. Sin embargo, señalo que en idioma español, ese tipo de trabajo más sutil y fino, puede ser muy bien realizado por las wikicomunidades nacionales de España y/o de Argentina, pues aparte de ser ellas unas de las comunidades wikipedistas más antiguas y con más wikipedistas trabajando, son también muy serios en cuanto a la forma en la que hacen las cosas.
    No agrego más por el momento, pues tengo miedo que ello, en vez de aclararte mis dichos, por ahí tienda a confundirte más.
    Un abrazo desde Uruguay, y muchas gracias por tu esfuerzo por tratar de entender mi planteo y ms puntos de vista, y por en ese contexto hacerme algún tipo de aportes. --  AnselmiJuan (discusión) 02:01, 14 November 2017 (UTC)[reply]
    Gracias por su repuesta, AnselmiJuan. Si entiendo correctamente, esto es sobre un cambio social, y no es una propuesta técnica. Por tanto, esto puede no ser un trabajo para Community Tech. Necesitamos una acción clara que requiere ingeniería. Lo siento, pero podemos tener que archivar esto propuesta. Fue un placer hablar contigo. Espero contribuir a la Wikipedia de español una día, cuando entiendo español mejor :)

    ¡Gracias por participar en la Encuesta de los Deseos! MusikAnimal (WMF) (talk) 20:58, 21 November 2017 (UTC)[reply]

    Split Properties and Identifiers into two separate Classes

     N Out of scope for Community Tech

    • Problem: Currently for each new identifier a new Property is needed, so more than an half of the properties are now Identifiers. With more imports and Wikidata acting as the centre of the Linked Web, more identifiers will be needed.
    • Who would benefit: Users and editors
    • Proposed solution: Add a new Class into the Wikibase ontology called Identifier, optionally as a subClass of Property. Move the current properties describing identifiers to Identifier class (so Youtube Playlist, aka P4300, will be used as I4300), allowing a redirect. New identifiers should be only created under the Identifier class, starting with I1 and jumping the already used numbers.
    • More comments:
    • Phabricator tickets:

    Discussion edit

    I don't see the fact that half of the properties are identifiers as a problem in itself. Can you explain in more detail why you think it's a problem and how changing the architecture would be better and worth the added complexity? ChristianKl (talk) 18:15, 9 November 2017 (UTC)[reply]

    One minor issue with using "I" for identifier is that is easily confused with "1". --Papuass (talk) 09:46, 10 November 2017 (UTC)[reply]
    Or with "l" for that matter. ChristianKl (talk) 16:18, 10 November 2017 (UTC)[reply]
    It would at very least better support the current split in the entity view between statements and identifiers (see also this proposal). It's not only a purely aesthetic purpose IMHO. --Sabas88 (talk) 11:26, 13 November 2017 (UTC)[reply]
    • We can find another letter for identifiers, this is definitely a minor issue. I think it might be a good idea to separate identifiers from the other properties. Also, normal ontologies have some degree of separation between properties that describe an object/subject/concept and properties that describe, well, their identification number in other databases. --Sannita - not just another it.wiki sysop 11:12, 13 November 2017 (UTC)[reply]
    • I also do not see what is the problem. Ok so in our GUI we separate properties into two groups: statements and identifiers and the split is about 50/50. So what is the issue. Renaming some properties from P4300 to I4300 is an unnecessary complication. --Jarekt (talk) 13:57, 16 November 2017 (UTC)[reply]

    Archived edit

    This is a serious change that goes outside of scope for our survey. A prerequisite for technical work here would be a consultation with Wikidata community and developers on your proposed ontology change. This survey is a wrong venue to do that. Thanks for participating. Max Semenik (talk) 21:30, 21 November 2017 (UTC) [reply]

    Fix talk pages

     N Out of scope for Community Tech

    • Problem: Wikipedia contributors without Mediawiki experience are irritated by the (lack of a proper) user interface on talk pages.
    • Who would benefit: All contributors taking part in discussions.
    • Proposed solution: For example, there should be buttons to add a reply to an existing topic or to add a new topic. The structure (currently achieved through indentation) as well as the name of the user and the date of the contribution should be handled automatically.
    • More comments: The current talk page format follows the wiki philosophy, but when we want constructive discussions, this seems like romantic fundamentalism. Let's make discussions more approachable for everyone.
    • Phabricator tickets:

    Discussion edit

    Well, it won't harm giving this project a boost by including it in the wishlist, right? --Gnom (talk) Let's make Wikipedia green! 19:04, 19 November 2017 (UTC)[reply]
    • Since Flow is more a long term solution, that requires a cear cut and therefore ist neglegted by many communities, we additionally need a short-/mid-term solution that attaches itself to the current wikitext-base and enriches it with a standard no-thrills commentary-functionality. I had quite a lot of discussions on this topic during the Wikimania in Montreal and we outlined a way to do that something like this with JavaScript. A Script that injects a "comment here"-box at the bottom of each section. Und than takes all the text, the user enteres there, to the wikitext, automatically adding ::: and --~~~~ if missing.
      Of course this is a hacky solution, but hacky solutions are kind of tradition in this project. And hey: Almost anything is more understandable and convenient for common newbies than the status quo. // Martin Kraft (talk) 18:29, 20 November 2017 (UTC)[reply]

    Hi Bernd.Brincken: This proposal is asking for Structured Discussions -- an important but ambitious & complicated project. We don't want to make that space even more confusing by creating another version of it. :) I'm going to archive this proposal, thanks for participating in the survey. -- DannyH (WMF) (talk) 20:59, 20 November 2017 (UTC)[reply]

    Hi DannyH (WMF), I think that there is no need to archive this wish - many votes might instead encourage the Wikimedia Foundation to direct more resources at the "important but ambitious & complicated" issue of finally, finally, finally fixing talk pages. --Gnom (talk) Let's make Wikipedia green! 08:53, 21 November 2017 (UTC)[reply]
    Hi Gnom, while I agree that fixing talk pages is an important goal for the WMF, this simply isn't a project that the Community Tech team can undertake. As our scope definition explains, we aren't able to work on large, long-term development projects, especially ones that are already being handled by other teams. The purpose of this survey is to identify projects for the Community Tech team to work on, and if we can't realistically work on it, it doesn't make sense to have people vote on it. Kaldari (talk) 18:19, 21 November 2017 (UTC)[reply]
    Hi Kaldari, I am very confused. I have the impression that "difficult" wishes are deliberately being "archived". This way, "small" and "fun" things get done, while more "important" yet "bigger" improvements are moved out of sight. Is this really what we should be doing here? Couldn't this survey also cover wishes that are maybe too big for the Community Tech team, and therefore have to be tackled by other teams, under the condition that the community finds their fulfillment worthwile? --Gnom (talk) Let's make Wikipedia green! 20:57, 21 November 2017 (UTC)[reply]
    Hi Gnom: No, the purpose of this survey is to find projects for the Community Tech team to work on. We're archiving proposals that are beyond the scope of what our team can do, because we don't want to mislead people. If people vote for this proposal, then they'd assume we're going to work on it, and we already know that this is out of scope for our team. I'm going to archive this again. -- DannyH (WMF) (talk) 21:30, 21 November 2017 (UTC)[reply]

    @DannyH (WMF): I just saw, that this wish has been speed-archived to. And like User:Gnom, I am really disappointed about that. The dysfunctionality of the talk pages is one of the mayor problems, when it comes to recruiting the new authors we desperately need in Wikipedia. Due to this desgin-failure, we loose potential new authors every single day. And since the WMF obviously is not able to provide and implement a large scale solution for the talk pages since years, we need to adopt a different approach.

    This wish is not about a large scale long term solution but about a short term fix with limited effort. Since I am a interaction designer and web developer my self, I can assure you, that a skilled CSS/JS-programmer should be able possible to implement the progressive enhancement solution for talk-pages (as the one I described above) within max 2-3 weeks of working time. If you don't think so, please layout in detail why!

    This wish clearly is within the scope of the technical wishes project and it should be part of the Survey. I therefore urge you to de-archive this wish and bring it back to the survey starting today. // Martin Kraft (talk) 10:59, 27 November 2017 (UTC)[reply]

    Hi Martin, I totally agree that making talk pages easier to use is really important. It's also very complicated, because it touches half the pages on our projects. One reason why it's complicated is that it's hard to define what a single "post" is -- people edit talk pages for a lot of different reasons, including editing their own post, editing someone else's, reordering posts or threads, and splitting threads. You can't assume that each edit = a new message, so how do you let the system know what kind of edit this is? There's also a lot of complexity to the way people reply to other people's posts, which would have to be specially built. We could go on and talk about this more, but the bottom line is that this isn't in the scope of a Community Wishlist Survey proposal. -- DannyH (WMF) (talk) 17:59, 27 November 2017 (UTC)[reply]
    @DannyH (WMF): That's why I mentioned de:Progressive Enhancement. The idea is not to replace the recent way to edit talk pages, but to add an easy and accessible way to do handle the most simple task of adding a comment. And to implement something like this definitly is not rocket science and therefore well within the scope of your project and a foreseeable task. // Martin Kraft (talk) 22:05, 27 November 2017 (UTC)[reply]
    FWIW, this sounds like en:User:Enterprisey/reply-link. --Elitre (WMF) (talk) 18:00, 27 November 2017 (UTC)[reply]
    @Elitre (WMF): Thanks, that is almost exactly what I hat in mind. But the point is: We need something like this not only for experienced users able to edit their common.js but for newbies and unregistered users. And to implement that is the purpose of this technical wish. // Martin Kraft (talk) 22:05, 27 November 2017 (UTC)[reply]
    Hi Martin, we're not taking votes on archived proposals. -- DannyH (WMF) (talk) 21:42, 27 November 2017 (UTC)[reply]
    This proposal shouldn't be archived but part of the survey. // Martin Kraft (talk) 22:05, 27 November 2017 (UTC)[reply]
    "Structured Discussions -- an important but ambitious & complicated project. We don't want to make that space even more confusing by creating another version of it." Sigh. I can only encourage you to support the right solution - which means to reduce the ambitious project to a normal, simple, feasable one. If a Javascript addition can achieve this, fine. --Bernd.Brincken (talk) 00:56, 28 November 2017 (UTC)[reply]

    Allow embedding of query results in Wikipedia

    • Problem: we have a great query system, with timetable, map or graphs showing up and everybody can use it... except us. There's no way to embed dynamically generated query answers in Wikipedia.
    • Who would benefit: Wikipedia readers, as they can see good quality and interactive elements within articles.
    • Proposed solution: Maybe a bypass of iframe ban on Wikipedia could be done for Wikidata query results.
    • More comments:
    • Phabricator tickets:

    Discussion edit

    @Theklan:, could you provide a few concrete example of what you want? Max Semenik (talk) 01:04, 21 November 2017 (UTC)[reply]

    I assume it's to be able to embed the results of a Wikidata service query into a wiki page, presumably by writing the SQL into the wiki page (between some bracketed magic words) and then the wiki display the results. (Probably the problem would be caching.) Right now there is a bot that serves as a proxy, User:ListeriaBot, that can provide this. --Izno (talk) 04:29, 21 November 2017 (UTC)[reply]
    Listeriabot creates lists. There's no way to embed dynamic maps or timetables. -Theklan (talk) 11:44, 21 November 2017 (UTC)[reply]
    Another bot could be developed to output GeoJSON or another Map extension-friendly format. Timetables might be SOL on regardless since they would probably rely on HTML on the Mediawiki blacklist (but maybe not). --Izno (talk) 14:08, 21 November 2017 (UTC)[reply]
    But this approach is different. Query content is dinamyc, so we can zoom in or out, pan, drag, click, see... and every other option that is not an iframe embedding would make static maps (as happens with graph extension). -Theklan (talk) 21:45, 21 November 2017 (UTC)[reply]

    @MaxSem:: if we make this query we can see a map. The map has an an embed result that gives this code: 

    <iframe style="width: 80vw; height: 50vh; border: none;" src="https://query.wikidata.org/embed.html#%23defaultView%3AMap%0ASELECT%20%3Fitem%20%3Fkoord%20%3Firudia%20WHERE%20%7B%0A%20%20%3Fitem%20wdt%3AP131%2a%20%3Fnon.%0A%20%20wd%3AQ47588%20wdt%3AP527%20%3Fnon.%0A%20%20%3Fitem%20wdt%3AP31%20wd%3AQ513550.%0A%20%20%3Fitem%20wdt%3AP625%20%3Fkoord.%0A%20%20OPTIONAL%20%7B%20%3Fnon%20wdt%3AP18%20%3Firudia.%20%7D%0A%7D" referrerpolicy="origin" sandbox="allow-scripts allow-same-origin allow-popups" ></iframe>

    This code can't be embedded in Wikipedia, so we can't benefit of dynamic maps in our articles. The same happens for timelines. Look at this query. And now try to embed the timeline somehow in an article. Impossible, isn't it? But all the people except Wikipedians can embed it via an iframe in their blog, app... and it seems quite weird for me not to be able to reuse something that we are creating. -Theklan (talk) 11:49, 21 November 2017 (UTC)[reply]

    The problem here is that current WDQS setup is nowhere near as powerful as required for this to happen on Wikipedia. We have some discussions to give it more servers, but even if these plans will be set in motion, the work won't start before the second half of 2018, which means that Community Tech will not be able to work on this project before the next survey. Another problem is query duration: it's very easy to write a slow query that will run for multiple seconds which means that page saving will take much longer which will negatively affect contributors' experience. Considering all this, I'm archiving this proposal, with the understanding that next year the situation might be different and at least some parts of this proposal might be workable. Max Semenik (talk) 22:33, 21 November 2017 (UTC)[reply]

    Recognize .djvu file as wikisource index file (placeholder)

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

    Discussion edit

    Please do not post comments here, but at the other page: 2017 Community Wishlist Survey/Wikidata/Recognize .djvu file as wikisource index file

    We don't use placeholders like this in the survey. Each proposal should be in one category. I'm going to archive this placeholder proposal. Thanks for participating in the survey. -- DannyH (WMF) (talk) 23:16, 21 November 2017 (UTC)[reply]

    交互式

    • Problem: 目前wiki的信息交互模式，依然是文字加图片，或者是gif等方式。因此，我想wiki可以有力量突破下现有的交互模式，增加一些新的交互方式。例如，用鼠标即可操控UV轴的H5页面镶嵌进wiki的百科页面，相关词条对应的不仅仅是一张照片，一个窗口可以浏览几十，几百，几千甚至上万的照片叠加，相关联，这些照片都放在后台，前端通过H5，CSS，js即可做到。我个人认为这一技术在即将到来的5G高速时代，将会很受青睐。
      • Google translation: In the current wiki information exchange mode, there is text plus still pictures, or gifs, etc. I would like a wiki which can have the power to break through the existing interactive mode, add new interactive way. For example, you can use the mouse to manipulate UV axis of H5 embedded into wiki pages of Wikipedia pages related entries corresponding to more than just a picture, a window can browse dozens, hundreds, thousands or even tens of thousands of photos superimposed associated, these photos are placed in the background, you can do it through the front H5, CSS, js. Personally, I think this technology in the upcoming 5G high-speed era, will be appreciated.
    • Who would benefit: wiki用户，所有浏览该词条的人都会更加直观的认识对应信息。
      • Google translation: Wiki users, browse the entries of all people will be more intuitive understanding of the corresponding information.

    http://www.zhongshengteam.com/dougong/misdirection/ http://www.zhongshengteam.com/dougong/move/ http://www.zhongshengteam.com/project/model_speed/ http://www.zhongshengteam.com/project/panorama_h5/

      • Google translation: H5, CSS, JS. There are cases here, is my personal work in the company, for reference....(followed by links)
    • More comments: 我不知道，相关的文件是放在哪里合适？内容的制作者的服务器引出的外链供wiki使用还是把所有的文件都交给wiki，放在wiki的服务器上。
      • Google translation: I do not know where to put the relevant files are appropriate? Outside the chain producers of content server drawn for wiki use or all the files to the wiki, wiki on a server.
    • Phabricator tickets:

    Community discussion edit

    @BlackC: What is "H5"? (Did you mean HTML5?) If I understand this proposal correctly, it's about making information on Wikipedia pages more interactive? Could you provide some specific examples what you would like to see? Thanks in advance! --AKlapper (WMF) (talk) 21:11, 8 November 2017 (UTC)[reply]

    Ping: User:Liuxinyu970226 or User:Shizhao, could you help clarify what the user means? My Chinese is not good enough. /Johan (WMF) (talk) 16:29, 20 November 2017 (UTC)[reply]

    BlackC: AKlapper asked you for clarification on Nov 8th, and you haven't provided any. We'll have to archive this proposal. Thanks for participating in the survey. -- DannyH (WMF) (talk) 23:30, 21 November 2017 (UTC) [reply]

    Search function in a category

    • Problem: Sometimes, there are large categorys on Commons with pictures. It is difficult to navigate in it and navigation is too limited.
    • Who would benefit: Editors of Wikiprojects who wants to use files and readers who wants use files with free licenses.
    • Proposed solution: Introduce a system like Google Search/Bing search where you can select for example, which color of image you want, which size, in what order, which license, if you want to see only images or only videos etc. Especially the function to order files in a category by upload date seems me interesting.
    • More comments:
    • Phabricator tickets:

    Discussion edit

    LIVE NIEUWS: I have good news on this one -- the Multimedia team's Structured Data on Commons project will make this kind of search possible. I'm going to archive this proposal. Thanks for participating in the survey! -- DannyH (WMF) (talk) 18:08, 22 November 2017 (UTC) [reply]

    Generate reference from ISBN

    • Problem: To add references of books manually is way too long and at the same time it may be automatized
    • Who would benefit: Editors, having more time to edit, Wikipedia recieving more bites
    • Proposed solution: Write a code, which will be taking data from ISBN, ČSN (Older Czech code) and other national databases and generation reference. User will just have to add e.g. page from, which it is cited.
    • More comments: I know, there is a bug about this. The last news are the our developers is waiting to the database owners. But I wonder, weather there is just one database. Google is able to get such data, so why Wikipedia not. More over there might be other local databases - e.g. Czech used before the switch to ISBN in 1990s ČSN. Ask User:Mormegil, who knows about it and is able to tell you weather, the database is ready to use.
    • Phabricator tickets:

    Discussion edit

    Have you tried a RefToolbar gadget? It can fill in the pre-defined template form from given ISBN, URL, DOI or PMID, if the pertinent information is available. --Vachovec1 (talk) 18:50, 12 November 2017 (UTC)[reply]

    Use native video player

      Merged with another proposal

    • Problem: our current video player is severely outdated and outclassed by browsers' native players. It's clumsy and its UI doesn't look well on modern high resolution screens.
    • Who would benefit: readers and editors alike
    • Proposed solution: use native HTML5 player
    • More comments: we can sacrifice being able to show videos to 2-3% of our viewers which sounds like a good tradeoff to me as long as we the rest of our readers don't have to suffer the Kaltura player anymore.
    • Phabricator tickets:

    Discussion edit

    I don’t know what HTML5 is capable of, but a link to the file description page is needed for copyright reasons, subtitles have no point if they can’t be used, and the quality selection is also useful. —Tacsipacsi (talk) 13:45, 20 November 2017 (UTC)[reply]

    Archived edit

    Merged this proposal into 2017 Community Wishlist Survey/Multimedia and Commons/Use native audio/video player. Max Semenik (talk) 01:23, 23 November 2017 (UTC) [reply]

    Specialised blocks

      Merged with another proposal

    • Problem: Currently the one way administrators can block users is by taking away all editing privileges, this is regardless of what caused the block in the first place, someone can be a good content editor but less than civil in the talk pages, or someone can be good at discussing things in talk pages but revert war in the articles themselves.
    • Who would benefit: Everyone, as content editors wouldn’t be prevented from continuing to improve content and metapedians who are lousy at content editing can continue to give good comments about the content itself.
    • Proposed solution: Blocks that exclusively apply to certain features, for example “Talk:XXX” blocks for users who have abused their ability to edit talk pages, or blocks that only apply to mainspace articles, or “Wikipedia:XXX”/”Commons:XXX” but not restrict uploading privileges or the the other way around where good content editors add copyrighted images be restricted from uploading exclusively, for sockpuppetry this could be account creation, or restricting only a single account to edit on an IP, for e-mail abuses this could only be disallowing that particular user to e-mail other users, Etc.
    • More comments: Currently the editor retention is low, after having experienced non-stop (and still ongoing) threats and insults (especially in the IRC) purely based on the fact that I'm a blocked editor I don't find this exodus surprising, one of the reason why people leave is because all editing privileges are revoked with a block and topic bans are a lot rarer than blocks even if many blocks are based on similar reasons.

    Well, the reason I want this to be a thing is because there was a global lock 🔒 requested for a photographer who’s content I really like, on September 1st I drafted this message for Wikimedia Commons:

    “Verzonden: vrijdag 1 september 2017 04:42:07 Aan: Donald Trung Onderwerp: Unblock Classiccardinal.

    Classiccardinal is a great photographer, just because he can only speak in insults and harasses Hedwig in Washington and Yann doesn't mean that he should be barred from uploading his great pictures that benefit other Wikimedia projects, another measure should be taken to prevent his disruptive behaviour such as an interaction ban with the people he keeps harassing or another form of ban where his ability to edit talk pages and userpages is prevented while he could still upload pictures. He has been on Commonswiki for years and his contributions here benefit the project, Commons should be about the images and not its community. --Donald Trung 15:56, 11 November 2017 (UTC)”[reply]

    But seeing the seriousness of this user’s harassment I don't have any immediate plans for requesting an unblock for them as they still don't seem to have learned to behave, but I don't think 🤔 that the community should miss high quality great pictures 📷 because the photographer can’t behave, maybe there are other ways to address this like making an “upload-only” user-class, but having specialised blocks might prevent any such harassment while great photographs such as [ these] can continued to be uploaded. Well, that’s why I think 🤔 why having such a feature would be greatly beneficial. --Donald Trung (Talk 🤳🏻) 15:56, 11 November 2017 (UTC)[reply]

    • Phabricator tickets:

    Discussion edit

    This has been merged with 2017 Community Wishlist Survey/Admins and stewards/Allow further user block options ("can edit XY" etc.). /Johan (WMF) (talk) 02:34, 25 November 2017 (UTC) [reply]

    Multilevel Structured Discussions

     N Out of scope for Community Tech

    • Problem: In the big discussions in the Structured Discussions (Flow), the conversation turns into a wall of text. And it is not easy to analyze and read.
    • Who would benefit: experienced editors, discussion readers
    • Proposed solution: Give editors the opportunity to choose the presentation of the discussion as they are used to. (user settings or single board settings) Store in the comment data about clicking on which "Reply" it was created. Show as we do in Wikitext: display 15 levels (or at the choice of the editor), then start the ladder again on the left with the initial indentation and the transfer designation en:Template:Outdent. In mobile form, this can be with a reduced indentation of the nodes of the ladder and remove the indentation where the ladder is without nodes of branches.
    • More comments:

    Discussion edit

    • It's no problem. Flow indent's system is fine. —Be nt all (talk) 17:56, 11 November 2017 (UTC)[reply]
      • Not for all. Many people say that there is a lack of logic and narrative threads in serious big discussions. Messages appear in the heap, analyze the dependencies in which for people (especially those who did not participate in the discussion, but who read it) excess work. --Sunpriat (talk) 11:01, 12 November 2017 (UTC)[reply]
    • Indentation model of Flow is good. There is a problem with a storage model of Flow, that stored discussions as a plain lists of messages with indentation values.--Tucvbif (talk) 22:42, 11 November 2017 (UTC)[reply]
    • Going to disagree with commentators above, the indentation model of Flow is not good at all, it does not make sense to any person that is already familiar with commenting systems on other websites. When I click ‘Reply’, I expect the message that gets sent out to be on another level from the message I am replying to, not in some preferential order that this system is using. It generally looks like a bug in the system every single time. stjn[ru] 11:14, 12 November 2017 (UTC)[reply]
    • Simply disable Flow, ordinary structured discussions, as they take place on normal talk pages, are far better manageable for editors. OK, not for bots, but they should take second row always. Flow is just a weak forum impersonation without any real structure, far too little indentation levels, not clear ratios between posts in longer discussions, no possibilty to rearrange the structure of meandering discussions, completely inflexible so far less useful. OK, machines seem to deal better with this rigid, inflexible corset, but machines are irrelevant compared to humans, and disussions are for humans, not for machines. Grüße vom Sänger ♫(Reden) 22:22, 14 November 2017 (UTC)[reply]
    Hi Sunpriat, I'm afraid that I have to archive this proposal, for the same reason that we've archived similar proposals this year. Working on Structured Discussions/Flow/talk pages is too big for the Community Tech team to work on this year. Sorry for notifying you so late. Thanks for participating in the survey. -- DannyH (WMF) (talk) 18:30, 27 November 2017 (UTC)[reply]

    Replace labels and aliases

    • Problem:

    Currently, labels and aliases are entered via a simple text field, with no scope of usage ascribed to them. This has several problems:

    • the two tier system forces editors to choose a primary identifying term (the label), which means all other terms get relegated to secondary status (the aliases)
    • the item or property fails to explain the context in which the term is used
    • the Wikidata interface dumbly displays the label of the property or item whenever that property/item is used in a statement, regardless of the context

    Some usage examples:

    Q1976332 has the English label 'cooler' and the English aliases 'portable ice chest', 'ice box', 'cool box', 'chilly bin', 'esky' & 'Ice Chest'. English Wikipedia states: "In the United Kingdom the common name is a "cool-box". In the United States they are usually called a "cooler". In New Zealand they are generally called a "chilly bin", a generic trademark; the common Australian name of "Esky" is also a generic trademark". Yet none of this geographical usage information is provided in the Wikidata item. These geographic differences are particularly important in cases where an identical term has different meanings in different places, e.g. the two meanings of 'biscuit'.

    Sometimes linguistic differences have little to do with geography. The people officiating sporting contests can be called referees in some sports and umpires in others. The Wikidata property (P1652) uses 'referee' as the English label and has 'umpire' as an alias. This means 'referee' is used on items relating to sports where the correct term is 'umpire'.

    • Who would benefit:

    Editors and readers of Wikidata, who would be provided not just with a list of terms for the same concept but also an explanation of the context in which they are used.

    • Proposed solution:

    Develop a replacement for labels and aliases by adapting the key–value pair technology currently used for statements. Provide a way for editors to develop and manage rules around the usage of each term (similar to property constraints); e.g. P1652 should display as 'referee' when used in items about association football but should display as 'umpire' when used in items about Australian rules football.

    • More comments:
    • Phabricator tickets:

    Discussion edit

    If you want the UK name of the label you can use "en-uk" as your language which has a fallback to "en". I don't see the problem. ChristianKl (talk) 18:55, 24 November 2017 (UTC)[reply]

    Voting edit

    Hi Gareth, After consulting with the Wikidata team, we've determined that Community Tech can't work on this proposal. Lydia, the product manager for Wikidata, says: "Labels and aliases are intentionally kept simple so they can be used in Wikipedia, for search in Wikidata and also outside Wikimedia. A part of this proposal will be addressed with the work we are currently doing on lexicographical data in Wikidata to support Wiktionary." We have to defer to Lydia on this, so I'm going to archive this proposal. Sorry for the late notice, and thanks for participating in the survey. -- DannyH (WMF) (talk) 22:02, 27 November 2017 (UTC) [reply]

    Automatic Wikimedia table updater from Google docs

     N Created after proposal phase ended.

    • Problem: Maintaining and updating the table that presents the programme schedule for Wikimedia conferences is both tedious and unnecessarily difficult. Especially for large events like Wikimania where up to one hundred events can take place. Events change with increasing intensity until the day of the conference (and even on that day). Conference attendees need to be accurately kept informed on what is happening when. For the programme manager/s who have to keep track of these rapid changes this is currently VERY difficult as the table system built into Media Wiki is not optimal for this situation. Spreadsheets are better suited for this task but are not well suited to display this information to conference attendees. As such a tool or bot that allows the programme manager to plan and schedule events on a google spreadsheet and then automatically publish those changes with the push of a button would fix that problem.
    • The current system, or lack there of, increases stress on the programme manager
    • The current system, or lack there of, greatly increases the likelihood of errors being made on the programme displayed to the public
    • The current system, or lack there of, is time consuming and laborious
    • Who would benefit: All current and future organisers of events that relay on an accurate and up-to-date table on a Media Wiki platform. Such as Wikimania, Wiki Indaba, WikiCon, etc. The most immediate beneficiaries would be the programme committee of Wikimania 2018.
    • Proposed solution: A bot or tool that could auto-update changes made to a Google Spreadsheet at the touch of a button. In other words, a change is made on the google spreadsheet, the tool is used to publish that change onto the programme table on the Media Wiki website hosting the programme on a page like the Wikimania 2018 programme schedule on the Wikimania 2018 website.
    • Phabricator tickets:

    Discussion edit

    We're talking about tables such as this - https://wikimania2017.wikimedia.org/wiki/Programme/Friday Wittylama (talk) 09:38, 28 November 2017 (UTC)[reply]

    Wikipedia 2.0 zwecks Erreichung eines größeren Leser- bzw. Nutzer- und last not least Spenderkreises

     N Created after proposal phase ended

    • Problem: Der Artikel Bluthochdruck existiert nicht in der deutschen Wikipedia. Stattdessen leitet der Suchbegriff "Bluthochdruck" um auf einen medizinischen Fachartikel mit Ausdrucksweise-Ungetümen wie Zitat "Die Leistungssteigerung auf dem Ergometer und die verminderte Belastungsdyspnoe sind auch auf eine Abnahme der links ventrikulären Hypertrophie (LVH) und die Besserung der diastolischen Funktion zurückzuführen.", und das gerade in einem Abschnitt, der auch Patienten interessieren könnte, wenn sie ihn nur verstehen könnten.
    • Wem würde dieser Wunsch helfen: 50% der Bevölkerung Deutschlands sind ungefähr laut dem Artikel im Laufe ihres Lebens von Bluthochdruck betroffen. Ein beträchtlicher Anteil davon hat weder eine medizinische noch eine pharmazeutische Ausbildung. Das Wissen über Bluthochdruck kann aber lebenswichtig sein, wiewohl die Risiken dieser physiologischen Erscheinung je nach Stärke ihres individuellen Autretens sich nur statistisch als entsprechend dieser Stärke höhere Folgeerscheinungs-, Krankheits- und Todesraten darstellen. Eines der bevorzugten Nachschlagewerke in Deutschland ist mittlerweile ganz zweifelsfrei die Wikipedia. Ihr Inhalt sollte sich daher auch dem Laien korrekt erschließen, zumal wenn sich ein Artikel um lebenswichtige Dinge für 50% der Bevölkerung dreht.
    • Lösungsvorschlag: Es wird ein Artikel "Bluthochdruck, umfassend erklärt für Laien" angelegt, der die ganzen Pseudograecolatinodeutschen Fachwortungetüme möglichst überhaupt nicht gebraucht und wo nötig einfach erklärt. Die Weiterleitung Bluthochdruck bleibt bestehen, jedoch in einer neuen Form der Weiterleitung, die das Konzept Wikipedia 2.0 kennzeichnen soll: Auf den medizinischen Fachartikel voller Fachlatein wird nur derjenige umgeleitet, der in seinem Wikipedia-Nutzerprofil angegeben hat, medizinisches Fachwissen zu besitzen. Wer dies nicht in seinem Benutzerprofil stehen hat, wird von derselben Weiterleitung umgeleitet auf den einigermaßen streng in verständlichem Deutsch verfassten Artikel Bluthochdruck, umfassend erklärt für Laien. Wer kein Benutzerprofil angibt, kann meinetwegen weiterhin mit Fachartikeln bombardiert werden ;-) Genauso sollten andere Fachartikel behandelt werden, d.h. in Benutzerprofilen kann auch angegeben werden, dass man wirtschaftswissenschaftliches Wissen besitzt, so das zu komplexen zentralen Begriffen der Wirtschaft entsprechende profilgesteuerte Weiterleitungen greifen.
    • Weitere Kommentare:

    Anmerkung zu diesem Beitrag in der englischsprachigen Meta-Wiki: Die Sprache dieses Vorschlages ist Deutsch. Er bezieht sich ja auch auf die Deutsche Wikipedia.

    Hint for english-speaking readers: The language of this proposal is German. It reflects a problem of the German Wikipedia. It suggests the replacement of the REDIRECT by a user-profile-controlled REDIRECT to achieve better understandability of articles that should be available in specialists language as well as in the people's language.

    • Phabricator-Tickets:

    Diskussion edit

    • @Uwe Kulick: (German) (Google translate) Es tut uns leid! Dies wurde erstellt, nachdem die Angebotsphase beendet wurde. Ich bewege es in die Archive. Danke für Ihre Teilnahme, trotzdem!

      (English) Sorry! This was created after the proposal phase ended. I am moving it to the archives. Thanks for your participation, nonetheless! MusikAnimal (WMF) (talk) 15:43, 28 November 2017 (UTC)[reply]

    Allow multiple entries within each category

     N Created after proposal phase ended

    • Problem: Sometimes, multiple entries within a category would be useful. For instance, on the French wiktionary there is a listing of French verbs that includes both the infinitive form (e.g. aimer) and a pronominal form (s’aimer). But which sort key should be given to the pronominal form? Equally valid arguments apply for a « aimer s » key and a « saimer » key. Ideally, the entry would appear twice in the category, under those two keys. There are other examples, such as proper nouns beginning with a definite article (e.g. Le Mans should be categorised under « Mans Le » and « Le Mans »).
    • Who would benefit: Wiktionaries, other wiki projects.
    • Proposed solution: Possibly add to the wiki software a magic word that can be used to specify a second (third, fourth, etc.) entry in a category’s index. Other wikicode approaches may be possible.
    • Phabricator tickets:

    Discussion edit

    Last year's proposal received a terse opposition comment that merely stated the proposal was "not well-cooked". That was unhelpful. It is not for the proposer to advance a technical answer, it's up to the developers to figure out the least disruptive, most efficient way of satisfying the proposal.
    I'll conclude by adding that this could be merged with the proposal for Context-dependent sort keys, depending on the technical solution chosen. Urhixidur (talk) 17:32, 8 December 2017 (UTC)[reply]
    @Urhixidur: Sorry, the proposal phase has ended, so we unfortunately can't accept this. I have moved it to the archives. Thanks for your participation, and look forward to any proposals you may have next year! MusikAnimal (WMF) (talk) 17:34, 8 December 2017 (UTC)[reply]
    Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2017/Archive&oldid=20401073"