Jump to content

Community Wishlist Survey 2020/Archive

Add links
From Meta, a Wikimedia project coordination wiki

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

Adnaper

NoN No information given

Discussion

Yaşallıqların artırılması

NoN Insufficient information given

  • Problem:
  • Who would benefit:
  • Proposed solution:
  • More comments:
YAŞILLIQLARIN ARTIRILMASI
Həyatdakı canlılar naminə yaşıllıqların artırılması
Bununla bağlı lahiyələrin keçirilməsi 
Faydası həyatdakı bütün canlılara
 
Muhammadali Suleymanli

Discussion

Automatic translation by Google Translate (Azeri language)

Increase of greens
Increasing greenery for living things
Carrying out related projects
The benefit to all living things

@Muhammadali Suleymanli: what is the link with Wiktionary project? Pamputt (talk) 17:14, 1 November 2019 (UTC)[reply]

I am archiving this as it is incomplete and does not clearly define a problem. Once we get more information we can unarchive it.

@Muhammadali Suleymanli:, Zəhmət olmasa texniki problemin nə olduğunu daha çox təsvir edin. (machine translation for "Please describe the technical problem more"). Thanks, MusikAnimal (WMF) (talk) 18:15, 1 November 2019 (UTC)[reply]

Image inheritance, a bequest safe for Wikimedia Commons

NoN Does not qualify for the 2020 survey

  • Problem: Thousands of my pictures – probably millions of images from other Wikimedians – would be lost because they can currently(!) not be publicly published. We Wikimedians who are alive today can't upload the images if we're no longer alive, when these images in the future no longer restricted by copyright.
    Deutsch: ("Tausende Bilder von mir - wahrscheinlich Millionen Bilder von anderen Wikipedianern werden verloren gehen, weil sie aktuell(!) nicht veröffentlicht werden dürfen und wir heute lebenden Wikipedianer nicht mehr leben werden und also die Bilder nicht mehr hochladen können, wenn sie in Zukunft keinen Einschräkungen mehr unterliegen werden.")
  • Who would benefit: Wikimedia Commons and all its users.
    Deutsch: ("Wikimedia Commons und all seinen Benutzer*innen")
  • Proposed solution: I would like to be able to upload photos to a "private" – with a, to the normal ID, unrelated password – and extra protected user space. I'm thinking of interior photos, information boards, texts and so on. These photos are currently not covered by the Freedom of Panorama and must immediately be deleted. I would like to upload these photos "today", but save them for "later" (my digital "bequest", my "photo inheritance" for Wikimedia Commons).

    The way I envision it is that these files would 100 years after the uploading automatically be made free. Until then, they would just be available for administrators and myself. At the same would I already put these images "hidden" in the "proper" categories – but not available to non-administrators!

    Deutsch: ("Sehr gern würde ich Fotos in einen „privaten“ - mit einem von der „normalen“ Kennung unabhängigen Passwort – und extra geschützten Benutzer-Bereich hochladen.

    Ich denke dabei zum Beispiel an Fotos von Innenräumen, Informationstafeln, Texten usw. Diese Fotos unterliegen aktuell nicht der Panoramafreiheit und müssten sofort gelöscht werden. Ich möchte diese Fotos aber „heute“ für „später“ hochladen (mein digitales „Vermächtnis“ / mein „Bild-Erbe“ für Wikimedia Commons ).

    Meine Vorstellung ist, dass diese Aufnahmen etwa 100 Jahre nach dem Hochladen automatisch frei geschaltet werden. Bis dahin wären sie nur für Administratoren und mich selbst sichtbar. Gleichzeitig würde ich die Bilder schon „versteckt“ in die „richtigen“ Kategorie einfügen wollen - für Nicht-Administratoren unsichtbar!")

  • Antragsteller: Molgreen 10:38, 3 November 2019 (UTC)

Diskussion

Adaptation of 17th-18th century French writing in contemporary language

NoN No information given

Discussion

I think we should be able to offer old books in modern French. This could be of interest to a wider audience and easier to read. Personally, I have a lot of trouble concentrating for a long time on the old French historical books. I need more time to finish the book. Many simply give up opening the book. Could we create this category and propose the 2? Thank's DS — The preceding unsigned comment was added by Dragonsquadron (talk)

Hi Dragonsquadron! Could you fill out all the fields above? Specifically, what is the technical problem, and what kind of solutions are you proposing, if any? Note also that unfortunately, proposals can't belong in more than one category. Could we create this category and propose the 2? -- could you clarify what you're requesting? Vous pouvez communiquer en français, si vous le souhaitez! Merci, MusikAnimal (WMF) (talk) 18:25, 24 October 2019 (UTC)[reply]

I'm sorry, but we can't accept proposals that don't provide all the required information. Additionally, from what's already provided it seems like this proposal is not about a problem with software, so it's out pof scope for our survey. MaxSem (WMF) (talk) 19:47, 6 November 2019 (UTC) [reply]

Enable move-subpages for all autoconfirmed Wikibooks users

NoN Requires community consensus

  • Problem: Consider the page Raku Programming on Wikibooks, for example. The page was moved from "Perl 6 Programming" by JoaquinFerrero. The same user then moved all of the subpages hours later. But it would be tedious to move all of a book's subpages manually.
  • Who would benefit: Users moving books with subpages on Wikibooks.
  • Proposed solution: Enable the move-subpages right for all autoconfirmed Wikibooks users.
  • More comments:
  • Phabricator tickets:
  • Proposer: GeoffreyT2000 (talk) 03:50, 31 October 2019 (UTC)[reply]

Discussion

Subject diversity

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

  • Problem: On most of the active language versions, there is a substantial lack of subject diversity and far too little focus on what real news actually is supposed to be. Most of the more active language versions now focus mainly on sport-related topics, while the "real" news items (especially worldwide important events) hardly get serious attention (on the other hand, they appear almost immediately on Wikipedia, where they actually do not belong that soon, being still very "fresh" and therefore not yet suitable for an encyclopaedia). This way, Wikinews can hardly present itself as what it pretends to be.
  • Who would benefit: Especially the readers
  • Proposed solution: More editors who write about topics such as politics, worldwide important events etc. should be attracted. Perhaps some change in the software could help in that regard.
  • More comments:
  • Phabricator tickets:
  • Proposer: De Wikischim (talk) 08:35, 26 October 2019 (UTC)[reply]

Discussion

  • Is their some way we could incentivise contribution? How do people want to be incentivized? U+1F360 (talk) 15:09, 27 October 2019 (UTC)[reply]
  • News type items often get deleted from the various Wikipedia sites as not appropriate. May be there could be some transfer to WikiNews of these deleted items to a holding area where they could be reviewed and potentially republished there. Keith D (talk) 23:36, 27 October 2019 (UTC)[reply]
  • A few miscellaneous remarks. (Small point: Wikinews, not WikiNews.)
  • Each Wikinews project has its own particular position on how to approach "news". The two most extremely divergent approaches, afaik, are taken by en.wn and nl.wn. I, for example, coming from en.wn, find the nl.wn attitude deeply frustrating (if not appalling), and I take it many of the folks at nl.wn are similarly discomfitted by the en.wn attitude. I have for many years taken a live-and-let-live attitude, that these diverse-language Wikinews projects should collegially allow each other self-determination, without trying to proselytize on the other Wikinews projects.
  • The user who started this thread (De Wikischim) has not, historically, practiced my live-and-let-live approach to cross-wiki relations. Their behavior in this regard on en.wn has led to an ongoing project-specific administrative case (to wit, DW has been blocked on en.wn for over a year).
  • The project licenses are not compatible, so that it would be in general a copyright violation to move content from Wikipedia to Wikinews. Also, speaking of the English edition, standards are so different between en.wp and en.wn that a complete rewrite would usually be needed anyway.
--Pi zero (talk) 14:17, 29 October 2019 (UTC)[reply]
  • This does not present a technical problem, so unfortunately we are unable to help. I suspect the best course of action would be to participate in some sort of outreach, host edit-a-thons, and so forth. For this reason I am going to archive this proposal as a social problem. Thank you for participating in the survey! MusikAnimal (WMF) (talk) 19:52, 10 November 2019 (UTC)[reply]

Structured Wikiquote

NoN Outside the scope of Community Tech

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

Discussion

  • Some more data structure than exists today is probably for the better, but too much structure, as the proposal seems to indicate, is sure to stifle participation. It's a typical organisational tradeoff of people vs process. Guarapiranga (talk) 10:01, 23 October 2019 (UTC)[reply]
    • Thanks for your support! My hope is that it would encourage participation as the quotations would be easier to reuse on our projects (by embeding them) and outside of them (by linking to them). Having them translated in a single place I think is also a huge win. However, I imagine there would need to be some (small?) UI adjustments to Wikibase for Wikiquote that would make it easier/faster to contribute quotations. For instance, if Wikibase's label is going to be the quoatation itself, then it probably ought to look like a quote on the page, rather than a title (just as an example). U+1F360 (talk) 14:04, 23 October 2019 (UTC)[reply]
  • This is not a technical proposal, it's a policy discussion which should first achieve consensus within the Wikiquote community. I don't think it's eligible for consideration in the wishlist survey, unless some Wikiquote subdomain starts doing something towards the goal of a "structured Wikiquote" and ends up hitting some technical limitations. Nemo 16:05, 24 October 2019 (UTC)[reply]
    • I think it's both technical and policy, but there aren't many changes on our projects that don't require some sort of community consensus. Regardless, this needs a product/development team to champion. Otherwise it will never happen. I think Community Tech could be that team (if they think they can accomplish it within their parameters). I think the scope could be reduced to creating an MVP of what this would even look like, and perhaps making the UI changes necessary to Wikibase. U+1F360 (talk) 16:10, 24 October 2019 (UTC)[reply]
  • I definitely support this proposal. I think it's a great idea! Liamjamesperritt (talk) 03:29, 25 October 2019 (UTC)[reply]
  • I strongly support this proposal. I'd also like to see social media integration so that users could share individual quotes with one another on social media. AdamSobieski (talk) 03:27, 28 October 2019 (UTC)[reply]
  • Support. Each quote should have its source and its original language, one wikiquote or use wikidata is a solution--Esceptic0 (talk) 04:01, 29 October 2019 (UTC)[reply]
  • Oppose. This is a risky change of policy which should get a feedback from all communities.--DanHa (talk) 12:27, 1 November 2019 (UTC)[reply]
  • Strong support. I have messed around with this in test.wikidata and on a domain I own but I can't seem to think thru how it would work in practice. Seems like a great idea tho. —Justin (koavf)❤T☮C☺M☯ 19:34, 2 November 2019 (UTC)[reply]
  • Support. Then hopefully incubator:Wq/mul will be merged into the new Wikiquote.--Jusjih (talk) 04:19, 4 November 2019 (UTC)[reply]
  • This is a very popular proposal, and we also think it's a great idea! We have discussed it and unfortunately have concluded this would involve a long-term engineering effort that is simply too big for Community Tech. Working on this would compromise our ability to work on other wishes within schedule. As others have pointed out, it seems this proposal may need further community discussion as well. That said, I'm going to archive this as out of scope. We apologize for any disappointment, and thank you for your participation in the survey! MusikAnimal (WMF) (talk) 20:05, 10 November 2019 (UTC)[reply]

hOCR should work for all wikisource

NoN Merged into Community Wishlist Survey 2020/Wikisource/New OCR tool.

Discussion

Phe's tool has suffered some serious difficulties recently and nobody seems to be able to solve them, see phab:T228594. That is why I have suggested replacing this external tool with a brand new tool that would be an integral part of MediaWiki and would not be dependent on availability of a specific single and unreachable volunteer (see the proposal New OCR tool). I suggest to merge our proposals. --Jan.Kamenicek (talk) 20:24, 26 October 2019 (UTC)[reply]

@Jan.Kamenicek, thanks for your reply. Both proposals can be merge in one, if you have no issue. Jayantanth (talk) 07:23, 27 October 2019 (UTC)[reply]
@Jayantanth: I have merged it, can you check please, whether I worded it properly there? Thanks! --Jan.Kamenicek (talk) 11:59, 27 October 2019 (UTC)[reply]

Improve OCR with wikisource texts

NoN Has been merged into Community Wishlist Survey 2020/Wikisource/New OCR tool.

  • Problem: Users on multiple wikisources have complained that the OCR is not good enough, with letters with diatrics mentioned being especially bad.
  • Who would benefit: All users in languages which are both supported by Tesseract (close to 100 languages or language variants) and WMF has an wikisource on. The main content of wikisource comes from copying books that have an expired copyright. OCR is used in this process. Wikisource uses (among other things) the Google Cloud OCR, which uses Tesseract and the phetools ocr on labs which uses Tesseract as well. On top of that are some wikisource users who use Tesseract on their own computers. This proposal would improve OCR tools present on the ToolLabs. The better the OCR the easier the process is with each book, allowing wikisource editors to become more productive, completing more pages than they could do previously. This would also motivate users on Wikisource.
  • Proposed solution: Tesseract has an specific procedure to training OCR which requires corrected text of an page and an image of the page itself. On the Wikisource side, pages that have been marked as proofread, shows books that have been transcribed and reviewed fully. So, what needs to be done is to strip formatting the text of these finished trascriptions, expand template transclusions and move references to the bottom. Then take the text along with an image of the page in question and run it through Tesseracts procedure. The improvement would then be updated on ToolLabs.
  • More comments: Tesseract is an open source application.

This proposal was merged into Community Wishlist Survey 2020/Wikisource/New OCR tool.

Discussion

yeah, we have a backlog of uploaded texts that have a text layer that did not get included, but require a manual use of OCR button. OCR quality is a major pain point. Slowking4 (talk) 00:14, 24 October 2019 (UTC)[reply]
Also note that Wikisource OCR doesn't work properly with italic and small-caps text. Adding support for these, would be a huge improvement. Kaldari (talk) 16:11, 30 October 2019 (UTC)[reply]
Also texts in fraktur are very problematic. JAn Dudík (talk) 11:15, 31 October 2019 (UTC)[reply]
  • I checked the fraktur issue, and I would need 100+ A4 pages worth of 18th century texts (16-17th century is ok, too, but I did not check that). Your main wikisource (cs.wikisource) does not have that. This proposal will improve those languages that do have Fraktur support, namely Danish, German, Slovak and Swedish (that is an exhaustive list, btw.).
  • I do not know enough about the italic and bold issue to comment on it.--Snaevar (talk) 15:43, 8 November 2019 (UTC)[reply]
@Snaevar: I wonder if you might want to merge this proposal with Jan.Kamenicek's proposal: New OCR tool. I think one unified proposal would probably get more votes than two similar proposals on their own. Kaldari (talk) 16:18, 30 October 2019 (UTC)[reply]
I will answer the merge proposal on the main talk page of Community Wishlist Survey 2020.--Snaevar (talk) 15:43, 8 November 2019 (UTC)[reply]
@IFried (WMF): Note that this proposal has been merged into New OCR tool. Kaldari (talk) 16:10, 12 November 2019 (UTC)[reply]

Change in software geo-feature

NoN Insufficient informative given

Discussion

Comments in Local Time

YesY Wish granted!

Discussion

  • But, I'm are Chinese user. I can't see this feature in the language I use. Also, how do I put this component in Gadgets? —The preceding unsigned comment was added by Kitabc12345 (talk)
  • I think travel websites should be personalized for people in different time zones and even different countries. English is a universal language and is the official language and common language of many countries and regions in the world. Some languages have not yet done a Wikiyoyage project, and travelers need to access the material in a second language (English) they may know. Therefore, I really think this gadget is very useful. --Kitabc12345 (talk) 05:16, 8 November 2019 (UTC)[reply]

Notice of editing conflict

NoN This proposal is global

  • Problem: On many wikimedia projects conflicts can arise, when more users are editing the same file unbeknownst to each other. (I remember that in Oracle databases, you got a warning or (b)lock when someone else was already editing an entry you wanted to edit. Just a popup (or another type of message, perhaps even better) would do on Wikimedia sites, say Wikipedia, Wikibooks, Commons, Wikidata, when you start an editing session on a file someone else is already editing.
  • Who would benefit: all editors
  • Proposed solution: warning message, perhaps not a lock/block on the file i don't know, that would give the opportunity to prevent others from editing (abuse)?
  • More comments:
  • Phabricator tickets:
  • Proposer: Hansmuller (talk) 21:10, 10 November 2019 (UTC)[reply]

Discussion

providing commercial e books

NoN Proposes a legal change rather than a technical feature

Discussion

PUBLISHING COMMERCIAL ACADEMIC BOOKS CAN PROVIDE FINENCIAL RELIEF TO THE READERS FROM BUYING EXPENSIVE BOOKS. JUST LIKE: httpswww.pdfdrive.comcategory3 Surajsharma2000 (talk) 12:37, 10 November 2019 (UTC)[reply]

Species identification features

NoN Proposes a social change rather than a technical feature

  • Problem:
  • Who would benefit: Readers
  • Proposed solution: A species identification tool, as a separate feature. In every page describing a particular species, a separate box can be given which gives the major/salient features which helps you identify the species when you see it. It may be given as bullet points. This will help readers confirm whether the photo they have or the animal they saw indeed belonged to that particular species.
  • More comments:
  • Phabricator tickets:
  • Proposer: Jyothimohan (talk) 03:47, 26 October 2019 (UTC)[reply]

Discussion

  • Automated species identification suggests that this might be out of reach of major corporations and even a moon-shot level effort by the whole of humanity. Abductive (talk) 20:37, 26 October 2019 (UTC)[reply]
  • iNaturalist has some machine-learning that will suggest likely IDs, but there are so may cryptic species and ones that need micrographs of spores/pollen/reproductive organs that it will never be perfect. Still a pretty good start. I don't think it is WikiSpecies role to identify species. Best we could do is point to monographs that have the information. --NessieVL (talk) 17:19, 31 October 2019 (UTC)[reply]
  • As a person who professionally identifies species within my field of expertise I can say it is difficult and takes a significant amount of experience and practice, it is also not equally feasible acroos species groups. I agree with the above comment that it not really in our domain either. However, we could provide links to not just monographs as suggested above but other resources that can do this. There are many discussion groups around specialized groups where people can put up photos asking for identifications. However I do not think this needs any tools just a policy decision on Wikispecies that we are willing to include it and how. Cheers Scott Thomson (Faendalimas) talk 21:36, 2 November 2019 (UTC)[reply]
  • Same thought as Faendalimas: sounds like this just needs a policy decision on Wikispecies, not a software tool. Kaldari (talk) 22:28, 12 November 2019 (UTC)[reply]
  • Per above, this proposal as written does not seem to require any engineering assistance, so I am going to archive it. Templates could likely satisfy your needs, following a community discussion on how to use them for this purpose. Thanks for your participation! MusikAnimal (WMF) (talk) 16:00, 14 November 2019 (UTC)[reply]

electronic course features analysis

NoN Proposes a social change rather than a technical feature

  • Problem: it is challenging to create courses.
  • Who would benefit: learners, course providers
  • Proposed solution: create a working group with a single target: analyze learning platforms and come up with a list of features for wikiversity to support electronic courses, see e.g. edX python for data science as an example. this then can be piped into a technical analysis respective feasibility via use existing, build new, not support at all.
  • More comments:
  • Phabricator tickets:
  • Proposer: ThurnerRupert (talk) 05:41, 24 October 2019 (UTC)[reply]

Discussion

feel free to adjust/extend the proposal, and add your name as proposer. --ThurnerRupert (talk) 05:41, 24 October 2019 (UTC)[reply]

There already a lot of open-source learning-platform software packages. It might be possible to reuse code as well as feature ideas. HLHJ (talk) 22:00, 3 November 2019 (UTC)[reply]

I think this is more like a goal for Wikiversity community themselves, not for developers. The Wikiversity community itself should decide what they want, not Wikimedia Tech group. Juandev (talk) 08:39, 4 November 2019 (UTC)[reply]

Create official curricula

NoN Proposes a social change rather than a technical feature

  • Problem: Inconsistent course quality and the general lack of direction for learners.
  • Who would benefit: Learners and contributors
  • Proposed solution: We should create official curriculums, then official courses, like a framework for Wikiversity. Contributors then contribute to improve those curriculums and courses. This way collaboration effort is more focused, increase course quality. This suit Wikiversity better as a open collaboration community. Students will also have better time find the right course.
  • More comments:
  • Phabricator tickets:
  • Proposer: Razel01 (talk) 04:47, 27 October 2019 (UTC)[reply]

Discussion

  • It looks interesting, but I did not understand very well the possible details of this proposals. Reading "curriculums" two ideas comes into my mind:
    • "Curriculums of learners": a sort of list of what the learner has learnt on Wikiversity, i.e. completed courses, completed modules, completed lessons, etc. This list could be a self-declaration of learners (simple to implement, but with very poor value in term of "accreditation") or a list generated by an automated mechanism (for example after the completion of a questionnaire that gives a link to the page where everyone can check the questionnaire completed by user - but in this case other users could read it and do the same without studying the subject) or an evaluation made by other users (this case is more difficult to implement, because we do not have so much users competent in each subject and available for doing the evaluation)
    • "Curriculum of editors": it could be a simple list of courses/modules/lessons/etc. at which every users had contributed. In this case I do not see any particular usefulness, because the same information are available in the chronology of pages. Did you have any other idea about it? --Daniele Pugliesi (talk) 20:52, 30 October 2019 (UTC)[reply]

Improve drag and drop options in Visual Editor

NoN This proposal is global

  • Problem: There are other more attractive platforms for teaching/learning nowadays. Younger learners cannot read. Some people have difficulties with understanding wiki code.
  • Who would benefit: Wikiversity itself, by attracting more users.
  • Proposed solution: Provide better functionality of drag and drop in Visual Editor. Today, you can move some parts of the text or images within the page edited with the use of VE, but it's still clumsy (e.g. you cannot move the image at whatever position you want). So the proposed improvements might be:
    • allow the user, to drag and drop image at whatever place on the page
    • provide an icon for enlarging/making small the image that the user, can change image dimensions by mouse
    • provide the user with an easy way to create a gallery by moving images within the page by mouse
    • provide other image design on the page other than a gallery (e.g. images in the circle)
    • allow the user to highlight the block of the text, move it and set its background and border color after deployment
    • possibly allow inter-project transclusion, that a sample of text from Wikipedia, Wikibooks, can be drag and drop onto Wikiversity page
    • allow or provide other types of functionality, which will make Wikiversity more attractive and allow it to be used also by younger learners who do not know wiki code or text at all.
  • More comments:
  • Phabricator tickets:
  • Proposer: Juandev (talk) 09:40, 4 November 2019 (UTC)[reply]

Discussion

  • Unfortunately this proposal does not qualify for the 2020 survey because it is global, so I am going to archive it. We agree it would greatly assist Wikiversity, but it would equally effect other projects. We want to exclusively focus on solving technical problems for smaller projects, since such issues don't normally get the attention they deserve. We can still pass your feedback on to the Editing team who maintains VisualEditor in hopes they can make some of the suggested improvements. Thanks for participating in the survey! MusikAnimal (WMF) (talk) 16:46, 14 November 2019 (UTC)[reply]

Managment of research name space title on fr.wikiversity

NoN Does not require any development work

  • Problem: Specifically on French wikiversity, we decided to create a name space for research article. But since this decision we still have a proble to hide the « namespace: » displaying on articles' title.
  • Who would benefit: Editors and readers of research name space on fr.wikiversity
  • Proposed solution: Actually, the solution to hide the name space on the title is to to use the template Titre incorrect in a research presentation banner template. But this solution create a bug displaying in French just after saving a new edition with this text : "En raison de limitations techniques, la typographie souhaitable du titre, « ... », n'a pu être restituée correctement ci-dessus.". That's a bite annoying.
  • More comments:
  • Phabricator tickets:
  • Proposer: Lionel Scheepmans ✉ Contact French native speaker, sorry for my dysorthography 11:22, 6 November 2019 (UTC)[reply]

Discussion

Hi Lionel Scheepmans, this feature already exists: there's a configuration setting that controls restrictions on what {{DISPLAYTITLE}} can do. With it, you can change the displayed title much more drastically, including the namespace removal. Your community can request it to be changed for your wiki using this process. Since no development work is needed here, I'm archiving this proposal. MaxSem (WMF) (talk) 21:05, 14 November 2019 (UTC)[reply]

Ok, thank you MaxSem (WMF), Lionel Scheepmans ✉ Contact French native speaker, sorry for my dysorthography 23:43, 14 November 2019 (UTC)

Transclude wikipedia template, module pages on small project as Wikiversity

NoN Outside the scope of Community Tech

  • Problem: On Wikiversity as on other small wikimedia online projects, we don't have a user community big enough to compete with Wikipedia template and module creation. So we must usually import them from Wikipédia. Especialy on Wikivesity because the pedagogical project is very close to the encyclopedic one in term of edition. Same bibliographic citation for instance. Actually, the import and update work make by administrator is not easy. We are doing this with the page special:import and it's a real nightmare if we want to merge history of pages in the respect of the license and the transparency.
  • If a page name already exist on wikiversity with an other contain or function, the import overwrites the old page to establish the new one. By the way, trouble on the website organization can arise (example of conversation that appear in French Wikiversity after a template importation : https://fr.wikiversity.org/wiki/Sujet:V8jhz8s6sp17evpx).
  • Actually, the import option « Include all models » of the page special:import is really risky because of that. Finally the template or module pages must be frequently updated due to their evolution on Wikipedia and that's also a difficulty for administrators to make this repetitive task.
  • Who would benefit: Wikiversity and potentially other small wiki administrators and users.
  • Proposed solution: Extension:InterwikiExtracts permits to transclude articles from one Wikimedia project to another but unfortunately not template or module pages. A similar MediaWiki extension for template and module could be so a very powerful tool for enhancing collaboration and contain integration between all Wikimedia project. That's also a good way for not duplicate content from one project to an other and to concentrate the force of all Wikimedia technical contributors on single pages and single place. In the long run, a multi language Wikimedia technical commons, similar to Wikimedia Commons but for gathering template, modules, gadgets, and other technical wiki pages available for all projects and transcludable with an exention as scary transclusion could be a great idea!
  • More comments:
  • Phabricator tickets:
  • Proposer: Lionel Scheepmans ✉ Contact French native speaker, sorry for my dysorthography 00:39, 29 October 2019 (UTC)[reply]

Discussion

Wiki-based slideshows/posters

NoN Merged with Wikiversity/Sample skins for presentations

There is often a small screen facing the presenter, and a big screen facing the audience; the presenter's screen may show slide notes and timing information
  • Problem: Currently, if you want to upload a presentation to Wikimedia, you convert it to a PDF and put it on Commons. This format is not easily modifiable, reusable, or accessible. If you want to display Mediawiki pages on a big screen, you can use the F11 key to fullscreen the browser content (try it now; hit F11 again to return). But that leaves the screen cluttered with Mediawiki sidebars, and there are no convenient navigation functions for switching between slides.
  • Who would benefit: Anyone wanting to give a slideshow talk, or reuse wiki content in a talk, or vice-versa. Wikiversity users have a particular interest in putting lecture slides online.
  • Proposed solution: A Mediawiki implementation of a web-based slideshow, allowing wiki pages to be used as fullscreen presentation slides. A good addition would be a download/export function to get a flat file containing the presentation. Ideally, there should be second screen capability, so that the presenter can also see a countdown timer and a short set of point-form notes per slide.
  • More comments: Mediawiki obviously already renders in browsers, so this might be a fairly easy way to provide a really useful functionality. It could also attract users and content to Wikiversity.
    • The same format could be used to display an academic poster, made with existing Wikiversity tools, on a screen. SVG already does this well, but less wiki-reusably.
    • The W3C has a (flat-file) format and freely-licensed implementation, HTML Slidy, which might be useful. It exports/is XML; PDF export might also be useful, and might overlap with the article-export proposal.
    • I'm not sure whether it would be appropriate to do this with a skin (skin experts, I'd welcome your comments). If a skin with slide-navigation functions would be OK, then we could do the rest with a template taking, as parameters, a list of the wiki pages/sections to be used as slides, and displaying a slide-thumbnail menu with switch-skin links. Any page with that template would then become a slideshow. Perhaps second-screen capability could be done with a popup?
  • Phabricator tickets:
  • Proposer: HLHJ (talk) 23:45, 3 November 2019 (UTC)[reply]

Discussion

Your proposal could be found in these proposals:

Juandev (talk) 10:00, 6 November 2019 (UTC)[reply]

Sorry, Juandev, just saw this. I'd be happy to merge to this proposal with the sample-skins one. I think the article-PDF proposal has a different goal, although it would be possible to use some of the same technical tools in doing both. I've tried to separate the wish from possible implementation methods, as I am not the best judge of the latter, but I've mentioned the possible overlap in the proposal. HLHJ (talk)
Thanks to Bawolff for assessing the technical difficulty ("at a glance sounds do-able and an apprppriate difficulty level for community wishlist"). HLHJ (talk) 18:37, 9 November 2019 (UTC)[reply]
We agree that this proposal is very similar to Sample skins for presentations, so I am archiving this one (with our system we cannot simply redirect, I'm sorry to say!). @HLHJ: Please feel free to copy over whatever information you'd like to the new proposal. Thank you both for participating in the survey! MusikAnimal (WMF) (talk) 16:15, 15 November 2019 (UTC)[reply]

Wikibase sandbox

NoN Outside the scope of Community Tech

  • Problem: On Wikiversities we have some database-like research projects (eg. Bloom Clock (beta, cs, en), Dreams (cs)). They are based on collecting observations and further (statistical) analysis. Unfortunately, the core projects are based on technically difficult parser functions and other techniques, which creates difficult its dissemination to other languages mutation or keeping them alive when original creators are gone.
  • Who would benefit: Everybody involved in these projects, gardeners, psychologists and others who may use the results of the research, potential new users, who may be attracted to the new easier way of contribution/participation.
  • Proposed solution: Provide Wikiversity community with sandbox wiki with Wikibase and possibility of creating its own properties and items.
  • More comments: Wikiversity community may experiment with it to see, whether such a solution would ease its database related projects. Other possible uses in teaching/learning might be discovered.
  • Phabricator tickets:
  • Proposer: Juandev (talk) 08:24, 4 November 2019 (UTC)[reply]

Discussion

Wanted (by articles) pages

NoN This proposal is global

  • Problem: Difficult to easily see what pages are really missing on the site. Current Special:WantedPages such as voy:Special:WantedPages shows a list that are mainly red links on talk and project pages not main space article pages. Takes a lot of clicking to see which pages are really needed.
  • Who would benefit: Article authors looking for ideas for pages to create. Clean-up contributors looking for problem links.
  • Proposed solution: Create a page similar to Special:WantedPages but the number of redlinks shown to only be from mainspace pages and not talk and admin pages. One alternative idea is to make the existing page a table with a column showing number of redlinks from each namespace type (mainspace, talk of article, user page, template, ....) and make it possible to reorder the table based on descending number of each source page type.
  • More comments: This is not about filtering the page type of the wanted pages but of the namespace of the source of the redlinks.
  • Phabricator tickets: T208935
  • Proposer: Traveler100 (talk) 06:18, 10 November 2019 (UTC)[reply]

Discussion

Unfortunately this proposal does not qualify for the 2020 survey because it is global, so I am going to archive it. toolforge:missingtopics and PetScan may serve as short-term solutions. Thanks for participating in the survey! MusikAnimal (WMF) (talk) 16:38, 15 November 2019 (UTC) [reply]

Left-align inflection tables

NoN Proposes a social/aesthetic change that can be made by the community

  • Problem: Inflection and declension tables in the Wiktionary are often confusing because the text in those tables is centered by default. Left-aligned text would make it easier to read the columns.
  • Who would benefit: Users who are not yet profound in a foreign language or script, those who need more time and effort to find and compare different forms of a word.
  • Proposed solution: For example the CSS property text-align: left; together with text-indent.
  • More comments:
  • Phabricator tickets:
  • Proposer: Dialectum (talk) 12:57, 4 November 2019 (UTC)[reply]

Discussion

  • This survey is for technical development, not for frontend adjustment such as your proposal. This is something easy to change locally, and I suppose your message is made with one specific version in mind, isn't it? I suggest you ask to this concerned community first, to see if there is a will to do so. If not, it is something easy to fix with a gadget. - Noé (talk) 14:33, 4 November 2019 (UTC)[reply]
  • Indeed the proposed changes do not require external engineering resources, so I am going to archive this proposal. Thanks for participating in the survey! MusikAnimal (WMF) (talk) 16:48, 15 November 2019 (UTC)[reply]

Audio lookup of words

NoN Outside the scope of Community Tech

  • Problem: Especially with English, it is sometimes the case that someone wants to look up a work that they know how to say but do not know how to spell. Often this is with the goal of finding out how to spell the word. Without already knowing a word's spelling, it is difficult to find words such as phlegm, xylophone, schism or cello.
  • Who would benefit: This will be beneficial to anyone trying to find out how to spell an English word that does not have one obvious spelling.
  • Proposed solution: Use the IPA and/or audio clips associated with a word to generate a hash signature of its pronunciation. Add a feature to the UI to allow users to search by speaking a word. This will record the user speaking the word, generate a hash signature of the recording and then search for words with a matching hash signature. If only one word matches the search show the user that word. Otherwise, first show the user a summary of the words that match.
  • More comments:
  • Phabricator tickets:
  • Proposer: Mgrand (talk) 12:31, 9 November 2019 (UTC)[reply]

Discussion

  • As a French speaker, I can't say it is especially for English. Plenty languages have writing difficulties. Looking for the proper way of writing a word is a regular motivation to use a dictionary for those languages. The proposal Search in a lexicon challenge a similar issue, because a proper search could also be able to deal with IPA. But you are mentioning a search based on audio, and that's something different. Saying something to a microphone to trigger the search could be awesome, and useful not only for Wiktionaries Noé (talk) 17:21, 12 November 2019 (UTC)[reply]
  • This is a great idea! Unfortunately after discussing it as a team, we have concluded this would require long-term engineering efforts that we cannot afford. It is currently not feasible to recognize speech patterns or even to pronounce words from IPA. As such I'm going to archive this proposal as out of scope. Apologies for the disappointment, and thank you for participating in the survey! MusikAnimal (WMF) (talk) 17:11, 15 November 2019 (UTC)[reply]
    Hi MusikAnimal, do you think it could be post next year in the Community Wishlist or is it anyway an idea that is too big? If it is how could we suggest this idea properly, where? Is there's any process to collect this kind of suggestions? Noé (talk) 17:58, 15 November 2019 (UTC)[reply]
    To me it seems like a fairly large machine learning prospect. Google for instance doesn't get pronunciations and speech recognition perfectly either (I think it often relies on context within a full sentence), and they have a lot more resources then us. I think making this happen within our infrastructure would be a lengthy multi-team effort. I would recommend creating a Phabricator task for now, and from there we can hopefully at least put together some technical requirements. I guess use the "Wiktionary" tag. There is also WikiSpeech but this seems to be more about text-to-speech, and not the opposite. As a workaround, if you have a capable phone you could use the built-in speech-to-text in your browser to enter words into the Wiktionary search bar. MusikAnimal (WMF) (talk) 21:56, 15 November 2019 (UTC)[reply]
    Thank you for this feedback. I am aware this proposal is about a feature this is at the edge of actual techs, but I think our projects deserve this kind of very fancy features to attract a new audience. So, I will continue to think about it and then post it in Phabricator. Noé (talk) 07:14, 20 November 2019 (UTC)[reply]

Choice of the wiktionary project-wide sorting policy for categories

NoN Proposes a social/policy change rather than a technical feature

  • Problem: Several sorting policies can be used in dictionaries. The most usual one (policy 1) sorts according to letters and digits, removing everything else (e.g. red fox is considered as redfox for the purpose of sorting, and A/N as AN. However, when all phrases get separate entries, it may be better to use a different policy (policy 2): some dictionaries, including fr.wikt, consider that everything not a letter or a digit is replaced by a single space, except apostrophs, which are removed. Examples: presqu'île is sorted as presquile but A/N is sorted as A N and boulanger-pâtissier is sorted as boulanger patissier. This leads to an order such as boulanger, boulanger-pâtissier, boulangerie rather than boulanger, boulangerie, boulanger-pâtissier. The current fr.wikt solution is the addition of a sortkey to each page with a title including special characters such as - or ' or / etc.
  • Who would benefit: all editors creating pages for words with a - or ' or / etc.
  • Proposed solution: a project-wide parameter specifying one of the policies above (policy 1 or policy 2), or no policy ("no policy" would lead to the use of the category collation without any special treatment (assuming that the " Multiple collations per site" proposal is adopted, I hope so)).
  • More comments:
  • Phabricator tickets:
  • Proposer: Lmaltier (talk) 20:41, 8 November 2019 (UTC)[reply]

Discussion

  • Is this project-wide or should this alphabetical orders be recorded in MediaWiki in order to be use the same way in each Wiktionary and in each other projects using MediaWiki software out of the Wikimedia Foundation's projects? To phrase it from another point of view: is French tradition of ordering English the same as German tradition of ordering English and so on? Noé (talk) 14:15, 15 November 2019 (UTC)[reply]
    • It's a dictionary policy depending mainly on the number of phrasal entries in the dictionary; when there are many phrases as separate entries, one option is better; when phrases are included in separate word entries, the issue is different. Lmaltier (talk) 21:21, 21 November 2019 (UTC)[reply]
  • We have discussed this as a team and it seems there are no engineering resources needed. Simply find consensus for the collation you wish to have on your wiki, and request it on Phabricator. Please let us know if we're misunderstanding you. Thanks for participating in the survey! MusikAnimal (WMF) (talk) 17:37, 15 November 2019 (UTC)[reply]
    • @MusikAnimal (WMF): Simply find consensus for the collation: this proposal has nothing to do with collations (for collations, I support the "Multiple collations per site" proposal, as the collation needed depends on the category language). There are many possible collations (more or less one per language) but only a few general sorting policies used by dictionaries, the ones I mention above. Please read the proposal again: it's something very important in dictionaries. Rejecting the proposal without any discussion because of a misunderstanding would be a pity. Lmaltier (talk) 21:22, 21 November 2019 (UTC)[reply]

Lives

NoN Outside the scope of Community Tech

  • Problem: Lives
  • Who would benefit: The visitors because they have a new way to follow the news. The editors because they don't need to edit the page for a new comment. All people because they don't have to reload the page to view a new comment.
  • Proposed solution: Create an extension, which will be associated with a page type, in the form of a time bar, where will be indicated the time, and a small logo (if specified) of what happened, with right, the comment, and the edit/history buttons.
  • More comments: The anniversary of Wikinews is being celebrated very soon. The deployment of the extension would be a plus.
  • Phabricator tickets:
  • Proposer: AirSThib (Flight attendant · Flights) 15:54, 24 October 2019 (UTC)[reply]

Discussion

@AirSThib: it's not clear what do you mean exactly, maybe you could post an example link to this on some other news site? MaxSem (WMF) (talk) 00:19, 30 October 2019 (UTC)[reply]

@MaxSem (WMF): This is the schema. AirSThib (Flight attendant · Flights), the 15:47, 31 October 2019 (UTC).[reply]
@MaxSem (WMF): If you want a link, see for exemple https://www.eurosport.fr/formule-1/grand-prix-du-mexique/2019/live-course_mtc1085013/live.shtml. AirSThib (Flight attendant · Flights), the 09:25, 1 November 2019 (UTC)[reply]
I like this idea.. While Wikinews generally has been rather 'weak' in terms of traction, what we have seen, is that it and even more so Wikipedia, tend to be very popular in vetting and summarising news during or shortly after the event. I think a live feed option, where we can keep track of verified and non-verified information/retractions etc can be a worthy and interesting addition that could open up new possibilities in untapped areas. —TheDJ (talk • contribs) 12:37, 4 November 2019 (UTC)[reply]
@TheDJ: Hi and thanks ! AirSThib (Flight attendant · Flights), the 17:50, 6 November 2019 (UTC).[reply]

@AirSThib: Thanks for submitting the wish! We have discussed this wish as a team, and we unfortunately determined that it is out of scope. We apologize for any disappointment, and thank you for your participation in the survey! --IFried (WMF) (talk) 23:27, 18 November 2019 (UTC)[reply]

@IFried (WMF): Hello. It is impossible to release or it's incorrect ? AirSThib (Flight attendant · Flights), the 14:06, 20 November 2019 (UTC).[reply]
@AirSThib: Bonjour, et merci pour la réponse! Si je comprends bien votre question, vous demandez si le souhait est impossible à mettre en œuvre. Si tel est le cas, non, ce n'est pas impossible à mettre en œuvre. Cependant, c'est un très grand souhait L’équipe prend généralement beaucoup de temps et prend beaucoup de ressources. Nous avons tendance à entreprendre des projets plus modestes, qui peuvent être achevés en quelques mois. Pour cette raison, nous l’avons marqué comme étant au-delà de la portée. Nous nous excusons pour tout déception et merci d’avoir participé à l’enquête! En outre, j’ai utilisé la traduction automatique, je vous présente donc mes excuses pour toute erreur en français.
En anglais/In English: Hello, and thanks for the response! If I understand your question correctly, you're asking if the wish is impossible to implement. If this is the case, no, it's not impossible to implement. However, it is a very large wish, and the work would take a great deal of time and resources for the team. We tend to take on smaller projects, which can be completed in a few months. For this reason, we have marked it as beyond scope. We apologize for any disappointment, and thank you for participating in the survey! --IFried (WMF) (talk) 17:31, 20 November 2019 (UTC)[reply]

Modern Interface for Video Course's

NoN Unclear proposal / Requires community consensus

  • Problem: Create an extension only for Wikiversity so that author's can have more easy options when adding 'Video Courses' & wiki functionality will be unchanged.
  • Who would benefit: The Wikiversity users , course authors .all the learning community that Wikimedia Foundation project can support.it will certainly give a boost to fulfill Wikiversity & the wikimedias goal.
  • Proposed solution:

Front-end standards group doing this type of tusk from a long time.

Community tech team could get valuable insight by consulting with them.

"Kaltura" already have most of the video related solutions that are required. we should contact with them to get assistance. The mw:Extension:TimedMediaHandler tech Team would know better.

Discussion

It's not clear exactly what the new interface should look like, or what solutions it should offer that are missing in the current interface. Furthermore, I believe this needs community consensus first. I recommend brainstorming some ideas with your community, finding consensus for how the new interface should look and function, then re-propose in next year's survey. Finally, I suspect creating a new extension from scratch might be a long-term effort that is beyond our scope. For now I'm going to archive this proposal, but please let me know if I'm misunderstanding you. Thanks for your participation! MusikAnimal (WMF) (talk) 00:00, 19 November 2019 (UTC) [reply]

Improve workflow for uploading academic papers to Wikisource

NoN Not enough information

5-minute documentary on medics using Internet-in-a-Box in the Dominican Republic, where many medical facilities have no internet. These medics would presumably also appreciate better access to the research literature (Doc James?).
Likewise the staff of the University of Ngaoundéré, which has a slow, expensive satellite connection, but also has local-network Afripedia access
...and biologists doing field research
  • Opportunity: There are a large and increasing number of suitably-licensed new Wikisource texts: academic papers (strikingly-illustrated example on Wikisource). Many articles are now published under CC-BY or CC-BY-SA licenses, and with fully-machine-readable formats; initiatives like Plan S will further this trend.
  • Problem: Uploading these articles is needlessly difficult, and few are on Wikisource.
  • Who would benefit: Having these papers on Wikisource (or a daughter project) would benefit:
  1. anyone accessing open-access fulltexts online. There is an ongoing conflict between traditional academic-article publishers and the open-access movement in academia, and some publishers have done things which make freely-licensed article fulltexts harder to access (for instance, one publisher has paywalled open-access articles, pressured academics and third-party hosters to take down fulltexts (examples), charged for Creative-Commons licensed materials,[1] sought to retroactively add NC restrictions to Creative Commons licenses, forbidden republication of CC-licensed articles on some platforms at some times, and acted with the apparent aim of making legal free fulltexts harder to find [2]); it also bought out a sharing platform (example). Wikimedia has social and legal clout to resist such tactics, and is well-indexed by search tools.
  2. anyone wanting offline access to the academic literature (through Internet-in-a-Box): people with poor internet connectivity (including field scientists), or censorship
  3. those who have difficulties reading non-accessible content. Some online journals work hideously badly with screenreaders.
  4. anyone wishing to archive a previously published paper, including the Wikijournals (journals go bust and go offline, and many research funders require third-party archiving)
  5. those using the fulltexts for other Wikimedia projects (e.g. Wikipedia sourcing, academic article illustrations copied to Commons for reuse)
  • Proposed solution: Create an importer tool for suitable articles, with a GUI.
  • More comments:
    • Konrad Foerstner's JATS-to-Mediawiki importer does just this, but seems stuck in pre-alpha.
      • Even the citation-metadata scrapers which we already use could automate much of the formatting.
      • Another apparently-related tool is the possibly-proprietary Pubchunks.
    • The #Icanhazwikidata system allows academics to add academic-paper metadata to Wikidata by tweeting an identifier; Magnus Manske's Source Metadata tool added it automatically. An #Icanhazfulltexthosting system could allow uploading a fulltext by tweeting a fulltext link (with some feedback if your linked PDF lacks the needed machine-readable layer).

Discussion

Thanks to Daniel Mietchen for the example article. I've made a lot of statements about projects I don't know much about, and would appreciate advice and corrections. HLHJ (talk) 02:02, 9 November 2019 (UTC)[reply]

Us becoming a repository for high quality open access journals is a good idea. We just need to be careful that we do not include predatory publishers. Doc James (talk · contribs · email) 09:22, 9 November 2019 (UTC)[reply]
Agreed. Plan S and such look as if they may help more broadly with that, too. HLHJ (talk) 01:11, 21 November 2019 (UTC)[reply]
@Doc James: What, in your view, is the advantage of hosting academic papers on Wikisource vs just hosting the PDFs on Commons. It seems like most mobile devices and browsers these days support reading PDFs, and modern PDFs almost always have a text layer that is already searchable (and gets indexed by Google, etc.). Converting PDFs into Wikisource texts is a lot of work, and I'm curious what it achieves in your view. Kaldari (talk) 16:21, 12 November 2019 (UTC)[reply]
User:Kaldari Yes maybe the problems with PDFs are improving. Papers are more sources than media files though. So they more naturally fit within Wikisource. Doc James (talk · contribs · email) 16:28, 12 November 2019 (UTC)[reply]
Doc James, Kaldari: I'd prefer markup to PDF for several reasons:
  • First, text reusability; the text in these articles could be included in other wiki content. Cutting and pasting from a PDF can be really awkward, requiring a lot of manual editing to say, re-insert the spaces between the words which the OCR for some reason omitted. It also makes the images much more easily and quickly reusable, on Wikiversity, in the Wikijournals, in Wikipedia, etc.. The media in old, no-text-layer PDFs are also useful.
  • Separately, if you don't have a good cheap high-bandwidth internet connection, a PDF is bigger, to download or pack by sneakernet. Consider downloading all of Wikisource vs downloading all PDFs from Commons (which I don't think Internet-in-a-box has an interface for). If you are paying for satellite bandwidth, this matters.
  • Using a screenreader, it is reportedly rather difficult to read many academic paper PDFs (things like no spaces, or having the page footer and header read out to you in the middle of a sentence once a page, are annoying). By contrast, it is comparatively easy to read Mediawiki pages, which is very much to the credit of the devs. The reward for a job well done is more jobs...
  • This could attract new editors to the community
Most of the fancy formatting for an article on Wikisource is for the metadata. Just a simple tool that would create the metadata template from Crossref data or PMC would make importing articles a lot easier, especially if there is a machine-readable text layer (even a lousy one). This semi-automation seems to me as if it would not be a lot of work, but as I say, I am ignorant. HLHJ (talk) 01:11, 21 November 2019 (UTC)[reply]

Thank you for posting this proposal, HLHJ! However, there is a problem: it describes in much detail who will benefit, but does not explain the problem: what's the current procedure, what are the pain points, etc. Could you elaborate on this, please? MaxSem (WMF) (talk) 01:35, 14 November 2019 (UTC)[reply]

Unfortunately, we can't accept proposals that don't explain the problem in sufficient detail. Thank you for participating in our survey. MaxSem (WMF) (talk) 00:29, 19 November 2019 (UTC)[reply]
Sorry, MaxSem (WMF), I am a tad late checking back, off-wiki life. This answer is probably too late, but... Currently you manually upload a PDF to commons, and manually type it up, or if there is a machine-readable copy you cut-and-paste and manually reformat it, as far as I know (I asked on the main Wikisource forum a while back and got nothing better). It's doable, it just takes forever, and it's frustrating to manually copy structured machine-readable metadata when a program could do it much more rapidly and reliably. No objection to manual proofreading, but cutting the scutwork would be good. Additionally, it can be difficult to extract the images from articles (especially scanned pdfs). This problem applies even more to Wikibooks. I describe it in great detail in the section below. HLHJ (talk) 02:01, 20 November 2019 (UTC)[reply]

Improve workflow for book illustration cleanup

Some books and other publications are frankly pretty useless without their illustrations. Some newer PDFs have machine-recognizable images which could be automatically extracted,, but a very large number of illustrations need to be cropped from their scanned pages, and have their yellowed backgrounds adjusted to white, so that they can be included in the Wikisource text. The colour adjustment is such a common task that a reliable standard command to do it for greyscale images is posted the wiki. Only the cropping then requires human input.

Current workflow:
  1. Download the scanned page image file
  2. Use an external tool like * to crop (or identify the top-left-corner-co-ords and dimensions desired, and use jpegtrans manually).
  3. Run a command on the file to adjust the colour. Many editors are not familliar with command-line tools, so this may actually be a significant obstacle.
  4. Upload new file
  5. Copy over most of the metadata, adding a note to say what file it is cropped from
  6. Put the cropped image into the Wikisource text
  7. Repeat for every illustration in the book
Desired workflow: If the images cannot be extracted automatically, semi-automate:
  1. Click on the note in the Wikisource file that there was an illustration at this point to open the scanned page image in the illustration-extraction tool. Either:
    1. Adjust automated guess as to which rectangles contain illustrations
    2. Manually draw a polygon around the illustrations (rectangle default)
  2. Look at the automated colour adjustment.
    1. If the automatic colour adjustment is bad (unlikely), click to skip the colour adjustment and template the cropped Commons file as needing white balance adjustment. ##Otherwise, click "Done"
  3. The image is automatically cropped, adjusted, uploaded with suitable metadata to commons, and inserted into the Wikisource text.
  4. Repeat for every illustrated scanned page in the book.

As a bonus, this tool could be used to easily produce cropped images for use on other projects, a perennial Commons and Wikipedia wish. HLHJ (talk) 02:01, 20 November 2019 (UTC) [reply]

Switch between Reading mode and Contributing mode

NoN Technically infeasible

  • Problem: Some great scripts are not activated for IP because they are heavy or because readers doesn't need them to access the content. New contributors could benefit of those but may take ages before to find how to pimp their interface and add indispensable tools. And then, contributors have a display made for contribution and they may like to switch back to a lighter interface for reading, or have two settings.
  • Who would benefit: Readers and contributors
  • Proposed solution: Having a Reading mode and a Contribution mode with dedicated and modifiable parameters, including beta features, specific gadgets and css. A switch should be display somewhere on the interface to move from one setting to the other easilly. Then, a default could be made like the option to have all beta feature activated when they arrived. This default could be modified for projects preferences and for users preferences.
  • More comments: OSM have two interfaces, one for consultation and the other for contribution. I am not suggesting to go to this extremity but to have two sets of settings in the same interface.
  • Phabricator tickets:
  • Proposer: Noé (talk) 16:31, 10 November 2019 (UTC)[reply]

Discussion

I am sorry to say this is not currently technically feasible. For performance reasons, the caching layer does not allow us to load all JavaScript to logged-out users. One option available is to set the desired gadgets to default for all, and this will make them available to IPs and users who have otherwise not enabled the gadgets. Hope this helps! MusikAnimal (WMF) (talk) 00:42, 19 November 2019 (UTC)[reply]

Well, I also have considered this proposal to be more global than project-oriented, so I am not so sad. Your solution is not good, as default gadgets will be activated for all without consideration for their needs. People who only want to read the content should be able to have the fastest version of the website, without any gadgets that help contribution, and people who want to contribute should be able to get proper tools. It is not only for people without an account. I'll be glad to have a dedicated interface for contribution for a project I am not familiar with, when I just want to do a small task, such as copy-edit a Wikisource page to add an extra space or add a category to a dozen of pages in a Wikipedia in a language I am not fluent in. Global parameters may helps but they are not made for specificities and each project is peculiar. I may consider to submit it again next year, if a longer time let people think about a solution we may haven't consider yet. Noé (talk) 07:09, 19 November 2019 (UTC)[reply]

Improve the PDF/book reader

NoN This proposal is primarily for Commons

  • Problem: When we view a scanned book in PDF or DjVu format in Commons or Wikisource, its always single-page view. Every-time we go to the next page, we need to click on the drop down menu of pages. See this book in Commons for example. For book readers, its more like viewing images than reading books. This not only creates difficulty in reading, but also in identifying missing, duplicated pages etc. if the file needs to be corrected.
  • Who would benefit: Commons & Wikisource editors and readers
  • Proposed solution: Implement the open-source Internet Archive BookReader in all wikis specially Commons and Wikisource. For the same book in Internet Archive, see the difference. It has features like single view, double-page view, thumbnail view, zoom and a wide variety of other features.
  • More comments: Proposed in Community Wishlist Survey 2016 and 2019
  • Phabricator tickets: phab:T154100
  • Proposer: as before in 2016 and 2019. Bodhisattwa (talk) 12:36, 9 November 2019 (UTC)[reply]

Discussion

Correct pdf converter

NoN Insufficient information given

  • Problem: We need correct pdf converter
  • Who would benefit: Wikivoyage's guides users
  • Proposed solution: with title, without junk, correct convert maps
  • More comments:
  • Phabricator tickets:
  • Proposer: Digr (talk) 17:32, 10 November 2019 (UTC)[reply]

Discussion

Hello, i think too that wikivoyage need a good pdf converter because the current converter doesn't work. And when you prepare your trip, it's a good thing to aggregate all the page that you need in a pdf version. Maybe the latest version is not installed on the French speaking wikivoyage ? --mik@ni 09:08, 18 November 2019 (UTC)[reply]

Better statistics

NoN Proposes a legal change / too privacy invasive

  • Problem: Wikinews authors cannot check whether the news articles are reposted in other sites, or copied somewhere, or referenced from other sites. This prevents Wikinews from following the users' interests, prevents from coöperation with broad readers.
  • Who would benefit: Wikinews authors and, a little later, all Wikinews readers.
  • Proposed solution: allow Wikinews authors to see referrals to the articles, to know from what source the readers appear, possibly with some extension.
  • More comments:
  • Phabricator tickets:
  • Proposer: PereslavlFoto (talk) 22:49, 24 October 2019 (UTC)[reply]

Discussion

  • I'm not sure how we can do the tracking.. Are there open standards that are not privacy invasive (say unlike Google tracking) that can provide this ? Or do you want to see raw incoming referrals ? Honestly with the current level of privacy enforcement by browsers, i'm not sure if referrals still give us this level of insight any longer. Whatever it is, I'm guessing you want more than this? —TheDJ (talk • contribs) 12:30, 4 November 2019 (UTC)[reply]
    • The goal is, to see what sites refer to Wikinews, and what are the sources of interest to Wikinews articles. The link you provide shows us the volume of interest, yet we would like to see the sources of interest. --PereslavlFoto (talk) 11:38, 8 November 2019 (UTC)[reply]
  • Hello! We have discussed this as a team and decided this indeed is too privacy invasive, so I'm going to archive this proposal. Referrer data currently exists, but only for all projects combined, and only as aggregation (external non-search, external search, internal, and direct). I don't think legal would agree to providing raw referrer data on a per-article basis, but we have asked. Thanks for your participation in the survey! MusikAnimal (WMF) (talk) 17:04, 19 November 2019 (UTC)[reply]

Kartographer improvements

NoN We won't be working on the existing maps stack this year

  • Problem: The development of the Kartographer tool should be continued. Beside the phabricator tasks noted below the there are some additional wishes. (1) The computing time for <maplink> calls should be reduced especially for the use with Lua. (2) Showing user's position at the map; adding a button to move the map to the user's position. (3) Adding a zoom-level control to maps. (4) The Wikivoyage mode should be available at all wikis. (5) Make mapframe available for all flagged-revs Wikipedias.
  • Who would benefit: All wikis including Wikipedia, Commons, Wikidata, Wikivoyage, etc.
  • Proposed solution: Additions to the Karthographer extension.
  • More comments: It is very difficult to estimate the developing time. But the Kartographer should be permanently improved.
  • Phabricator tickets: T141715, T141335, T140083, T180909, T192334, T190069, T190067, T190064, T190062, T183770, T183766, T191585, T208713
  • Proposer: RolandUnger (talk) 18:46, 10 November 2019 (UTC)[reply]

Discussion

  • RolandUnger, thank you for submitting this proposal! We have reviewed this as a team, and we will unfortunately be unable to take on this wish. Here's why: Our infrastructure team is currently discussing options to switch out the maps frontend and backend to a different technology stack, which would be more robust and easier to maintain. If we can make that work, then it could take care of many of the concerns expressed in this proposal. It will be at least several months until we'll know for sure what the decision will be, so for this year's wishlist, we're not going to take on any possible commitments to working on the existing maps stack. Thank you again! --IFried (WMF) (talk) 17:47, 19 November 2019 (UTC)[reply]

Better fallback handling in Kartotherian's language selection

NoN We won't be working on the existing maps stack this year

  • Problem: Locations should be shown in the user's language. This is working but only if a location name is given in the OpenStreetMap (OSM) database just in the user's language.
  • Who would benefit: All Wikis which are using Kartographer and Kartotherian.
  • Proposed solution: In multiple steps, we should look for suitable labels in OSM database.
  1. Search for a label in the user's language.
  2. Search for labels in the same writing system like the user's language. For instance, French language uses the same system like English or German, Bulgarian the same like Russian or Ukrainian, Farsi the same like Arabic.
  3. In case of multiple results we select the language of the biggest weight.
  4. Additional fallbacks could be English or French labels because many readers can read and speak these languages.
  5. Last fallback is the official language -- like now.

Discussion

  • RolandUnger, thank you for submitting this proposal! We have reviewed this as a team, and we will unfortunately be unable to take on this wish. Here's why: Our infrastructure team is currently discussing options to switch out the maps frontend and backend to a different technology stack, which would be more robust and easier to maintain. If we can make that work, then it could take care of many of the concerns expressed in this proposal. It will be at least several months until we'll know for sure what the decision will be, so for this year's wishlist, we're not going to take on any possible commitments to working on the existing maps stack. Thank you again! --IFried (WMF) (talk) 18:05, 19 November 2019 (UTC)[reply]

Proofread extension enhancement

NoN Outside the scope of Community Tech

  • Problem: Proofread extension is great tool for proofreading, but the transcluded output have some problems:
    • The source text is stored in another space (Page namespace) than in page in main namespace, where might be metadata for this text
    • When somebody wants to edit this text, he find nothing relevant in source and link to one or many transcluded pages. There are some tools (default in some wikisources) which helps to find the correct page. These tools displays number of page in the middle of text (in some wikis in the edge) and in source html there are invisible parts, but sometimes in the middle of the word/sentence/paragraph. Spiltted to new proposal
    • There are needed various hack in the source (page) to get correctly formated output
      • <nowiki/> is needed for marking end of paragraph in the end of page, in other case translusion connect both paragraphs together
      • Is impossible to transclude poem which is on more pages as one block, there must be marks for beginning and ending of poem in every page break, so this seems as more poems .
    • Is problem to have simple links ([[/foo/]]) to other subpages from not/transcluded pages
    • Documentation. Probably somewhere exist in english, but in other languages tehre are only base informations and some users uses many enhanced functions which are not in documetation
    Because of these problems some users (including me) prefers text directly in main namespace.
  • Who would benefit: Wikisource editors, readers, users of TTS
  • Proposed solution: Solve these bugs, make tools for better orientation in transcluded pages.
  • More comments:
  • Phabricator tickets:
  • Proposer: JAn Dudík (talk) 13:24, 25 October 2019 (UTC)[reply]

Discussion

  • JAn Dudík, thank you so much for this wish! We have discussed this as a team, and it's too large in its current form. Can you perhaps break this wish into multiple smaller wishes? For example, the second bullet point is a great example of an individual wish. This would make the proposal much more manageable for the team. Thank you! --IFried (WMF) (talk) 01:00, 11 November 2019 (UTC)[reply]
OK, I made own proposal JAn Dudík (talk) 16:33, 11 November 2019 (UTC)[reply]
Thank you, JAn Dudík! --IFried (WMF) (talk) 02:08, 12 November 2019 (UTC)[reply]
  • JAn Dudík, thank you for submitting this proposal! Since you created a smaller proposal, which is more manageable for the team, we'll archive this original proposal. In addition, the remaining elements of this proposal are too large for us to take on, or they are social problems rather than technical ones. Again, thank you! --IFried (WMF) (talk) 19:06, 19 November 2019 (UTC)[reply]

Import top features from UDEMY, MOODLE, docebo

NoN Outside the scope of Community Tech

  • Problem:

Better Collaboration: In the current "Learn by doing" courses, authors could increase interactivity by useing 'REAL TIME collaborative edit' feature for the sake of reader/learner.

  • Who would benefit: The Wikiversity users , course authors .all the learning community that Wikimedia Foundation project can support.it will certainly give a boost to fulfill Wikiversity & the wikimedias goal.
  • Proposed solution: First of all, "community tech team" would know the best way to implement it. They are the expert's.
  • More comments: Some of concerns about 'Wikiversity improvement' could be found here .please check it out https://meta.m.wikimedia.org/wiki/User:Ahm_masum/test4

It would be nice if author's/reader could collaborate with each other in realtime ,for learning/ better understanding purposes. just like eatherpad, which is also in open licence.So it Could be implemented in wikiversity as a feature for group learning.

In the current implementation the 'database' service isn't appropriate .It should be fixed when implementing for Wikiversity.

Wikimedia has many tools hosted in 'Cloud VPS' ,why can't it also?

They already have some experience with 'eatherpad' . So a Wikiversity implement wouldn't be heard to achieve.

Discussion

  • i like the idea in the sense that educational features should be implemented. the best example i know is edx. see e.g. python for data science. maybe you want to reformulate a little, focus more? --ThurnerRupert (talk) 05:50, 24 October 2019 (UTC)[reply]
  • I like the idea, too, and think it could be very useful in general to adopt advanced learning tools on Wikiversity taking inspiration from other learning platforms. --Daniele Pugliesi (talk) 20:56, 30 October 2019 (UTC)[reply]
  • MASUM THE GREAT, thank you for submitting this proposal! This wish could be very exciting; it's just too large (for the Community Tech) in its current form. So, we have an idea for you: Perhaps you could identify one feature in this wish that you would like to be implemented. Alternatively, you (or other members of the community) could submit multiple features as as separate wishes. Thank you—and we look forward to see if there are updates to this wish! --IFried (WMF) (talk) 21:43, 30 October 2019 (UTC)[reply]
Thanks IFried (WMF). Feel free to split this proposal by any means. If community tech team have to (heavily) narrow it down to 1 simplest proposal then they should choice "progress report" features, just saying.--MASUM THE GREAT (talk) 13:45, 1 November 2019 (UTC)[reply]
Currently I'm working to make it 3 different proposal. Please be Patience.--MASUM THE GREAT (talk) 13:29, 5 November 2019 (UTC)[reply]
Hello @IFried (WMF): ,@MusikAnimal (WMF):

.I've already split this into 2 different proposal. Please see 'PROGRESS REPORT Feature' & 'Modern Interface for Video Course's' .

If you want to remove this proposal then please replace it with 'this (my 3rd proposal)'

Any kind of advice is welcome. Many Many Thanks .--MASUM THE GREAT (talk) 15:05, 10 November 2019 (UTC)[reply]

  • Good idea. Wiki Movimento Brasil User:joalpe is working on a Moodle format for Wikiversity.

--Lgjunior

  • Merge with ThurnerRupert's "electronic course features analysis" proposal? The anyone-can-edit/quality-control issue seems separate from the technical capabilities, and as it is more political than technical, the Community Wishlist may not be a good place to discuss it. HLHJ (talk) 22:30, 3 November 2019 (UTC)[reply]
  • MASUM THE GREAT, thank you for creating the smaller proposals (which break up this wish into more manageable chunks). For this reason, I'll now archive this original proposal, which is unfortunately out of scope for the team. Again, thank you! --IFried (WMF) (talk) 19:13, 19 November 2019 (UTC)[reply]

Support CSS Shapes module

NoN Does not meet MediaWiki browser compatibility standards

  • Problem: Some books are decorated with illustrations that are non-rectangular and lay out text along the irregular shape. This can some times be approximated by just using normal Mediawiki image syntax, but in some cases the only reasonable layout is as the original. For example, this page (illustrations by Howard Pyle). The proper way to achieve that is using CSS Shapes Level 1] shape-outside: url(…) pointing at an image whose alpha-channel gives the exclusion mask for the element it matches. However, there's no way to apply advanced (non-predefined) CSS rules to an image in Mediawiki, and the CSS sanitizer would (I believe) nuke the url() from inline styles in any case.
  • Who would benefit: All projects. The Wikisourcen run into this situation every so often, but all projects will have use for it every now and again.
  • Proposed solution: Extended syntax for applying arbitrary CSS to images? Let the CSS sanitizer accept url() for internal images? Bonus for some syntax where I can just use "File:Image.jpg" instead of "//upload.wikimedia.org/…". Parametrized values for TemplateStyles maybe? If we could have a template {{masked image |float=left |display=Image.jpg |mask=Image.png |threshold=0.5}} that could feed the latter two to its TemplateStyles stylesheet, that solves this problem. Cases where we need shape-inside would still be unresolved, as well as a myriad other cases for fancy CSS, that fully parametrized TemplateStyles would solve.
  • More comments:
  • Phabricator tickets: T200632, T203416
  • Proposer: Xover (talk) 21:08, 10 November 2019 (UTC)[reply]

Discussion

  • Hello! We have discussed this as a team and decided that CSS shapes are not supported well-enough to be used in MediaWiki, so I'm going to archive this proposal. It would seem we're just waiting on support for IE 11 to be dropped, then this will be OK. I cannot say when this will happen, unfortunately. It also seems url() is explicitly not supported because it's possible to load malicious assets (tracking pixels, for instance). Perhaps our Content Security Policy, when fully rolled out, will alleviate that concern (phab:T28508). Thanks for participating in the survey! MusikAnimal (WMF) (talk) 19:40, 19 November 2019 (UTC)[reply]

Connect the internet, culture and the world

NoN Insufficient information given

español: Conecta internet, la cultura y el mundo
  • Problem: Today, there is a deep debate around the world in which we live is increasingly connected, and as in any debate, opinions are as diverse as creative and by nature, contrary to each other; But, the circumstances, concepts or ideas are tools, and the use given to them is not the fault of the ideas or tools, but of those who misuse those tools
    español': Hoy día, hay un profundo debate entorno a que en el mundo en el que vivimos está cada vez más conectado, y como en todo debate, las opiniones son tan diversas como creativas y por naturaleza, contrarias unas con las otras; pero, las circunstancias, conceptos o las ideas son herramientas, y el uso que se les dé no es culpa de las ideas o herramientas, sino de quienes hacen mal uso de esas herramientas
  • Who would benefit: In sum, the benefits are profitable by children, their parents, or professionals who seek information regarding their topics of interest.
    español: En suma, los beneficios son aprovechables por niños, sus padres, o profesionales que busquen información con respecto a sus temas de interés.
  • Proposed solution:
  • More comments:
  • Phabricator tickets:
  • Proposer: Jualom (talk) 00:19, 4 November 2019 (UTC)[reply]

Discussion

Ability to start a new article in the mobile interface

NoN This proposal is global

ru: Возможность начать новую статьи в мобильном интерфейсе

  • Problem: It is now impossible to start a new article in the mobile interface. You have to go to the desktop interface, create an article, and then go back. Or create a special page for users working with a mobile interface.
    ru: Сейчас невозможно начать новую статью в мобильном интерфейсе. Приходится переходить в десктопный интерфейс, создавать статью, а потом переходить обратно. Либо создавать специальную страницу для пользователей, работающих с мобильным интерфейсом.
  • Who would benefit: All users who prefer to use gadgets and users who do not have the ability to edit on a desktop computer.
    ru: Все пользователи, предпочитающие пользоваться гаджетами и пользователи, у которых нет возможности редактировать на настольном компьютере.
  • Proposed solution: Add the ability to start a new article to the mobile interface.
    ru: Добавьте в мобильный интерфейс возможность начинать новую статью.
  • More comments:
  • Phabricator tickets:
  • Proposer: HalanTul (talk) 07:56, 11 November 2019 (UTC)[reply]

Discussion

Wiktionary in e-readers and e-book apps

NoN Outside the scope of Community Tech

  • Problem: There is no reuse of Wiktionaries' content in e-readers such as Kindle, Nook, Kobo or in epub readers such as Moon+ Reader, EPUB Readers, Pocketbook reader, etc. They use internal dictionaries instead of a better collaborative dictionary.
  • Who would benefit: Mobile users.
  • Proposed solution: Having an app to use Wiktionary as a dictionary in reading apps. (i'm not sure how this all works, but i hope you get the idea)
  • More comments: It is not a core feature but a good way to spread knowledge as a service.
  • Phabricator tickets:
  • Proposer: DaraDaraDara (talk) 14:22, 8 November 2019 (UTC)[reply]

Discussion

  • This proposal may be connected with Lexicographic knowledge as a service, a proposal to develop more format to export the content of Wiktionaries. For an internal dictionary in e-readers, it could be only one conversion, but I imagine there is more work to do in order to convert the data properly. In this process, Dbnary, a RDF conversion of Wiktionary data, could be of some help. Noé (talk) 20:05, 10 November 2019 (UTC)[reply]
  • DaraDaraDara, thank you for submitting this proposal! It is unfortunately out of scope, so we’ll be unable to take it on. For this work to be possible, structured Wiktionary would need to first be developed. Hopefully, this is something that can be done in the future. Thanks again, and we apologize for any disappointment. --IFried (WMF) (talk) 00:21, 20 November 2019 (UTC)[reply]

Structured, plain text Wikisource exports

NoN Proposed did not respond

  • Problem:
One of the main goals of Wikisource is to produce transcription text that can be widely shared and reused in other contexts. Wikisource has a lot of promise for allied organizations, such as GLAM institutions, that also work on preserving and providing access to textual works. Currently, however, Wikisource is vastly underutilized by the GLAM sector, and one of the main reasons is the lack of interoperability.
It is actually quite difficult to make completed texts on Wikisource useful to the outside world because of the use of wiki formatting and templates in transcriptions, as well as non-transcription text on Wikisource pages, which are not easy to strip out in any programmatic way—and certainly not in any built-in way easily available to reusers, such as an API request.
For example, here is the first paragraph of the US Declaration of Independence:
WHEN in the course of human Events, it becomes necessary for one People to dissolve the Political Bands which have connected them with another, and to assume among the Powers of the Earth, the separate and equal Station to which the Laws of Nature and of Nature’s God entitle them, a decent Respect to the Opinions of Mankind requires that they should declare the causes which impel them to the Separation.
But here is how Wikisource transcribes it:
{{dropinitial|W}}HEN in the cour{{ls}}e of human Events, it becomes nece{{ls}}{{ls}}ary for one People to di{{ls}}{{ls}}olve the Political Bands which have connected them with another, and to a{{ls}}{{ls}}ume among the Powers of the Earth, the {{ls}}eparate and equal Station to which the Laws of Nature and of Nature’s God entitle them, a decent Re{{ls}}pect to the Opinions of Mankind requires that they {{ls}}hould declare the cau{{ls}}es which impel them to the Separation.
Here is how that looks in an API response (spoiler: terrifying).
  • Who would benefit:
  1. This would primarily benefit Wikisource's potential reusers, specifically stakeholders seeking to use Wikisource as a platform for crowdsourcing their content and then ingest transcription data back into their dataset.
  2. It would also benefit all Wikisource editing communities more directly by encouraging increased institutional partnerships and new users.
  3. It might help Wikisource in other ways, like improving the search index, and paving the way for future storage of transcriptions as structured data statements (directly on Wikidata or as local statements like Structured Data on Commons).
  • Proposed solution:
A successful outcome would involve a documented, core functionality that allows a user to easily access a transcription for a given work as plain text, and in a machine-readable context.
This could look like a method in the existing Wikisource API for requesting sanitized data, with a "translation" layer on the backend that can take the formatted Wikisource pages and deliver clean versions to the consumer. For example, a JSON array of pages if querying a mainspace or index namespace page, or, at the very least, the ability to get such data on a per-page basis by querying the page namespace. It would hopefully not be an external, standalone tool that might become unmaintained.
I think it could look something like Extension:TextExtracts, except that extension doesn't seem to work in Wikisource contexts and has a character limit.

Discussion

While I do like the idea, it is worth considering the Rest API in line with this proposal. Dominic´s example in Rest API. See also https://en.wikisource.org/api/rest_v1/ --Snaevar (talk) 17:42, 23 October 2019 (UTC)[reply]

@Snaevar: Yes, that's a good point; I wasn't really aware of it. It looks like what we want could be similar in approach to the Wiktionary definition method, except without any HTML elements in the response. In general, though, I really like how this works: https://en.wiktionary.org/api/rest_v1/page/definition/apple. Dominic (talk) 19:49, 23 October 2019 (UTC)[reply]

@Dominic: I'm not sure if it's quite what you're after, but the Wikisource Export tool can export to plain text (for example, United States Declaration of Independence (Dunlap Broadside)). It does this by creating an epub of the work and using Calibre to convert that to plain text. —Sam Wilson 23:29, 23 October 2019 (UTC)[reply]

@Samwilson: This is a useful example as well, but doesn't quite get at the use case I'm describing either. I think there are several export tools like this aimed at serving the reader of a text, but none that seem optimized for the use case of a downstream harvester attempting to consume Wikisource transcription data at scale. For example, if I am an institution that contributed that digital image of the Declaration, and thousands of others, and then wanted to ingest the work produced by Wikisource back into source dataset, I would want to be able to easily query for the text of a specific digital image in the form of structured data (when I say plain text, I mean the transcription doesn't have HTML elements or wiki markup, not that it is unstructured or TXT format). Dominic (talk) 21:14, 24 October 2019 (UTC)[reply]
@Dominic: It sounds like you might be talking about being able to export in TEI format, or some other non-presentational markup? This would indeed be terrific! At the moment, the closest we come is HTML, because wikitext only fully outputs to HTML. There have been experiments with using things like Pandoc to turn wiki HTML into Docbook or other structured formats, but because we don't have semantic markup for lots of elements (e.g. a quotation paragraph in a book is just indented, or a chapter title is just larger text) there's no way to actually portray these things in a real structured way in any format. For instance, the example paragraph you give above uses the long s, and an institution bringing the transcription back into their collection would want to retain that knowledge about the work, but plain text doesn't give it (that's a slightly shallow example, maybe, because that can just be represented with an actual ſ character – but lots of things can't be).

Maybe you could update the proposal to clarify what you mean by "as plain text, and in a machine-readable context", because it feels like these things might be in opposition — if it's machine readable, it might be text but it's no really plain text, if you see what I mean? We already have plain text, but it's not very useful! :-) Sam Wilson 22:36, 24 October 2019 (UTC)[reply]

Reagarding the Rest API. You still have to learn how to do it. What about something easy for tech idiots like me on a few clicks. I dont have a time to learn it, does the GLAM employee will have a time to learn it? Why somebody would be learning something if they can have it elsewhere without learning new things? Juandev (talk) 09:17, 4 November 2019 (UTC)[reply]
  • Dominic, thank you for submitting this proposal! Unfortunately, we are unable to take on this work, as we did not receive a response from you in regard to our question. We apologize for any disappointment, and thank you again for taking part in the survey! --IFried (WMF) (talk) 00:26, 20 November 2019 (UTC)[reply]

Visual entry form

NoN Outside the scope of Community Tech

  • Problem: Wiktionary pages tend to be very template-heavy, meaning that the learning curve is very steep, and not only for new users —editors coming from other projects are easily overwhelmed by the sheer amount of templates (with their respective parameters) that need to be memorised in order to create a decent entry.
  • Who would benefit: Absolutely all Wikitionary editors, both current and potential.
  • Proposed solution: A way to easily use inputboxes and preloaded content with the visual editor, so that a page that is 100% made with templates is easily manageable using the Visual Editor. Each community should be able to define what will appear in the preloaded content, and there should be an option to highlight the different parts so that the user can know where to click to write them (since many templates are invisible when not filled). Ideally, the editor should be able to directly write on the page without the typical template pop-up.
  • More comments:
  • Phabricator tickets:
  • Proposer: Unapersona (talk) 10:53, 10 November 2019 (UTC)[reply]

Discussion

  • Good point. It could be related to another proposal "Adapt visual editor to wiktionaries but you include as well code colorization, and that's something interesting too. Noé (talk) 11:00, 10 November 2019 (UTC)[reply]
    @Noé: to clarify, with "highlighted" I didn't mean syntax highlighting. When you are editing a page full of empty templates using the Visual editor (not the new source one), the templates are often invisible unless you know where to click. There should be a pointer that tells the user "click here to add etymology", "click here to add translations", etc. --Unapersona (talk) 11:47, 17 November 2019 (UTC)[reply]
  • We have discussed this as a team and believe it would better be addressed with structured Wiktionary Wikiquote (phab:T71753, see also 2020 wish), which is out of scope for our small team. Without this underlying structured data, what we build will be quite fragile and difficult to make configurable for each wiki. We apologize for any disappointment, and thank you for your participation in the survey! MusikAnimal (WMF) (talk) 00:52, 20 November 2019 (UTC)[reply]
    @MusikAnimal (WMF): have you not mixed the topic? This is a Wiktionary proposal and you talk about Wikiquote. Pamputt (talk) 06:24, 20 November 2019 (UTC)[reply]
    @Pamputt: My apologies! I did have it mixed up. But the same problem persists... similar to the "Adapt visual editor to wiktionaries" proposal. We have been made aware of Dbnary which does offer structured data, but I don't think this will help us with VisualEditor, which is meant to be wiki-agnostic. Basically we'd need to hard code VE to work on each wiki, individually, which doesn't scale (and probably wouldn't pass code review, either). We can however make a gadget or something that is specific to your wiki, if you'd like? I'm sorry we're running out of time... voting starts in 45 minutes! We can unarchive after voting starts but we do need to narrow the scope of this, and take out the VisualEditor part. We definitely recognize the desire for better VE support, and will make sure the Editing team is aware of it. MusikAnimal (WMF) (talk) 17:19, 20 November 2019 (UTC)[reply]

Increase maximum file size

NoN Out of scope for our team

  • Problem: For now it is impossible to upload files bigger then 4GiB. That is a problem especial for high quality uncompressed book scans or high resolution or long video material. There are only two workarounds one is to compress the data what is lossy in many cases or to split up the file what makes it harder to link them.
  • Who would benefit: Everyone wants to use high quality book scans as one file, long video files or similar big files.
  • Proposed solution:
  • More comments:
  • Phabricator tickets: task T191802
  • Proposer: GPSLeo (talk) 18:46, 21 October 2019 (UTC)[reply]

Discussion

  • The first letter after the project name should always be capitalized. I will fix that now. GeoffreyT2000 (talk) 19:01, 21 October 2019 (UTC)[reply]
  • yes, files will continue to get bigger, and hard limits will increasingly stop work. Slowking4 (talk) 18:57, 22 October 2019 (UTC)[reply]
  • One thing to consider for people implementing - its not just the storing of large objects in Swift. Its also about being able to effectively serve large ranges of large files from varnish (in the video case), and in the PDF/Djvu case its also about scaling the whole 1 file but 20,000 associated thumbnails system. Its been a while since I've looked at file storage, so its possible my knowledge is outdated, but just wanted to mention what I believe are the issues involved. Bawolff (talk) 02:34, 23 October 2019 (UTC)[reply]
    @Bawolff: "Thumbnails" for multi-page formats (PDF/DjVu/TIFF) could really use some TLC! There are performance issues that makes the proofreading (transcribing) process slow and lots of issues that lead to outdated thumbnails. General improvements in performance and reliability here could have a really big cumulative effect.
    On the performance side I suspect that 1) Wikisource essentially needs full size page images where the infrastructure is rigged for reduced-size thumbnails that can be generated on the fly, and 2) the sizes of "thumbnail" requested from ProofreadPage never hits a size that exists pre-generated (is there some kind of cache-hit analysis that could reveal this?). Making sure there are pre-generated images for each page and that ProofreadPage requests a size that exists should reduce this to just serving an image (which is reasonably fast today, and will benefit from any future general infrastructure improvements).
    On the reliability side, I think general armoring is in order, and combine that with an algorithm that behaves well in the context of a multi-page media. Just guessing based on some of the cases I've seen, something pathological in the file trips up whatever component is generating the thumbnails and because its assumptions are that it's operating on "1 file : 1 image : multiple thumbnails" it falls down completely instead of recover gracefully when faced with "1 file : many images : multiple thumbnails". If the image data on page 3 of a PDF is borked, the right failure mode is to give up on that page and move on to pp. 4–1024, but from the outside it looks like what happens is that it gets stuck and gives up on the entire file.
    This isn't directly related to this Wishlist proposal (I'm just free-associating from your comment above) and I can't really see a way to put this that would fit in a proposal of its own ("Make images m0ar better!!!!"), so I'm mainly just putting it out there in the hopes it'll find a home somewhere. --Xover (talk) 10:31, 9 November 2019 (UTC)[reply]

Unfortunately, our team wouldn't be able to work on this. Increasing the limit would involve infrastructure upgrades including storage expansion, HTTP cache improvements, budgeting, etc. Our team does not have the skills required for this so we can't commit to working on this proposal. Regardless, thank you for participating in our survey! MaxSem (WMF) (talk) 01:04, 20 November 2019 (UTC) [reply]

Add maps of sightseeing spot to help visitors find nearby sightseeing spots and information through maps

NoN We won't be working on the existing maps stack this year

  • Problem: Although we have “What's nearby?”, we can't meet the map class to find nearby attractions and information.
  • Who would benefit: When someone using map of Wikivoyage on tour road. Any reader on mobile wanting to see what Points of Interest are nearby.
  • Proposed solution: We can follow the map of the sightseeing spots of the backpacker. After the click sightseeing spots, there will be local article information to help visitors find their destination. Also see WikiShootMe.
  • More comments: Add maps of sightseeing spot to help visitors find nearby sightseeing spots and information through maps. This is a functionality any mobile user would expect. Other apps do this. Stops Wikivoyage becoming popular with mobile users, which is the largest group of internet accesses.
  • Phabricator tickets: phab:T208713
  • Proposer: ✈IGOR／ 〒 Tell Me What?! ． Wikivoyager 15:18, 24 October 2019 (UTC)

Discussion

Little gimmick related to your proposal: https://tools.wmflabs.org/wikimap/?commons=false&project=wikivoyage&lang=zh&lat=24.82&lon=120.98 --DB111 (talk) 11:44, 25 October 2019 (UTC)[reply]
Yes, We will need like this Little gimmick, but Wikivoyage logo is wrong, by the way, if can display any listing point and information on map, I think the little gimmick is good idea.-- ✈IGOR／ 〒 Tell Me What?! ． Wikivoyager 15:30, 25 October 2019 (UTC)
Thank you, I have to admit that it is originally a Wikipedia tool, but you're right, I fixed this. --DB111 (talk) 21:13, 26 October 2019 (UTC)[reply]
@DB111: In fact, The wmflabs have a good function is Show me where I am, but I think any point not only point name, It can add to also name, URL, E-mail, Address, Directions, Phone, Tollfree, Fax, Hours, Price and Content etc. (e.g See section of Wikivoyage). In other words, all the parameters in the list item are displayed on the map. This is convenient for tourists to use the mobile phone's Wikivoyage map to find nearby attractions or stores on the road, and click on the Point to see the contect of List items, this function is very practical and convenient. This feature is equivalent to the map of the backpacker.-- ✈IGOR／ 〒 Tell Me What?! ． Wikivoyager 13:02, 27 October 2019 (UTC)
In addition, we can also refer to the interface design of Google Earth, we can meet the map class to find nearby attractions and information. Kitabc12345 (talk) 13:41, 25 October 2019 (UTC)[reply]
I think the most important enhancement that is needed is to have current position marked on dynamic maps in article pages (mapping listings not cities on map with users position also marked). Particularly important as most web users are now mobile users, and knowing what is near you is a crucial feature for any travel/location guide. --Traveler100 (talk) 13:58, 27 October 2019 (UTC)[reply]
However, the Point on the current map is only the picture and the name, but there is no related Point content. I think this is too rough and inconvenient. I think let the tourists only know the name and appearance of the Point, but they don't know what it is. If this is the case, at least when the visitor clicks on a nearby Point, at least the link to the list item information is required(Click Name link, It will to someitem list on local article), so that the relevant content of the Point can be known. -- ✈IGOR／ 〒 Tell Me What?! ． Wikivoyager 14:21, 27 October 2019 (UTC)

✈IGOR, thank you for submitting this proposal! Unfortunately, we are unable to take on the wish. Here's why: Our infrastructure team is currently discussing options to switch out the maps frontend and backend to a different technology stack, which would be more robust and easier to maintain. If we can make that work, then it could take care of many of the concerns expressed in this proposal. It will be at least several months until we'll know for sure what the decision will be, so for this year's wishlist, we're not going to take on any possible commitments to working on the existing maps stack. We apologize for any disappointment, and again, thank you! --IFried (WMF) (talk) 01:36, 20 November 2019 (UTC) [reply]

Show user's current location on maps

NoN We won't be working on the existing maps stack this year

  • Problem: On Wikivoyage, when using mapframe embedded maps, it is difficult for the user to find their current real-life location on the map.
  • Who would benefit: Users using Wikivoyage while traveling, especially mobile users.
  • Proposed solution: Provide an option, maybe an icon to click, to indicate the user's current location.
  • More comments: This is an obvious feature which users expect, and not having it makes the maps significantly less useful.
  • Phabricator tickets: T208713
  • Proposer: Mx. Granger (talk) 23:35, 1 November 2019 (UTC)[reply]

Discussion

  • Weak support. I'm not a big fan of geo-tracking and I don't really use mobile devices but this is definitely a hi-value feature for travelers to opt into. Even as someone who wouldn't use a Wikivoyage smartphone app while traveling, I can tell this is something that would be very handy. —Justin (koavf)❤T☮C☺M☯ 19:40, 2 November 2019 (UTC)[reply]
  • This looks useful. I regularly use a local public transport apps which have similar features, and I can easily see nearby bus or tram stops; it would be very useful to find nearby museums or cafes when exploring a strange city. It would also encourage readers to keep the Wikivoyage page open when they walk to a location, rather than switching to a map app. Users can configure geo-tracking on their phone to allow or not allow a particular browser to get locations information, and the wiki could have a preference to opt out for readers who have logged in. AlasdairW (talk) 00:05, 5 November 2019 (UTC)[reply]
  • This has been desired by User:Traveler100 for a while. I support. SelfieCity (talk) 12:55, 9 November 2019 (UTC)[reply]
  • A must for a site about locations. Most users of the web are today from mobile devices, this is an expected function. Also not having this forces the use of other mapping applications. --Traveler100 (talk) 05:57, 10 November 2019 (UTC)[reply]
  • Mx. Granger, thank you for submitting this proposal! Our infrastructure team is currently discussing options to switch out the maps frontend and backend to a different technology stack, which would be more robust and easier to maintain. If we can make that work, then it could take care of many of the concerns expressed in this proposal. It will be at least several months until we'll know for sure what the decision will be, so for this year's wishlist, we're not going to take on any possible commitments to working on the existing maps stack. We apologize for any disappoint, and thank you again for submitting this proposal. --IFried (WMF) (talk) 01:46, 20 November 2019 (UTC)[reply]

Importing non-GeoJSON map data to Wikimedia Commons

NoN This proposal is primarily for Wikipedia, Wikidata, or Commons

  • Problem: All map data at Wikimedia Commons is stored in GeoJSON format. This format is not supported by many GPS devices. The import and export of common map formats like GPX and KML/KMZ to Commons and Wikidata should be added.
  • Who would benefit: Wikimedia Commons and all wikis that use Kartographer.
  • Proposed solution: Maybe as WMF Labs tools.
  • More comments:
  • Phabricator tickets: T55023, T154908, T137677, T216601, T28059
  • Proposer: RolandUnger (talk) 18:59, 10 November 2019 (UTC)[reply]

Discussion

  • RolandUnger, thank you for submitting this proposal! Unfortunately, it focuses on improvements to Wikimedia Commons, and we aren't accepting Commons wishes in this year's survey. We apologize for any disappointment, and thank you again for participating in the survey! --IFried (WMF) (talk) 01:57, 20 November 2019 (UTC)[reply]

UX VisualEditor on Wikisource

NoN Outside the scope of Community Tech

  • Problem: visual editor came to wikisource but has not shown much promise. the menus require much searching, and scrolling down, memorizing keys, or customizing CSS.
    veterans go back to wikitext, and newbies do not know how to navigate
  • Who would benefit: new editors to wikisource
  • Proposed solution: do a thorough UX design on default menu layout
  • More comments: "visual editor is broken on wikisource" was a broad consensus expressed at wikimania [3] and previous wishlist [4]
  • Phabricator tickets:
  • Proposer: Slowking4 (talk) 19:07, 22 October 2019 (UTC)[reply]

Discussion

  • There is also problem with VE inside <poem></poem> - VE thinks that text is parameter of {{poem}}. The same situation is with some formatting templates (one in the beginning with <div class=foo> and second with </div> on the end of text. T45120 JAn Dudík (talk) 21:03, 22 October 2019 (UTC)[reply]
    IMHO Visual editor is almost useless into wikisource; a specific wikisource editing interface should be built by scratch, under strict supervision by a group of very active wikisource editors. --Alex brollo (talk) 07:34, 9 November 2019 (UTC)[reply]
  • Unfortunately, after much discussion, we believe our small team is not capable of taking on a VE refresh for Wikisource. I think one major improvement would be to have a way to add buttons for certain templates and tags, such that you as a community could customize it. For instance editing existing poems seems to work fine (in my testing), but there's apparently no way to add a poem. Though, you could make Template:Poem as a wrapper, and you'd at least be able to make use of it in VE.

    Overall, there seems to be a lot of issues with VE on Wikisource. To fix these we will need the expertise of the Editing team, so we will make sure they are aware of this and that the demand for a more functional VE is high. Thanks for taking the time to create this proposal, and apologies we can't take it on. MusikAnimal (WMF) (talk) 02:38, 20 November 2019 (UTC)[reply]

Display recordings with an order based on geolocalization

NoN Can't be implemented at this moment

  • Problem: Thanks to the recording tool Lingua Libre, Wiktionaries can now display dozen of audio files with pronunciations for each words. It is a great way to hear the diversity of usages and the reality of languages. Unfortunately, with the time going, it is problematic. The pronunciation section is inflating, chaotic and not adapted to the readers. Recording order is not useful, and correcting the order by hand is not possible because of the quantity of files added. Plus, one order do not fit for the diversity of the audience.
  • Who would benefit: Readers of Wiktionaries all over the world
  • Proposed solution: Gathering all audio files in one template and a solid script may allow a display adapted to the geolocalization of users, based on their IP. Doing so, someone from Canada should have a North-American audio first and then European and African ; someone from Mali should have Malian audio, then other African, then Europe and so on. Audio files recorded with Lingua Libre have metadata including a country or a city, so it could be possible to related those data to a geographical database such as geonames, or with Wikidata itself in order to push the recording on a map. Then, the display could order the files following the distance with the user. This require an authorization to use the IP but it could be only the first digits, so we avoid to consider those as a personal data. It could work without any cookies and be session dependent. A v. 2 could allow to specify a different localization as a preference.
  • More comments: Some examples of pages with too many audio files: cinq, arbre, fraise.
  • Phabricator tickets:
  • Proposer: Noé (talk) 08:15, 22 October 2019 (UTC)[reply]

Discussion

  • Working with the display of recording may lead to add a way to record directly into Wiktionaries via Lingua Libre account (to add metadata about the speaker). There is another proposal that suggest to do so, suggesting a different solution, but both could be connected, maybe Noé (talk) 10:05, 13 November 2019 (UTC)[reply]

Unfortunately, this type of feature would be hard to do in a wikitext based dictionary, however Wikidata support for Wiktionary is being worked on as we speak, so hopefully in the future this will be more easily doable. But for now, we can't accept this proposal. Regardless, thank you for participating in our survey! MaxSem (WMF) (talk) 06:35, 20 November 2019 (UTC)[reply]

Hi, MaxSem, you wrote that "Wikidata support for Wiktionary is being worked on", and reference is needed. To my knowledge, Wikidata have is own agenda and it doesn't include a support to Wiktionary. Wikidata chose to built a separate registry of words in Lexeme namespace. Maybe Wikibase could be of some help, but it's a separate initiative, and there is nothing related to this need in the community wishlist. Noé (talk) 06:56, 20 November 2019 (UTC)[reply]
(edit: I realize I'm partially off-topic, since the request is not about building maps - I hope that some of what I wrote is still interesting) I think that the solution can be found in the new developments made on Structured Data for Commons. If the recording files on Commons include the right metadata, and since it will soon be possible to query the structured data from Commons in SPARQL (a beta service is already available), just like it is already the case for Wikidata's data (example), it will be possible to create dynamic maps. Starting from there, including the map on a wikipage will be a matter of building the right template (Basque Wikipedia is already integrating dynamic SPARQL maps, unfortunately I can't show you an example because the Graph extension is broken at the moment, but here you can see the template)
So I think you could find a solution that doesn't involve a big development task but will need a bit of creative hacking and discover the joys of SPARQL and Lua :) Lea Lacroix (WMDE) (talk) 17:19, 26 November 2019 (UTC)[reply]
Merci Léa ! Structured data for Commons + SPARQL + Lua = ♡ -- Noé (talk) 17:30, 26 November 2019 (UTC)[reply]
Very interesting idea. I created T239272 to track this feature. Pamputt (talk) 19:39, 26 November 2019 (UTC)[reply]

Improve association between definition and illustration

NoN Can't be implemented at this moment

  • Problem: When an illustration is added on an article, it is necessary to indicate in the illustration description the definition index associated. This index can be changed if the order of definitions is changed and desynchronization appears. Moreover, it is not systematically possible to adjust the position of the illustration in front of the associated definition. So, it would be interesting to improve the association between the definition and its illustration(s).
  • Who would benefit: Readers
  • Proposed solution: I provide some ideas (I don't want to implement all of them):
    • link a definition to its illustration by generated ID to display automatically in illustration description the suitable definition index (avoiding desynchronization in case of reordering)
    • highlight the illustration on definition mouse over event
    • reduce the size of all images and zoom in on the illustration when user select a definition or put the mouse pointer over it
    • create a unique illustration displayer in the article (anchored to the definition section, fixed on scroll in the section to keep it visible all the time) and show in it the suitable illustration when mouse is over a definition
    • on smartphone or tablet, insert the associated illustration between the definition and the next one (maybe in gallery if several illustrations are available)
  • More comments: I hope I am understandable. I take other propositions. You can see an example of page with a gap between the images and the definitions: clé.
  • Phabricator tickets:
  • Proposer: Jpgibert (talk) 15:51, 23 October 2019 (UTC)[reply]

Discussion

  • I agree a cross-reference system dedicated for picture could be very useful, in Wiktionary it's obvious because it's a list of definition and a list of picture, but in other projects too. In mobile display, pictures are often put before a paragraph and not in the planed position next to the text, so a good reference system could be very useful to keep both connected. Something similar as figure reference in LaTeX of LibreOffice, if it rings something for you. Noé (talk) 15:26, 24 October 2019 (UTC)[reply]
  • On Wiktionary, there are a couple of decent procedures for references. Something similar is needed for illustrations but also for translations, synonyms, holonyms, meronyms, etc. Urhixidur (talk) 14:27, 25 October 2019 (UTC)[reply]

Unfortunately, connecting information to an illustration would be hard to do in wikitext, however Wikidata based Wiktionary is being worked on as we speak, so hopefully in the future this will be easily doable. But for now, we can't accept this proposal. Regardless, thank you for participating in our survey! MaxSem (WMF) (talk) 06:36, 20 November 2019 (UTC)[reply]

Hi MaxSem, How do you imagine having a cross-reference system to have the same number for an element in a text and a number wrote in the comment of a picture with Wikidata? This is not how Wikidata work. Plus, the list of definitions are not related in each versions of Wiktionary and in Wikidata, i.e. "cat" in English Wiktionary may have five meanings, "cat" in French Wiktionary may have three including one not describe in English Wiktionary and Wikidata could have four. Then, what can we do? Should each definitions in each wiktionary have an id? That make no sense for me. A proper MediaWiki solution sounds way more efficient. Plus, Wikipedia or Wikivoyage could use such a cross-reference system for pictures, and it will not be with Wikidata neither. Should we get a way to explore this issue without suggesting Wikidata as a solution? Noé (talk) 07:06, 20 November 2019 (UTC)[reply]

Adapt visual editor to wiktionaries

NoN Outside the scope of Community Tech

  • Problem: The visual editor is the same as Wikipedia, but wiktionary pages are structured in a totally different way
  • Who would benefit: Anyone who wants to create or edit wiktionary pages
  • Proposed solution: Install a visual editor which understands the structure of wiktionary pages and proposes tools that handle the wiktionary templates. This will help editors a lot, especially the beginners. The most obvious features are:
  1. Handle multiple languages in the same page
  2. Standard sections that are present in all pages (e.g. the French wiktionary always has 1. Etymology 2. Form and pronunciation 3. Definitions and example sentences 4. translations)
  3. Definitions start with one or more templates
  4. Optional sections have a predefined order
  5. Configurable character sets are needed to build pronunciations
  6. A tool to build sources from one of the existing models, to put at the end of example sentences
  7. A tool to add links and lists of links to a section, many sections contain structured and ordered lists of links to other pages (words)
  8. Links to Wikipedia and other sister projects

Discussion

  • The solution for this problem may also imply some UX, to frame a branch of VisualEditor that fit with the specific needs of Wiktionarians. Also, in French Wiktionary we have a gadget to use a form for the creation of new entries, it could be a good indication of our needs in this kind of contribution, it's CreerNouveauMot. A related proposal, Visual entry form suggests to also use more preload in order to help begginers to have the template of the page. It may also be through a dynamic questionnaire asking questions such as "Is it for English?" Yes/No "Is it for a noun, verb, adverb, etc.?" "Is it still in use?" (if not, add "old" in the beginning of a definition), etc. Noé (talk) 10:00, 9 November 2019 (UTC)[reply]
  • @Romainbehar: I am sorry for contacting you last minute... voting starts tomorrow! I believe there may be a problem with this proposal. As you say, each Wiktionary uses a different format so it will be very difficult if not impossible to make a tool that works for all of them. Additionally, VisualEditor in particular is a behemoth of software, and customizing it for Wiktionary is probably outside our scope. However, we could make a gadget that allows for easy addition/modification of Wiktionary entries, but this would have to be specifically for your wiki. Would you like to reword the proposal to be solely for French Wiktionary? MusikAnimal (WMF) (talk) 03:17, 20 November 2019 (UTC)[reply]
  • @MusikAnimal: Thanks for answering my request. I understand that VisualEditor is a large piece of software and doesn't fit in your current scope, but creating a gadget is far from my inital idea: using VisualEditor in the French Wiktionary is almost useless as it just allows modifying text (sometimes it's more difficult than expected), and doesn't help much with Wiktionary specific templates and structures. The French Wiktionary already has gadgets, such as the one named CreerNouveauMot widely used to ease the creation of new pages. I'll create another entry to improve that gadget. Out of curiosity, could you give me links to the VisualEditor community and code? Romainbehar (talk) 08:05, 20 November 2019 (UTC)[reply]
    Understood. In that case I'm going to archive this proposal as out of scope, because even if we did work on VisualEditor, it'd need to be adapted to suit all the Wiktionaries. This is not really possible unless there is some sort of structured data. I have been made aware of Dbnary which does offer structured data, but I don't think this would help us if we're talking about editing. We'd still need some configuration for each wiki, when VisualEditor is supposed to be wiki-agnostic. I'm not sure what you mean by the VE "community", but technical details can be found at mw:Extension:VisualEditor. Thanks for your participation in the survey! MusikAnimal (WMF) (talk) 17:03, 20 November 2019 (UTC)[reply]
Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2020/Archive&oldid=19576953"