This page is an archive for Community Wishlist Survey 2023 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 February 10, we can't move any proposals out of the Archive.
I've archived this proposal because it doesn't require any engineering resources. Anyone is free to create instructional videos. In this survey, we're specifically looking for ideas that are technical in nature. You can review the FAQ for more information. Thanks for participating in the survey! MusikAnimal (WMF) (talk) 19:56, 23 January 2023 (UTC)[reply]
Add function for them who don't understand language, but page in their language doesn't exist
It sounds like you're asking for other language editions of Wikipedia to have their own copy of articles you see on English Wikipedia. This is not something that can be automated, unfortunately. We rely on volunteers in each respective language to translate and/or write the articles from scratch. mw:Content translation can help with this. As this proposal is not technical in nature, I am archiving it. You can review the FAQ to learn more about what proposals we're looking for. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 20:10, 23 January 2023 (UTC)[reply]
@Bruce1ee Adding namespace aliases is just a configuration change, so there's not really any engineering involved here anyway. I'm happy to archive this proposal for you, either as "withdrawn" or "requires community consensus." Is that alright with you?
Also worth noting that "WP" is not real namespace alias, but a pseudo-namespace. Each of those are merely redirects someone created. Likewise you can do the same with Templates. I.e. T:DYK. Also, as pointed out in the perennial proposals Nardog linked to, some shortcuts would conflict with articles, so it seems very unlikely the "T" shortcut would get implemented on English Wikipedia, specifically. MusikAnimal (WMF) (talk) 18:25, 24 January 2023 (UTC)[reply]
Proposed solution: A bot that would fix these minor errors. For example, for MOS:CURLY, it only needs to replace them with regular quotation marks. For more complicated things, such as with en/em dash consistency, it could leave a message on the talk page.
Who would benefit: Whoever the Manual of Style benefits. People who make minor edits.
Problem: It has been seen many times that a new contributor in an AFD discussion or many contributors from the same country try to save an article without any reason (I am not against their participation in the AFD deletion discussion), but many of them, due to their inexperience, give arguments outside of Wikipedia guidelines, which are completely wrong.
Proposed solution: In my view there should be a separate group for contributors participating in AFD deletion discussion and some set of criteria defined for those contributors to join this user group so that only experienced editors can join this group.
Who would benefit: Doing so will better adhere to the notability guidelines defined by Wikipedia.
No, absolutely not. IP users do occasionally give good arguments, and creating a user group to limit only certain people is an exclusionary practice. Besides, a good way to gain experience at AfD is to participate in a discussion and see the holes in your argument pointed out by others, and even if the arguments are bad, the closer can easily discount them when the discussion ends. The Night Watch (talk) 01:53, 25 January 2023 (UTC)[reply]
This would need to community consensus to move forward. In addition, it would be mostly involve only a configuration change, so there isn't much engineering that Community Tech could help with anyway. For this reason I'm going to archive the proposal. Thank you participating in the survey! MusikAnimal (WMF) (talk) 16:55, 25 January 2023 (UTC)[reply]
Problem: There are some bots, such as SeroBOT, using ORES estimations to do reverts in Wikipedia. Currently, the bot is using an additional request to retrieve ORES estimation to analyze if there is a bad faith or damaging edition to revert. The EventStream component could add this information to create real-time vandalism dashboards or similar tools (grafana?, irc bots?).
Proposed solution: Include, where is possible, the ORES estimation as a new key of the event streamed to not create an additional request to ORES endpoint. It
Who would benefit: Bot and tools using EventStream and users who need analyzing ORES estimation in real-time.
More comments: I know that the extra request will exist in tools (SeroBOT or EventStreams) because both elements are not connected. The negative effect will be to increase the RTT to show new events streamed.
This is not a place to complain about how people delete your articles. This is solely for providing ideas about technical software improvements that should be considered. —TheDJ (talk • contribs) 16:27, 25 January 2023 (UTC)[reply]
NRequires community consensus and does not need engineering resources
Problem: User Access Requests
Proposed solution: My solution to the many access requests that are made every day are granted depending on the years since one has been an editor and the editions made, the system selects it and starts the voting process, depending on the number of votes the system will give permission, voting will only be given for some permissions (Librarian, Bureaucrat, Checkuser, Suppressors, etc.), the system will only grant these permissions with voting permission. The permissions that the system will grant automatically without voting are: Autoconfirmed, Reversor, Verifier. The remaining permissions without voting will only be given when the user requests it.
The years as a Wikipedian and the number of necessary editions will be defined by mutual agreement between users.
Who would benefit: Librarians, bureaucrats and all Wikipedians with permission to grant user permissions, also requesting users.
Esta propuesta necesitaría el consenso de la comunidad para avanzar. Por otro lado, sólo consiste en un cambio de configuración, por lo que no hay mucha ayuda técnica con la que Community Tech pueda contribuir. Por ende, voy a archivar la propuesta. Si quieres saber cómo solicitar un cambio de configuración, puedes dirigirte a este link. Gracias por participar! / This would need to community consensus to move forward. In addition, it only involves a configuration change, so there isn't much engineering that Community Tech could help with anyway. For this reason I'm going to archive the proposal. If you want to know how to request a configuration change, you can go here. Thank you for participating in the survey! JFernandez-WMF (talk) 19:15, 25 January 2023 (UTC)[reply]
@Lion-hearted85: I will say I find it useful to know if something has been published or hasn't gone through because my internet crapped out, though I will say that on mobile, placing a green tick in the middle of the green text "Your edit was saved" isn't very readable. I don't know if this is an issue that's present on desktop, though.Ineffablebookkeeper (talk) 23:05, 23 January 2023 (UTC)[reply]
Since we learned that there is a workaround for those that do not want to see the confirmation message after saving an article, I'm archiving this proposal. Thank you for participating in the survey! HMonroy (WMF) (talk) 19:17, 25 January 2023 (UTC)[reply]
Problem: VisualEditor creates a lot of noise and hard to read syntax, e.g. adds a lot of white spaces to templates, uses numeric references <ref name=":0"> that become hard to maintain later on.
Proposed solution: Only edit lines where content changes were done to keep the diff clean. Use human-readable references names based on author last name and year or let the user define it with some sane defaults.
Problem: Currently, there is often vandalism from IPs and new users. Much of this is mere section blanking.
Proposed solution: I propose that non-autoconfirmed users are not allowed to change the size of a page above 1000 bytes; Wikipedia not publishing any edits that are 1000 bytes or over.
Who would benefit: Recent changes patrollers, and generally everyone.
More comments: There could also be some kind of pop-up when approaching the 1000 byte limit, preventing actual hard work from being lost unnecessarily. Vandals removing paragraphs for fun won't count bytes to ensure their edit is published. There are very few reasons why a new contributor would need to make such a large edit, and especially now after the "suggested edits" has been introduced, most good-faith contributors would likely never see this warning.
Hi Roundish, and thank you for your proposal. I believe it is possible to do what you are asking with abuse filter? There is access to user groups, page size, and other edit information that can be used to prevent or warn users when they are modifying a page. If abuse filter solves this problem can I go ahead and archive this proposal? Thank you. DMaza (WMF) (talk) 14:56, 25 January 2023 (UTC)[reply]
Hi, having looked at the abuse filter page, I agree. I'm just not entirely sure how to do it, kinda complex... You can go ahead and archive this, although it would be great if someone saw this and made a filter. --Roundish (talk) 23:26, 25 January 2023 (UTC)[reply]
Sometimes they don't answer common questions that people ask and come to Wikipedia to confirm it, and obviously some of those answers are very low in the article and highlighting them in the first paragraph or with a template would be better. — Redditor098 (talk)
@SWilson (WMF) Create a template to summarize the article. Longer articles would obviously use this template to summarize the article. Sorry if i answer this way is that I can't reply to your comment. Redditor098 (talk)
@Redditor098: No worries, and thanks for replying. It sounds like this is something that should be suggested on your Wikipedia's Village Pump, and isn't suitable for a wishlist proposal. I'll archive this now; hope that makes sense. SWilson (WMF) (talk) 07:26, 26 January 2023 (UTC)[reply]
Problem: There can be many photos of a subject, but often Wikipedia pages feature only a limited handful.
Proposed solution: Make galleries a default option on Wikipedia pages. Anyone can upload new photos of a subject right from the Wikipedia page edit mode and users can thumb through different angles, times, and facets of a subject.
Who would benefit: Everyone.
More comments: Wikipedia is amazing for text, but this would make it equally valuable for photo and video.
Problem: blocked users cannot make good edits. if they wanna do this, they must find someone to do(helper). dont misunderstand this with sockpuppetery. blocked ones asking edits to published from a helper in their userpages and they add good edits coming from blocked ones. but the problem is blocked ones cant find helpers easy.
Proposed solution: blocked ones add a request in a page existing in metawiki. patrollers or admins checking up the page and approve or decline the request. if they approve requestBOT will add requested edit to corresponding wiki. if they decline they must put a reason there. also, if blocked user abuse(declined request is not abusing) that feature, they gonna banned from this without warning and future appeal.
Who would benefit:
this feature will encourage blocked users to stay away from sockpuppetery. because they can keep make good edits. benefit for blocked users and wikipedia
blocking is making us upset. and that feature will help about this. benefit for blocked users
blocked ones and helpers has a place with this feature. blocked ones keep making requests and helpers keep helping if that feature exist. benefit for blocked users and helpers
and finally, that feature helping admins about unblocking. they can follow how blocked user did requests. admins cannot follow this right now. because blocked users can and keep do requests in various places. benefit for admins
Blocked users are blocked for a reason. If the admin belives there is any willingness from the blocked user to make good edits, then the admin can unblock the draft namespace (on the top 10 wikipedias) or the user namespace (on the remaining ones), and let the user have an second chance that way.--Snævar (talk) 20:43, 23 January 2023 (UTC)[reply]
The request bot could be a chance for experienced editors to review their edits and see it is possible for them to be unblocked, however there are different ways in other wikis. Thingofme (talk) 01:55, 24 January 2023 (UTC)[reply]
Index page organization on mobile is unreadable in french version. On mobile the picture hides titles because there is three columns.
[[1]]
Proposed solution:
For the french version, do same from english version. Two colums, the picture above the title box above page index, and the second columns is for summary or table.
[[2]]
This is template work that the community can do themselves. Are you saying that the community is unable to figure out how to do this and require assitance ? —TheDJ (talk • contribs) 00:16, 27 January 2023 (UTC)[reply]
Problem: When a Wikidata item has enough information to start a Wikipedia article on a person, it's still a cumbersome/repetitive task to create the article's initial paragraph(s).
Proposed solution: Create a tool that feeds Wikidata info to ChatGPT, then creates a userspace draft with ChatGPT's text plus en:Template:Biography.
Who would benefit: (1) Wikipedia, as it helps starting articles. Wikipedia editors with some knowledge/awareness of Wikidata, as it saves them writing highly similar texts and reminds them of available basic data. (2) Wikidata, as it encourages adding more details to items.
More comments: This would be particularly helpful for starting biographies; perhaps the idea is also useful for other specific article types. The tool could be offered for the languages that ChatGPT speaks (currently English, and to a lesser extent French, German, Spanish, Italian and Portuguese). It could be made available only if the Wikidata item has a certain minimum of properties.
Wikimedia's vision is - "Imagine a world in which every single human being can freely share in the sum of all knowledge. That’s our commitment." Creating articles using chatGPT (or any other AI tool) doesn't align with our current vision so this proposal will be archived. Thank you for participating in the wishlist survey 2023. - JSengupta-WMF
Problem: Since the release of ListeriaBot v2, there is a problem with lists with many links to big entities (for example, links to countries), which make the list generation fail. See some previous discussions: 1, 2. The issue is reported in the official repository: magnusmanske/listeria_rs#66.
Proposed solution: Fix the memory issues, which are probably a caching problem.
Who would benefit: ListeriaBot is used to automatically maintain lists of Wikidata items in various Wikipedias. It is used intensively by Women in Red in various languages, as well as other projects (3,204 lists in English, 1,152 in French).
More comments: Fix the issue with loading big external entities, possibly a caching problem.
@MarioGomDon't worry about finding the solution. If the issue is solely memory, we'd focus on that. If it needs to be rewritten, then so be it :) In other words, I do not think it's necessary to have two proposals. Do you mind if we archive this one in favor of the other? I will also make some changes to the other more clearly indicate that memory limitation is the primary issue we're trying to fix, but also that it may involve a complete rewrite. It doesn't really matter in the eyes of the voters, I would assume. MusikAnimal (WMF) (talk) 19:38, 30 January 2023 (UTC)[reply]
I'm voting now. We/re told that computing capacity doubles every few years. Can we squirt a bit of that benefit in Listeria bots direction pls? Victuallers (talk) 18:48, 28 January 2023 (UTC)[reply]
Problem: many pictures / photos uploaded on wiki are of no value - some users have not understood that the wiki pages are not here to store invauable family photos, blurred snapshots from their party or other freetime activity showing nothing valuable or usable for the community now or in the future
Proposed solution: to be able to delete photos that are of zero value
Who would benefit: wikipedia community (foundation, editors, visitors)
NProposes a social/policy/licensing change rather than a technical feature
Problem: Who is really an expert to analyze a change or participate in a focus group about discussion of specific topics or popularization?
Proposed solution: Indication of our areas of expertise with years of study and/or years of professional or associative experience on our profile and which can be validated or questioned by peers after exchanges
Who would benefit: everyone
More comments: These experts would accept to be solicited during a thorny debate on a form, a modification to be validated or improved
Problem: The official name of the songs and albums in Spanish are not respected. For example, the capital letters in these are removed. An album by the Argentine band Tan Bionica is called "Hola Mundo" and on this website it is written as "Hola mundo" which is disrespectful towards the band and its followers. Respect for the titles of musicians and bands should be a priority.
Proposed solution: Establish a new rule where the official titles established on all digital platforms by musicians and bands are respected, both in their songs and albums, with respect for capital letters and spaces being a priority, as is the case in English Wikipedia.
Who would benefit: Musicians and bands as well as their followers and Wikipedia readers benefit.
More comments: Music is very important to everyone. Respecting its forms is fundamental to the experience of it.
@Diublo El propósito de esta encuesta es para proponer solucciones técnicas. Esta propuesta necesita conseso comunitario para este problema, por esta razón archive su propuesta. Gracias por participar :)HMonroy (WMF) (talk) 06:25, 31 January 2023 (UTC)[reply]
El consenso existe, el problema es que algunos bibliotecarios simplemente deciden no respetar esto y lo cambian a su gusto, supuestamente siguiendo un manual del idioma, donde no es válido ya que la música es arte y se deben respetar sus formas. Que otra cosa podría hacer? Saludos. Diublo (talk) 18:39, 2 February 2023 (UTC)[reply]
Problem: It's very hard for new articles to be published without any well known and reliable sources. But, information is not all about reliable sources. There is a lot of information being inaccessible just because it doesn't have reliable sources.
Proposed solution: Voting method for new articles will push newly created articles to public voting. Wiki users and visitors can now find all those newly created articles in the homepage of Wikipedia. The articles passing the threshold of votes will now go through a physical field verification process by a volunteer from Wikipedia. If the information is found to be valid, it can now be an official Wikipedia article.
Who would benefit: This feature would be very helpful for people or events which do not have much online activity nor media coverage.
More comments: So, on every article which is not yet verified, users and visitors can find a simple button to know if they trust the information on this article. The article also will contain a warning that the information might not be true and is in the process of review.
In this survey we are seeking ideas of a technical nature. This proposal does not require engineering resources -- therefore, I'm archiving it. Please refer to the FAQ for more information. Thank you for participating! JFernandez-WMF (talk) 18:45, 31 January 2023 (UTC)[reply]
Problem: lack of knowledge of how to add a bibliography with url and the standardization problem when it is used (falta de conhecimento de como adicionar uma bibliografia com url e o problema de padronização quando é usado)
Proposed solution: the bibliography template creates the corresponding section in the article and also the links to each bibliographic reference filled in according to the pattern (a predefinição bibliografia cria a seção correspondente no artigo e também os links para cada referência bibliográfica preenchida de acordo com o padrão)
In this survey we are seeking ideas of a technical nature. This proposal does not require engineering resources -- therefore, I'm archiving it. Please refer to the FAQ for more information. Thank you for participating! // Neste survey estamos à procura de ideias de natureza técnica. Esta proposta não requer recursos de engenharia - portanto, estou a arquivá-la. Para mais informações, consulte a FAQ. Obrigada pela sua participação! JFernandez-WMF (talk) 18:48, 31 January 2023 (UTC)[reply]
"Add interlanguage links" interface should let users input sister wiki pages
Problem: Whenever I create a page at, say, Wikisource, and want to link it to a probably existing Wikidata entry, I should be able to use the "Add interlanguage links" interface from the sidebar. The issue is, I can only link to existing pages at other Wikisources, but not to a relevant article at Wikipedia
Proposed solution: in the free text field that lets you select "Language:" allow for other inputs.
Funnily enough, I always forget this doesn't actually exist yet. I find myself quite often searching at the said interface what to use to link to a sister project (you usually want to link from sister projects to Wikipedia) and then I remember I can't actually do that and I'll have to go to Wikidata if I want to make the connection. More often than not I just give up and decide to just link through a template. I strongly support this. — Klein Muçi (talk) 14:20, 27 January 2023 (UTC)[reply]
@Ignacio Rodríguez: This functionality is going to be provided by the new Autosuggest Sitelink gadget, which is still under development but hopefully will be launched very soon. It will help with linking new pages to existing Wikidata items. The reason that the interlanguage links don't support linking to arbitrary sister projects is that that feature is specifically about languages, and because it's not always clear what the connection should be (for example, Wikisource editions shouldn't be linked to Wikipedia articles about the work; they must go through an intermediate item that links the work and edition). This proposal is also pretty similar to the Popup to link to or create a new Wikidata object after creating an article one, so I suggest we archive this one and make sure that other one is capturing all the requirements. Does that sound okay? SWilson (WMF) (talk) 06:30, 1 February 2023 (UTC)[reply]
@SWilson (WMF) If it's really going to be solved soon, then I'm OK with archival. But I'm not sure that uncertainty about the link should limit us and make our work harder. There are instances when we are sure we should link to Wikipedia (authors and work pages). Maybe we shouldn't suggest by default sister projects, but if we manually input "xxwiki" it shouldn't be unallowed. Sometimes we the editors know what we are doing. The other issue is: if we miss the popup at creation, then we are at the same situation when can't easily link to Wikidata. Ignacio Rodríguez (talk) 12:16, 1 February 2023 (UTC)[reply]
@Ignacio Rodríguez: That's a good point, and I think the Autosuggest gadget should have a feature where it's possible to add the sitelink even not directly after adding a new page (i.e. it should be a button akin to the WikidataInfo gadget). I often find myself adding Author pages for Wikisource, where it's useful to be able to do it with as few clicks as possible. Regarding adding xxwiki, do you mean in a situation where you already know what the title is on xxwiki? Because otherwise, how do you know that it already exists on that wiki? (And yep, I think it is really going to be solved soon… it's already a gadget here on Meta and will be on other wikis soon.) SWilson (WMF) (talk) 12:23, 1 February 2023 (UTC)[reply]
@SWilson (WMF) Not necessarily you have to know the name beforehand, but one can assume it's already present at Wikipedia because of the notability of the subject. Or one could want to try and search for it. The sitelink gadget is very fast! Faster than opening a new tab, entering wikipedia, searching the subject, find the wikidata page and add the sitelink for sure. And multiplied by 2 if I'm adding e.g. a Catalan author, that sometimes do has an eswiki article, but sometimes only cawiki, and so on. Ignacio Rodríguez (talk) 14:03, 1 February 2023 (UTC)[reply]
Problem: Currently, it is possible to create an entry in Wikipedia only for famous people. WikiFamilyTree makes it possible for everyone to register a minimum of information on the web. It also provides the possibility of creating FamilyTree and connecting to each other
Proposed solution: Create a new wiki beyond Wikidata where all humanity can register information, only basic information and not biographical description. Then the family tree is created and gradually connected.
@Sunfyre: Thank you for submitting this proposal! There is another proposal wiki-anscestry that is proposing a very similar solution to your proposal. Are you okay with merging your proposal with the other proposal and archiving this one? HMonroy (WMF) (talk) 04:58, 2 February 2023 (UTC)[reply]
Problem: Translation is difficult if you don't know the language well. I know from experience if I wanted to help translate I would have to translate using third party extensions.
Proposed solution: Pull translations from many translation extensions and pull accurate translations.
Who would benefit: Translators and people who want to get translations out easier
More comments: I think translation should get even a minor rework to make it easier to get translations out there.
@NPRB: there are several different types of translation in our ecosystem. For example, translation of user interface messages (e.g., the "edit" button label) takes place at translatewiki.net, Wikipedia articles can be translated using Content Translation or starting a new article with the regular wikitext editor (in visual mode or wikitext), etc. For the particular case of Content Translation, there are several machine translation services integrated including Google Translate and Apertium. Could you clarify the proposal to indicate which kind of which kind of translation do you refer to, detailing the tools inolved and the ones you would expect to get integrated? Thanks! --Pginer-WMF (talk) 09:17, 26 January 2023 (UTC)[reply]
Many wikis specifically discourage tool translation as degrading the wiki's quality, i.e., something isn't always better than nothing czar22:25, 29 January 2023 (UTC)[reply]
Comment As mentioned above, something is not always better than nothing. I do not believe a person should translate a language they are not familiar with. Wracking (talk) 06:32, 30 January 2023 (UTC)[reply]
I hate excessive machine translation because it degrades Wikipedia quality, like what has happened in Vietnamese Wikipedia (a former admin was desysopped because of this). However this may be applicable to Meta repetitive translations, such as Tech News. Thingofme (talk) 15:48, 30 January 2023 (UTC)[reply]
NProposes a policy change rather than a technical feature
Problem: We have many opportunities to link to the Source. It can be a link to a website, a book, a document, a video resource, a tag on a Facebook post or Tweeter, and so on. Visually, it's all just a tag with a number on it. This can cause a problem in verifying the article.
Proposed solution: I propose to visually verify these icons. If the source of information is a video resource (Youtube), then the label is the same kind, if the link on Facebook is different and so on.
Who would benefit: When you read the article it will be visually clear what is the source of the article and how reliable it is.
More comments: icons should be in the same style and not stress the reader
@BlackStar1991: This can be done by modifying the citation templates on the wiki. Because this doesn't need any software changes or development, there's no need for this to be voted on. You should suggest these changes via the Village Pump or other relevant forum on your wiki. SWilson (WMF) (talk) 23:10, 2 February 2023 (UTC)[reply]
NProposes a social/policy/licensing change rather than a technical feature
Problem: I am a math professor. When I read math pages, they tend to be a fine references for things I already know but I find them to be hard to read if I am trying to learn the material. Often I have added explanations which are quickly removed. One such reviewer explained to me that this is the purpose/culture of Wikipedia.
Proposed solution: Allow both list of facts and readable explanations.
Who would benefit: People trying to learn
More comments: Maybe people who want to learn go to youtube or now chatGPT instead.
@JeffAEdmonds: Thanks for adding this proposal! My partner is endlessly reading math articles on Wikipedia, and he actually mentioned a similar sentiment to me earlier this week: that many math articles are incredibly detailed but don't provide a decent educational summary. His hypothesis being that most people who read these articles would benefit from a summary that was longer than the lead section, but not as detailed as the full article. I'm not sure how to approach this problem with a technical change though. Like User:DWalden (WMF) mentioned, this proposal currently sounds more like a policy change than a technical request. However, I think there are also technical solutions that could be considered if you want to make some updates to the proposal. Some random thoughts (that might be terrible, but I'm just brainstorming)...
Would certain educational articles benefit from having an expandable TL;DR summary (that was more educational & provided more examples) after the lead section?
If we want to keep this proposal from being archived (due to it currently sounding more like a policy change request than a technical feature request) I would suggest a revision to the proposed solution. Feel free to run with any of those ideas, or come up with something even better! 😊 Thanks so much for thinking about how we can make articles more accessible and engaging for people learning about complex topics! --KStoller-WMF (talk) 18:13, 27 January 2023 (UTC)[reply]
@JeffAEdmonds Just a heads up that wishlist items should "require engineering work and NOT be about a policy or social change" [1].
So this proposal might get archived before voting begins if the technical wish isn't clear. Do you have time to update the proposal before Friday? KStoller-WMF (talk) 00:05, 1 February 2023 (UTC)[reply]
In general, technical articles should be written in an accessible way, although I think enwiki math articles are famously bad at it. The Encyclopedia of Life used to have a "complexity slider" which made the article increasingly longer and more jargony by displaying extra sections, but in practice such a thing would be such a large editorial burden that I don't think there's any real chance of it working out. I think WMF product had some vague plans around "learning pathways", ie. sequences of articles the user is supposed to read in order, although I don't think that would do much to make articles learner-friendly. In theory, Wikiversity or Wikibooks would be spot on for learning-focused articles. In practice, those projects haven't really caught on (they get about a thousandth of Wikipedia's traffic and so aren't that useful for reaching a wide audience). --Tgr (talk) 00:53, 1 February 2023 (UTC)[reply]
This problem is legitimate, but as this wish is currently written the solution is really a social / policy change. If approved I don't think it would be clear to people what they would be voting for.
Problem: High learning curve for editing Wikipedia: Need to know MoS, secondary sources, footnotes, copyright, NPoV, edit summary, notability.
Proposed solution: For someone's first edit, make it very structured, like a checklist or a tutorial. Let Wikipedia show, step by step, with no distractions or deviation, what needs to be done for an edit that will stay.
Who would benefit: Everyone, more first-time editors continuing to edit, less biting of newcomers, less frustration in general.
Exactly! I love to see a wishlist item that is so close to what the Growth team is working on! The Growth team has been working on "Structured tasks" for first-time editors (which is one of the Suggested edits we provide to newcomers. Structured tasks are designed to help a brand new account holder make their first edit successfully. They offer onboarding and basic step-by-step instructions. So far, the Growth team has built two of these structured tasks for newcomers: one that helps new editors add internal links and one that helps new editors add images.
In an experiment evaluating the "add a link" task, we saw this task not only helped more new account holders try to edit for the first time, but it also improved newcomer retention! Neither of these Structured tasks are released on English Wikipedia yet, although you can test them from Beta wiki if you want to try them for yourself. They are also available on many other wikis currently (deployment table).
We hope to gradually release Structured tasks to more wikis as we make further improvements, train the models for more wikis, and introduce these features to each language wiki (T304110 & T322592).
So, @Cardofk, do you think the Growth team's work on Structured tasks is fulfilling this wish? If not, what details can you add to help differentiate this wish from the Growth team's work? For example, do you see an area we could focus on more to help make a first edit tutorial more helpful to newcomers? Growth's Structured tasks currently focus on one very specific type of edit (adding a link / image) but do you see some other way for us to make a tutorial more general or universal? Thanks again for adding this proposal! - KStoller-WMF (talk) 04:59, 24 January 2023 (UTC)[reply]
In Vietnamese wikipedia, the "add a link" feature is used for spamming edits to get to extended-confirmed level, but adding other tools into helping newcomers is a good way to attract new editors into the project. Thingofme (talk) 09:36, 24 January 2023 (UTC)[reply]
Hi @Thingofme! Sorry to hear that the "add a link" feature is leading to spamming on Vietnamese wikipedia! Unfortunately misuse of a tool is likely to be a concern for any tool designed to make editing easier for newcomers; anything that helps make an edit easier for a newcomer will also make editing easier for someone looking to quickly increase their edit count.
The maximum number of link suggestions to show on each suggested task. For example: a new editor could receive up to three link suggestions per article currently.
The maximum number of "add a link" suggested tasks newcomers can complete daily. For example: a new editor could complete up to 25 of these easy "add a link" edits per day before we stop showing them in the newcomer's "Suggested edits" feed.
Communities can configure several other settings for the "Add a link" task and even disable the task if they find it too disruptive for patrollers. However, for any wiki interested in improving new editor retention, I would suggest leaving this feature enabled. If abuse is an issue, perhaps just adjust the configuration to decrease the maximum number of "add a link" suggested tasks an editor can complete daily.
@Cardofk thanks again for this proposal! As it is currently written it's a rather large wish that overlaps with much of the Growth team's current work. Based on the fact that the Community tech team declines proposals if they "are already in Wikimedia Foundation teams' plans" [1], I would suggest that you clarify the proposal further to differentiate it from the Growth team's work on Structured tasks or the proposal will likely be archived. Thank you! KStoller-WMF (talk) 23:43, 31 January 2023 (UTC)[reply]
Thank you KStoller-WMF, yeah, I know that the proposal is too large and generalised, but I do not mind if it is archived, I just wanted to flag this as something important. I am glad that efforts are being made to make the learning curve in Wikipedia less steep. Cardofk (talk) 08:28, 1 February 2023 (UTC)[reply]
@Cardofk - thanks again for thinking about newcomers! The Growth team is fully dedicated to this user group and user problem. We still have a long way to go, and it's a challenge to find solutions that work for all users on all different wikis, but we are doing our best to take steps towards creating better onboarding for newcomers.
The team was torn on if we should move this to "Larger suggestions" or Archive... but since this proposal is "already in Wikimedia Foundation teams' plans" [1], I think I'll follow that Community tech guidance and archive this.
However, you still have two more days to add a new Wishlist proposal if you have any smaller feature ideas for helping newcomers. Thanks again for highlighting the need for better tools and tutorials for new editors! KStoller-WMF (talk) 22:24, 3 February 2023 (UTC)[reply]
This is great. I wonder if a manufactured, gamified tutorial (i.e., a fictional article with obvious typos/MOS violations) could help with this. "Newcomer tasks" were definitely helpful in introducing me to English Wikipedia editing, but sometimes the articles I was served early on were a bit intimidating, especially as I was completely unfamiliar to the editing technology as well. As I'm fairly new to Wikipedia editing, I've done "Newcomer tasks," and I think it was very welcoming and still has lots of room for improvement. Wracking (talk) 07:26, 30 January 2023 (UTC)[reply]
@Wracking That's great to hear that you got started with Newcomer tasks! I agree that many of those tasks are still fairly intimidating to a brand new editor. We hope that Structured tasks will help, but I agree there is still a lot of room for improvement when it comes to onboarding new editors! One task that is fairly newcomer-friendly and structured is Content translation, but it's not currently a task we present on the Newcomer homepage. We might explore ideas around this soon T321529. Let me know if you are interested in offering feedback on idea or designs in the future. Thanks! KStoller-WMF (talk) 23:55, 31 January 2023 (UTC)[reply]
Proposed solution: Create a template and a system like suppression proposal. With the photo to preserve and the photos to delete. Administrators, moderators or experienced users look to the proposal and delete the photos to be deleted, or keep them.
Who would benefit: All users
More comments: There is a template named superseded, but it is not enough to delete similar photos.
This could be useful, but the category you linked actually shows a nice variety of photos I wouldn't consider to be duplicates. They are of the same subject matter – the Basilique du Sacré-Cœur de Montmartre – but also they're not; one shows its architecture in detail, there's three examples of pre-1910 postcards of the Basilica from different angles, one is a face-on shot, etc. But some do seem close enough that you could maybe propose them for deletion under perhaps new criteria for deletion, that two photos are too similar and one is clearly the better option. I don't know if the problem is big enough to warrant a new tool or discussion board entirely, but I'd say a new criteria for deletion could work for this.Ineffablebookkeeper (talk) 23:11, 23 January 2023 (UTC)[reply]
Bad idea. We don't save any server space by "deleting" files, and many files on Commons are used externally by 3rd parties. Deleting such files would break the chain of attribution (e.g. in the case of CC-BY-SA) and cause potential copyright issues for external re-users who link back to Commons. -FASTILY01:30, 24 January 2023 (UTC)[reply]
I agree with Ineffablebookkeeper: there should indeed be a possibility for deleting photos that are very similar but are not considered to be duplicates, and this might be implemented by new criteria for deletion. There are too many photos that would fit. The advantages are for end-users: people who are looking for photos and are overwhelmed by many similar photographs; if they see only a good choice/selection, they can find easier and faster what they are looking for. To meet the objections of User:Fastily, the files of the deleted photographs might get redirects (provided that the attribution and licence are the same). --JopkeB (talk) 04:42, 25 January 2023 (UTC)[reply]
"the files of the deleted photographs might get redirects (provided that the attribution and licence are the same)". That's literally not how copyright/attribution works. -FASTILY07:04, 25 January 2023 (UTC)[reply]
Strong oppose. WMF is doing just the opposite with picsome - making commons into a general repository for stock fotos. It is a terrible idea to force re-users to use an image that passes the aesthetic filter of an admin at commons. If there are a million of fotos from the same object, than it is the duty of commons users to help re-users identify the one, that is the "one" for this specific re-user by providing depicts-SDCs. --C.Suthorn (talk) 11:17, 25 January 2023 (UTC)[reply]
Strong oppose. Per above. Also similarity of files may be subjective, one can say that '2 files are near-duplicates' while other user can say 'quite different'. Юрий Д.К. (talk) 19:13, 25 January 2023 (UTC)[reply]
We have a method: you can suggest them for deletion but I don't know why it would matter. Commons shouldn't be the arbitrator of what is the "best" version of a photo. Different projects may find different ones useful. Why is this at Meta anyways? Is there a proposal to delete a version at English because a version at the Polish one (for example) is "better"? -- Ricky81682 (talk) 19:29, 25 January 2023 (UTC)[reply]
Correction. I meant to say how would having this at Meta solve the issue. A discussion (presumably) at Commons that says the version used at one wikis is to be deleted because it's bad compared to another one is not a productive discussion. -- Ricky81682 (talk) 23:39, 25 January 2023 (UTC)[reply]
@Tangopaso: You mention 'models' a couple of times here. Which models are you referring to? Could you add a link to more information, for people who aren't familiar with this system. Also you mentio "a system like suppression proposal", is that a separate or previous wishlist proposal that you mean? Could you link to it? Thanks! SWilson (WMF) (talk) 04:19, 27 January 2023 (UTC)[reply]
Probably "Template".
But: At Commons Media files can be nominated as a "valued", "good" or "excellent" file and categories come with a button to show only this v/g/e media files. So the proposal is actually fulfilled in a way. plus: Images are singled out in wikidata as the representative image of a wikidata item. C.Suthorn (talk) 17:31, 28 January 2023 (UTC)[reply]
I'd agree with the strong oppose: For one thing, properly documenting a restoration means having the original, a PNG version (lossless, so it can be further edited), and a JPEG (as PNGs don't display well). How would we even begin to have something WMF creates deal with that unless it's just asking volunteers to? Adam Cuerden (talk) 01:27, 29 January 2023 (UTC)[reply]
Sorry, but I am French and my English is perhaps not fluent. I think I used the word model instead of template.
5 or 6 times I proposed the suppression of an image with the topic very similar to this one. Or with the template superseded. All of them were rejected.
I will respect the consensus of course. But in some years, there will be thousands of photos about a same subject. It removes the encyclopedic value of Wikipedia. For updating an encyclopedy, an adding process is necessary. But a cleaning process is also necessary. In my opinion. --Tangopaso (talk) 22:16, 2 February 2023 (UTC)[reply]
The different language versions of Wikipedia are enzyclopedias. Commons is not an encyclopedia. It is a media repository. There will not be thousends of images of the same subject. There are thousends of images of the same subject. That is intentional. And if you work on a language version of Wikipedia you do select one of this thousends of images for the article in that language wikipedia. But there are millions of other uses for this thousends of images. There is Wiktionary and wikivoyage. There is the Star Trek Wiki, that is not even part of WMF sites. There are millions of other web sites, news papers, books and so on. It is not your nor anybody else's choice to select, who should be allowed to use an image. There are ways to promote images: Good, useful, excellent images, the superseded template. But Wiki does not censor. C.Suthorn (talk) 05:37, 3 February 2023 (UTC)[reply]
@Tangopaso: Looking at the two aspects to this proposal, there is no community consensus for making it easier to delete similar files from Commons. The other aspect, of building a system to find the similar files, does I think sound interesting — but there is no actual use case that's supported by the community. If the Commons community was already engaged in deleting similar files, and wanted a quicker way of identifying them, then I think this this proposal would be great. But without that work being active (and in fact being mostly discouraged), there's no point in building the tools to help it. SWilson (WMF) (talk) 02:56, 6 February 2023 (UTC)[reply]
Please add exact number of page watchers under Page informations
This is a deliberate limitation placed for privacy. While lowering the threshold may be an option, always showing the exact number is not. Nardog (talk) 09:00, 5 February 2023 (UTC)[reply]
@W like wiki: As Nardog points out, this is an intentional limitation. Users with the unwatchedpages right can view the actual number (e.g. usually admins). See mw:Manual:$wgUnwatchedPageSecret for more info. It does look like the number '30' might have been chosen a somewhat randomly: there's a comment on the original task saying that it could be adjusted, and a comment in the WMF config saying that it comes from the "default value of https://toolserver.org/~mzmcbride/watcher/". So perhaps a discussion can be had about what the number should be (although that's something that doesn't need to happen within the wishlist). The main idea of not surfacing which pages are underwatched is sound though, because if no one's watching a page then people can more easily vandalise it. There's also the possibility of figuring out who is watching what, on wikis with very few users. SWilson (WMF) (talk) 06:09, 6 February 2023 (UTC)[reply]
Problem: ClueBOT, despite being a reliable anti-vandalism bot, is unable to focus on lots of pages on the same time. Last week, a Wikipedia user vandalised Just Dance 2023 Edition twice, and I reverted it. It can be annoying for people that watch the page and can he hard to revert when not enough people watch the page frequently
Proposed solution: To add more anti-vandalism bots on Wikipedia and possibly other Wikimedia projects; can be named [insertsomethinghere]BOT
Who would benefit: Wikipedia users that check pages that not many people check.
More comments: The other bots can focus on one certain project or multiple projects, so that the counter-vandalism bots are more effective.
@Brachy0008: ClueBOT, and most other bots on Wikimedia projects, are operated by community members - there are a wide range of bots already operating, including other anti-vandalism bots. Is there a specific kind of vandalism that the bots are missing? This wish needs to be more specific for it to be accepted for the wishlist because the problem and proposed solution are quite vague as currently written. Samwalton9 (WMF) (talk) 13:44, 30 January 2023 (UTC)[reply]
Problem: Special:RecentChanges officially only show the last 500 entries, which interferes with some users' workflows to go through it in big chunks. To a lesser extent, this is also true of watchlists (see 2016 wishlist entry). (In practice, we have gone back and forth on whether to allow more; right now you can get up to 5000 entries by editing the URL, but this is hard to discover, might be disabled again due to performance issues, and pretty slow both on the server and the frontend side - old browsers freeze up etc.)
Proposed solution: Add paging controls (ie. navigation options to see prev/next 500 entries, like on Special:Contributions etc) so users can go back in watchlist history without having to load huge chunks at the same time.
Who would benefit: Patrollers and editors who use these pages to review lots of changes at once, with a snappier user experience.
More comments: The watchlist and recent changes are very similar both in concept and database query structure, and share a lot of code, so it shouldn't be hard to implement the same feature for both of them at the same time.
Problem: Yes, you can watch all the Wikipedia articles you've been in your normal navigator's history, but it can be quite confusing to trace a continuity in your journey into the website. Besides, other also visited websites may complicate the process, and if you've searched in not one, but several devices, you'll be completely lost. Even there can be some pages missing. The biggest inconveniences are when someone tries to search for an article that found interesting but immediately forgot, and when he finds an article with many visible mistakes, but thinks to edit it later, believing he will remember it (you can mark it on your computer's favorites list, but anyaway).
Proposed solution: Create a private history only for registered users (so that it can't be seen by anyone but the user) that collects in chronological order all the articles and files that has visited.
Who would benefit: People who want to remind those frogotten articles, if we consider the idea of a private history for that specific use.
@M4tinbeigi: You are saying that on https://fa.m.wikipedia.org the line Srpskohrvatski / српскохрватски (صرب و کرواتی) is causing the mobile view to be so wide that it will overflow the viewport ? It seems that someone has set nowrap on all language names, which is a bad option to use in mobile layouts, because of exactly this problem. I suggest changing page fa:الگو:Wikipedia languages/styles.css from
@Ebrahim: OK, i have realized that there is another problem, which is RTL specific, which I had not noticed initially as my default interfact language is English. This has to do with the default layout of lists, specifically hlists.
.wikipedia-languages>ul{list-style:none;text-align:center;clear:both;font-size:110%;padding:0;/* add this line to pre-existing block */}/* Add this new block which tells hlist not to wrap, * which particularly in this template is undesirable */.wikipedia-languages>ul>li{white-space:normal;}
I second Aaron Liu’s observation; this seems quite contrary to the spirit of a wiki. Perhaps the proposer can give more specific examples of situations where this makes sense, or where it seems a reasonable solution to some other problem. As it stands, they have not said why they have a problem, and the claim that it would help all users seems very exaggerated. PJTraill (talk) 23:53, 23 January 2023 (UTC)[reply]
@ComputerHotline: When you say lock a category, do you mean a) preventing edits to the category page; or b) preventing any new pages being added to the category? It is already possible for wikis to protect individual pages (including category pages) where required, so if you could clarify — it sounds like this proposal could be scoped to protecting against adding items to a category. SWilson (WMF) (talk) 03:05, 24 January 2023 (UTC)[reply]
@ComputerHotline: Right, that's true, but page protection is something that's already available. I'm just trying to figure out what the focus of this proposal should be. I'm suggesting that it be renamed to e.g. "Category inclusion protection" and to be about preventing pages from being added to particular categories. As others have said above, the aspect of this about it being the creator who applies the protection is likely to not be feasible because it goes against the whole notion of a wiki being a collaborative environment. The aspect of it about page protection is also not needed because that's already possible. Which leaves only the category-inclusion part. What do you think? SWilson (WMF) (talk) 07:01, 24 January 2023 (UTC)[reply]
This doesn't make any sense. Even user categories are subject to other editors messing with them. This could technically be done with blacklists but I don't see an example where this makes any sense. -- Ricky81682 (talk) 23:37, 25 January 2023 (UTC)[reply]
A category can be effectively "locked" (preventing new pages being added) by using w:Wikipedia:Edit filter. Admins can do this if there is enough justification for it. On the other hand, allowing any user to "lock" a category at will is something that will probably never happen. MarioGom (talk) 15:49, 29 January 2023 (UTC)[reply]
Problem: Search results currently mingle pages with the search term in the title, and pages with the search term found in the page. The number of search results is a combined total.
Proposed solution: Split the number of search results between these cases, and allow us to select results fitting only one of these cases.
Who would benefit: editors and admins, especially when harmonising page names.
Thanks for the reminder. I have only just read the instructions carefully enough to realise that if searching for multiple words but not an exact phrase, then "intitle:" needs to be repeated before each word, and then it works. Aha! That will at least help with the task that I mentioned, of harmonising page names.
How about the other case, looking for words within article text rather than the page name? That would exclude e.g. redirect pages. (I confess that I can't immediately remember what I was doing when I made a note wanting this facility.) Fayenatic london(talk)16:47, 3 February 2023 (UTC)[reply]
Problem: The Watchlist is a very important page for a wikipedian. This is my default page. Yet, the user experience is quite bad. Typically I've a list of changes in chronological order. I have to click on each change, review the change, come back to the watch list and so on.
Proposed solution: First I think it would be useful to sort the watchlist by page first and chronological order second. This means grouping together changes in the same page which I haven't visited yet. Then it would be great to go easily to next change in my watchlist without coming back to the watchlist page. Just swipe left or right on the mobile or something easy using a desktop. This would make the reviewing process much easier.
Who would benefit: All wikipedians looking at their watchlist.
sort the watchlist by page first and chronological order second How is this different from the existing grouping interface ("Group changes by page in recent changes and watchlist")? Nardog (talk) 17:34, 30 January 2023 (UTC)[reply]
@PAC2: A few things that you may not be aware of that could assist you: In your recent changes preferences, there is an option called "Group changes by page in recent changes and watchlist". Also in your watchlist preferences, you can set the option "Expand watchlist to show all changes, not just the most recent". Between these two, it does a decent job at grouping changes. Another trick is to use the Popups gadget, which I see is available on French Wikipedia. Using this gadget, you can see diffs without having to leave the watchlist (though it does not mark the pages as visited). Do these tips help you?
As currently written, "Redesign the watchlist" is too vague of an ask. I want to first make sure the existing solutions aren't working for you, and find a way to trim down this proposal so that it is small enough for our team to work on. Thanks for participating in the survey! MusikAnimal (WMF) (talk) 17:39, 30 January 2023 (UTC)[reply]
@PAC2: Did the tips above help with the problem in this proposal? We reviewed this proposal and we are considering archiving it. Is is okay if we proceed with archiving it? Thank you! HMonroy (WMF) (talk) 21:17, 6 February 2023 (UTC)[reply]
Problem: Currently, none of the Upload tools are official from WMF/Commons, all of them are volunteer maintained, broke often, and doesn't offer user support.
Proposed solution: Create an official desktop software (for Windows at least, because that's what I use. Feel free to open separate request for other OS)
More comments: I'm personally using Vicuna for my GLAM works, because the alternatives didn't work. But Vicuna doesn't support 2FA, and I honestly didn't feel secure using any 3rd party software and giving away my password, especially having to Disable 2FA for me to Upload to Commons! That's unacceptable in my view, but alas, there's no alternatives. (and please don't ask me to use UploadWizard)
As I have pointed out, "Vicuna doesn't support 2FA, and I honestly didn't feel secure using any 3rd party software and giving away my password, especially having to Disable 2FA for me to Upload to Commons!" I would prefer official software that are actively maintained by the dev team, support 2FA, and bug-free. ✒Bennylin08:33, 3 February 2023 (UTC)[reply]
What's the value in developing OS-specific tools? What can it do that a web tool cannot do, while not being limited to a specific OS and not requiring installation (and with that a significantly higher level of trust in the author) and a much more complicated release process? --Tgr (talk) 03:08, 5 February 2023 (UTC)[reply]
The existing upload tools work; if there are specific issues with them then can be reported and fixed, but we cannot develop an OS-specific too. JMcLeod (WMF) (talk) 01:11, 8 February 2023 (UTC)[reply]
Module for unification of climate tables and diagrams
Problem: On many wikis, climate tables and charts are used. But in many cases, different software solutions are used, and the data were entered in individual pages. This means an unnecessarily high effort.
Proposed solution: The climate data by month (Average max., medium and min. temperatures, precipitation, humidity, rainy day, sunshine duration, water temperatures, etc.) should be stored in Wikimedia Commons data tables using International System of Units and its sources. The data structure has to be developed. Wikidata should have properties where local or nearest available data are stored. The presentation of these data in articles should be possible in two forms: tables and/or charts. In tables, it should be possible to select the data of interest. Data which are not available should not be shown. Data conversion should be possible. The style of these tables and table cells should be done with CSS. Additionally, charts should be produced showing different data (temperature ranges, precipitation, etc.). Charts should be realized as SVG graphics to modify them with CSS. The data import should be realized by Wikidata id or Commons data table name.
Who would benefit: All readers and authors in content wikis (Wikipedia, Wikivoyage, maybe Wikidata)
More comments: I think the data upload can be made with bots from free databases.
I tested the tool of visual diffs. Looks like it could be used after submission. I cannot see visual diffs after hitting the button of Show changes.
I also tested the tool in Chinese wiki. Chinese wiki has a special module called noteTA, which could allow people to transfer Chinese to fit different places' registers. However, when I removed a CGroup in noteTA, the page showed no visual difference between two edits. But I was able to notice the changes by comparing two HTML files. GriefCrow (talk) 21:33, 6 February 2023 (UTC)[reply]
(UPDATE)I found out when I turn on new wikitext mode, I can see visual diffs after hitting the button of Show changes. For the noteTA issue, I think it might be the issue of Chinese wiki. GriefCrow (talk) 04:33, 7 February 2023 (UTC)[reply]
@Intelligencescout: can you explain this a bit more? Right now anyone can register, and if you are using the mobile app you can save a reading list. phab:T322093 is about making the the reading list available to web users as well - is that what you want? — xaosfluxTalk01:56, 30 January 2023 (UTC)[reply]
Problem: Wikipedia is not sufficiently directly linked to other mediums channels such as social media.
Proposed solution: Partnering with media channels such as Meta. So you can put a direct link to an article in your post. This will increase Wikipedia's accessibility.
Well, what keeps you now from putting a direct link to an article in your post? (Is this about better article previews in social media tools, e.g. T213505?) --Tgr (talk) 06:44, 5 February 2023 (UTC)[reply]
@Cunningpal: Thanks for your proposal! Since you say you click on the magnifying icon, I'm assuming you're using the legacy Vector skin? In all skins, you should have a working search bar that doesn't require you to go to another page to enter a search term. Could you explain what, if anything, is stopping you from entering a search term? Or am I misunderstanding your proposal? MusikAnimal (WMF) (talk) 01:41, 24 January 2023 (UTC)[reply]
@MusikAnimal (WMF): In the Vector 2022 skin, if your window is less than 1000 pixels wide, the search bar disappears and all that's shown is the magnifying glass. You click on the magnifying glass and the search bar pops up, hiding the Wikipedia logo and hamburger menu next to it. Trey Jones (WMF) (talk) 21:30, 26 January 2023 (UTC)[reply]
Ah, perhaps that's what they meant. Though as TheDJ points out below, this is the same number of clicks as other skins. With JavaScript disabled, it has to browse to Special:Search first, but even then it puts focus on the text field. MusikAnimal (WMF) (talk) 21:54, 26 January 2023 (UTC)[reply]
Im slightly confused.. to enter something in the old skin, you have to click on the textfield before you can type. To search in the new one, you have to (sometimes) click the loupe before you can type. Thats exactly as many actions correct ? —TheDJ (talk • contribs) 20:01, 24 January 2023 (UTC)[reply]
Problem: Only one image can be used in a image= parameter
Proposed solution: A gallery, where titles on the top switch the image used, e.g. a title labelled 1980 will select a specific image, another labelled official will select another, similar to the gallery on this page.
"Already possible on wikis with w:MediaWiki:Gadget-switcher.js, as in Template:Location map." This is already available, you must ask an Admin to enable the gadget on your wiki and then it will be available.
For this reason, I am moving it to the Archive but we really appreciate your participation and hope that finding out it is possible can help you enable the functionality. NRodriguez (WMF) (talk) 20:43, 8 February 2023 (UTC)[reply]
History of all pages I've read while I'm logged in
Problem: There's no easy way to backtrack the articles that I've read (i.e. opened in my browser), unless I open my browser history. Won't (fully) work if I'm on multiple device and/or multiple browsers. Can't possibly remember all the articles I've read, yet sometimes I remember I was reading it at December 2022 (for example). So a history of all Wikiverse pages (global, multiprojects) would provide a solution to this.
Proposed solution: Just like in ytube, we have a history of all the videos we watched, it would be great if we have a list of articles we've read, and when we read it. (a cross of browser history x watchlist) assuming we're logged in.
Who would benefit: People who are avid Wikipedia reader and would sometimes go back to the article they read in the past that they've read. In its later incarnation of this feature, maybe we could add how many bytes are in those articles, and how many minutes we spent reading them, then at the end of the year, it would automatically compile a list of articles we've read this year, how long are their bytes (or word counts!), and how many hours have we spent on reading them. This is the Wiki-equivalent of bragging how many books you've in that year.
More comments: Currently the closest thing we have is Special:Contributions, where it listed all the pages I've (read and) edited. But in the Special:Reading history I envisioned, the list of articles read and articles edited could be combined together.
I know it's a long shot brainstorming idea, but I would like others to comment on this idea. Has this ever occurred to you: ("Oh, I wish I remember the article I read that day!") or in similar vein?
Agreed, this is a privacy nightmare and data that many foreign governments would love to have and to get their hands on. I don't really see a way to implement this safely, other than locally in the browser (which is what the browser history does). The mobile app does also keeps that data in your device, properly sandboxed and non-transferrable. Now that can be implemented in the browser as well of course and I would actually like that as an idea. BUT, you'd have to find some way to encrypt the data or something, as especially desktop computers much more often are shared between multiple users (schools, libraries etc). Its much more likely that the browser unintentionally leaks your interests to another user, than your own mobile device. —TheDJ (talk • contribs) 14:36, 2 February 2023 (UTC)[reply]
It could be implemented as an opt-in option. Users who choose to activate it will be given an appropriate warning about the privacy-relared issues. The user may subsequently opt-out, which will erase the list permanently; trying to opt-out will cause the user to get an appropriate warning. Animal lover 666 (talk) 21:52, 2 February 2023 (UTC)[reply]
Also, allow a user to remove specific entries from the history. And the data should never be accessable even to cueckusers - only the user him/herself, or devs as needed for development. Animal lover 666 (talk) 22:19, 2 February 2023 (UTC)[reply]
We reviewed this proposal and we asked the Legal team for input. Due to privacy concerns, we are archiving this proposal. Thank you for participating in this survey! HMonroy (WMF) (talk) 21:40, 8 February 2023 (UTC)[reply]
Problem: Due to the poor attention of the authors when editing and creating articles, the mistakes of newcomers and bots, and because of moving pages, some of the links between articles are led incorrectly. Editors rarely check all links in articles. Problem also includes links between articles in different languages.
Proposed solution: automatically analyze the context and indicate potentially problematic links using artificial intelligence
Who would benefit: editors who can quickly see most of the incorrect links. As a result, readers won't be disappointed when they don't go where they shouldn't.
More comments: a significant part of the tool's indications will be incorrect and will obviously require manual checking and checking other links. However, not all editors will understand this
@Proeksad: As written, I'm afraid this proposal is too broad. Could you explain which kinds of links are incorrect? For example, a previous wishlist proposal complained that linking to disambiguation pages is a common problem, so our team implemented a feature that warns users when linking to these pages. When using VisualEditor or the "Insert link" functionality of WikiEditor, you get visual clues and sometimes descriptions (from Wikidata) that help you decide what link to use. These are all examples of things we can do to improve linking. In order for your proposal to go into voting, we need it to be more specific and ask something similar. Unfortunately we have only a few days left before voting starts. Let me know your thoughts as soon as possible. Thanks, MusikAnimal (WMF) (talk) 22:08, 7 February 2023 (UTC)[reply]
Sorry for delay. Yes, my proposal is too broad. So you can move or archive. I suggest analyzing the context on the pages to evaluate the correctness of the links by artificial intelligence. Proeksad (talk) 23:32, 8 February 2023 (UTC)[reply]
This just popped up as a notification box, and I'm quite busy just now, but I stopped long enough to ask myself: what is the single worst paper cut in my Wikipedia workflow that unnecessarily wastes my time?
And very quickly it came to mind: being unclear about whether a page link should be formatted as a proper or improper noun.
I'm an armchair polymath. I know quite a bit about quite a lot. What suffers outside of my major field (computer science) is my exact knowledge of arcane terminology.
I've noticed a nice popup which arrived in the last year or so that warns me in real time when I keyboard a link to a DAB page. For some reason I can't hover on this to quickly find what I should use instead (requires an actual DAB page visit, which is overkill 80% of the time). But I have some custom JS from way back and so I never know for certain that my own experience is entirely mainstream. Small problem, and if it's also affecting others, it will surely be addressed in due time.
Now, the obvious low-hanging fruit here is to clone this sucker to help the unwashed get the hyphen/ndash right in hyphenated names. Good grief, talk about low hanging. Does the link target a redirect with the hyphen leading to the same thing with the ndash? Doh! You probably want to reverse that, and mutatis mutandis in the (rare) opposite case.
The DAB popup already codes 90% of the framework for adding this extra test. This ndash thing might seem like small potatoes, but it's not as small as it first appears. Your web form spelling checker probably treats the hyphenated case as a single lexeme, and the ndash case as two separate lexemes. So it's not just presentation. Your GUI is trying to help you here. Help it help you.
The problem with proper nouns is that we've placed community out in front of eventual sanity. Of course, this is how it had to be. Eventual sanity, as I see this, is our growing interdependence with Wikidata.
Long ago there was this entirely sane wish to see the web develop in the direction of the semantic web. Perhaps premature, but entirely sane.
But Big Tech decided that semantic was their secret internal sauce, and that the casual unwashed user can't handle the truth, or that it was cheaper to hire at scale if you were lax on fastidiousness, or some linear combination of the above, and we're actually further from semantic than 10 years ago.
Has anyone else noticed that God's original primary metadata, date of first publication, is eroding on social media faster than a glacier parasailing in a jet stream on Venus? Reddit commonly dates posts to "1 year ago" with no hover control I've found to resolve this more accurately. Who was first to the party is entirely central to academic priority disputes. It's almost as important in journalism, to sense who was moving the rock and who was rereporting the rock. Academia still bothers to teach students not to plagiarize. Plagiarism isn't yet a kissing cousin of free-speech absolutism (wait, it could happen).
This is not small potatoes in the current discussion. Wikipedia is old school on date of origin. Very old school. Not only can you get the UTC imprint for page creation, but for every fiddle subsequently.
Wikipedia is increasingly becoming the last remaining citadel of the original way of doing things. There's no real differentiation between the products offered by Big Tech. But there is real differentiation between Wikipedia and all the rest.
I saw this evolution in software play out over 50 years. The C language became unpopular. Sort of. C built the entire Internet. That's a well known story. But you can shoot yourself in the foot with C. That's also an old story. All of the popular modern languages try to be less like C in one way or another. On reputation, Rust is maybe the only one that is managing to be less like C without throwing the good parts under the bus. This is all fine. Some people have the right psychology to code in a demanding language like C. Many don't. But here's the irony. Half the time, the language determined to replace C is written in C. C hasn't disappeared at all. It's merely been driven somewhat more underground, where the battles are fought by specialists. If the language determined to replace C is halfway succeeding, it's often only because C did such a good job making that language fast enough to even try to use. Something in the food chain needs to do a good job of expediting the bare metal.
If this hadn't just popped up, I would perhaps polish this metaphor better. But roughly, there's a part of me that sees Wikipedia as becoming a hold-out culture for the "bare metal" of what we originally hoped to see evolve as the semantic web. A good entry point to the wish and theory is Jonathan Zittrain's The Future of the Internet and How to Stop It (2008). Tim Wu does a good job of framing this within larger historical trends. I like his older book, The Master Switch: The Rise and Fall of Information Empires (2010).
The main analytic concept from Zittrain is generativity. This means that the value of every system is measured by it's ability to support the synthesis of new systems. It means that the only culture worth having is remix culture. Big Tech does not see it this way. Wikipedia should. The obvious irony here: Big Tech is busy remixing Wikipedia here, there and everywhere. No doubt, ChatGPT used Wikipedia as one of its many training sources (and a very valuable source, at that). But I can't even add a line of JavaScript to fix my Google search results when they format the returned page with embedded HTML «br» elements that uselessly fritter away visual space on my 24" portrait monitor, by imposing far shorter line lengths than sensible, and this only because Firefox has decided to obey Google's protective box on the returned content (oh, how the once-free have fallen).
On Wikidata, the normativity issue with things like case and hyphens is mission central. Yes, on Wikipedia, culture comes first. Why adjudicate a fight you can't reasonably win? Well, because once you realize the end game here, you understand that we just kicking the can down the road. If our destiny is tied to being the last open, generative holdout, then Wikidata becomes our growth story into the future as a real alternative to the mirrored tunnel-vision of Big Tech. Basically, AOL wasn't wrong about the walled garden. Google and Facebook: hey, AOL, here's how you build a real walled garden. Not so small that you can see all the walls from everywhere all the time. No, so vast that many people never find the walls at all. But a vast walled-garden is finally still a walled garden if it's not fundamentally generative. Sorry, Google. It's just a mirage.
So here we are in 2022. Social media is busy eroding primary time stamps like a glacier parasailing in a jet stream on Venus. This does not bode well.
Meanwhile, we have culturally decided to avoid becoming normative on whether page topics are best handled as proper or improper, when both usages exist.
Quite often this isn't a problem, at least in the paper cut dimension. I go to the target page and scan rapidly for the first use not at the beginning of sentence (where sentence case obscures the treatment). You'd be surprised at how many screenfulls of text I sometimes have to wade through to find the first use of the page title somewhere other than the front of a sentence. There are particularly bad cases where the term is both at the same time, because a proper use sprung up using exactly the same words as the pre-existing non-proper use.
How long do I then ponder the target page to ferret that out? Ugh. What a waste of brain power.
This is the job for Captain Metadata. Do we have two different things, handled differently in their own realms? Or one thing, handled inconsistently across different discourse communities? I can't see Wikidata entering into healthy puberty without this issue being finally driven to ground.
So how about we not postpone the inevitable, at great paper-cut cost, and make a widget that suggests normative case treatment on the fly, the way we already do with DAB problems?
Proposed solution:
Extend Wikidata is small ways (if necessary) so that we can programmatically distinguish the various normative treatments.
Create an article page annotation to reflect consensus in whatever grey areas remain.
Clone the real time DAB popup to also offer this wisdom, as moderated by target page annotations, reflecting social consensus.
Who would benefit:
Fastidious people who care about generativity, and the survival of Wikipedia counterculture for the next 10,000 years.
More comments:
Sorry that's so off the cuff and a bit philosophical, but I lack the time to make this more focused. And this is my whole load of buckshot. I'm back to the races again on a 1000 other things.
@MaxEnt: Unfortunately it's required to trim down the proposal also because there will be translaters translating the proposals and we want to reduce the workload. Thanks! KSiebert (WMF) (talk) 12:02, 30 January 2023 (UTC)[reply]
So for wiki page visit statistics, you want to see which percentage of visits to a page is from another article, or from another foundation sibling wiki ? —TheDJ (talk • contribs) 23:39, 26 January 2023 (UTC)[reply]
Pinigng @RetroDancer: about the above question. Referral data is already available, but limited to articles receiving more than 10 referral points, or "observations". You can use toolforge:wikinav to visualize this data. It's also limited to a few select language Wikipedias, and I see your home wiki is nlwiki which is not supported :( If support was added for Dutch Wikipedia, would toolforge:wikinav meet your needs? MusikAnimal (WMF) (talk) 16:22, 30 January 2023 (UTC)[reply]
Problem: Although Wikipedia is not a mirror or a repository of links, images, or media files, editors still have many legitimate reasons to add pictures to Wikipedia pages. Even if it is three or four pictures, the reading experience on the mobile version is not good, and it often occupies several "pages" — Readers have to keep scrolling to find the text.
Proposed solution: Like Britannica[3], Provide buttons for readers who intend to read more images on near the photo.
Who would benefit: Reader using mobile phone.
More comments: I haven't figured out how to implement it yet :(. It may be to modify the display effect of <gallery> on small-screen devices.
@Ghren: Thank you for your proposal. Isn't Media Viewer providing the same functionality that you are describing in your proposed solution? If I'm misunderstanding the problem, or if I'm missing something please let me know. Otherwise I would like to move forward with archiving this proposal. DMaza (WMF) (talk) 20:32, 3 February 2023 (UTC)[reply]
Pinging @Ghren once more. If we don't hear back by some time tomorrow, we may have to archive this proposal. Note also the comment below about using <gallery mode="slideshow"> as a possible solution. Thanks, MusikAnimal (WMF) (talk) 18:42, 8 February 2023 (UTC)[reply]
Problem: We've got a serious problem on Wikipedia as a whole. When people try to search for terms in Spanish online, a surprising percentage of the time the response that Google comes up with is actually from the Asturian Wikipedia. Screenshot of Google results in Spanish What's the issue? Well, Asturian is spoken by less than a million people. Certainly, it's a real language and deserves a real Wikipedia, and its users work hard and should be praised. But it is a useful resource for, at most, less than a million people.
Spanish, however, is spoken by half a billion people as a native language. When someone searches for a term like "donde viven las cobras", the language that they are overwhelmingly likely to expect is Spanish, not Asturian.
Yet Google consistently returns Asturian Wikipedia over the Spanish Wikipedia for Google searches, at least those emanating from the United States (the second-biggest Spanish speaking country there is!). I personally find that about 30% of my Spanish google searches lead to the Asturian Wikipedia being the one chosen by Google as the top Wiki link, and this then blocks the Spanish one from appearing at all.
This is not just a Google issue, actually. Bing does the same!
Proposed solution: Intentionally reduce the SEO/web presence of the Asturian Wikipedia, making it less likely to pop up.
Who would benefit: All Spanish speakers worldwide, who would be far more likely to encounter the language they are looking for. (It's worth noting that even most Asturian speakers also speak Spanish.) It also provides some form of social justice, since Spanish speakers are much more likely to be of a lower economic status than Asturian speakers.
More comments: Frequently, links to the Spanish Wikipedia won't even come up when Spanish terms are searched in the USA (which has more Spanish speakers than any other country in the world bar one); instead, you'll get a link to the Asturian wiki and then the English one, even when you're searching in Spanish.
Hello there @Red Slash, we met as a team to discuss this proposal and we had a few questions-- do you know of any other users experiencing this? If so, can you link us to those conversations so that we can understand this? We tried to recreate the search you mentioned in your problem description but were unable to see any Asturian results. If the wish is about changing the way that an external engine structures the data that would be out of scope for us. This Robots.txt file may be of interest to you as it is the Spanish Wikipedia's disallow list which tells SEOs what to omit from searches. Thanks in advance NRodriguez (WMF) (talk) 20:55, 31 January 2023 (UTC)[reply]
Hello, sorry for my lack of response--I don't normally check on meta. I have had this issue continuously for a couple of years, but I haven't had any conversations with anyone else.
I'm wondering if we can enforce a disallow list throughout the Asturian Wikipedia to reduce its web presence for any article that shares a title with the Spanish article for the same thing. Red Slash (talk) 19:05, 17 February 2023 (UTC)[reply]
Problem: When undoing vandalism or good intentioned, but badly executed edits to a page, an issue often occurs wherein an edit is reverted, and then an editor returns to the Recent Changes page to examine other bad faith changes, or goes on to other tasks, and the edit is made again by the same editor, or, in some cases, the same edit is made by a different editor working in coalition with the bad actor. The current solution is to add the page to your watchlist, but this will notify you of any edit. If you frequently edit, or do large amounts of work on QA'ing new edits, this can rapidly reduce the helpfulness of alerts, as it's creates notification fatigue.
Proposed solution: Integrate Contribution Quality and User Intent predictions into the watch list setup process, so that an editor can choose to only receive notifications of page changes that are likely to be bad faith and/or low quality.
Who would benefit: Contributors who assist in monitoring for low quality and bad faith edits
@KSiebert (WMF): Hi :) There are ways in AF to catch multiple edits to the same page, but it's not quite the same as the watchlist. It would require non-trivial manual intervention to add/remove pages, something that not everyone is able to do. --Daimona Eaytoy (talk) 18:59, 2 February 2023 (UTC)[reply]
@Foxtrot620: It would seem having multiple watchlists could solve this (note phab:T3492 was added to the proposal), since mw:ORES is already integrated into the watchlist. You just need a separate one for pages you're patrolling. Is that correct? See also Community Wishlist Survey 2021/Watchlists/Multiple watchlists, which we came very close to working on. I think if you reword your proposal to encapsulate other use-cases, as it would be with multiple watchlists, you could improve the chances of this propsoal doing well in voting. Let us know what you think! Regards, MusikAnimal (WMF) (talk) 20:43, 2 February 2023 (UTC)[reply]
Problem: Currently 'make PDF' produces a printer-friendly, streamlined file. But when later attempting to convert to ePub or MOBI (Amazon ebook reader), then a blank page results. This is because the text is rendered as graphic image, I suppose.
Proposed solution: Offer "plain text" alternative to Printer Friendly pdf.
Who would benefit: Readers who have trouble with computer or phone screens who wish to engage longer articles on eInk or other device.
@Gpwitteveen: Hi, the current PDF option available to editors from the sidebar in the "Print/Export"-section and labeled as "Download as PDF" makes use of Chrome's PDF functionality, which should be completely text compatible and will not generate images. I'm not sure what kind of tools you are using to convert to epub or mobi, but they should work together normally. Can you provide some more details perhaps ? —TheDJ (talk • contribs) 23:15, 29 January 2023 (UTC)[reply]
What this functionality however does not provide is a Table of Contents. Unfortunately the ticket for that has been open with Google Chrome for quite some years already. —TheDJ (talk • contribs) 23:17, 29 January 2023 (UTC)[reply]
Problem: The following text is not directly a problem but rather a challenge to work faster with templates and data from Wikidata and to be able to change them. Let me illustrate a situation that is likely to occur in many wikis. An uninitiated editor edits a text, sees an error in an infobox, for example, and tries to correct it. At the moment he has two possibilities, editing via VisuelEditor, but this then mostly only locally in the wiki and the source code editor, there is no link to Wikidata, but also only local wiki. If an infobox is equipped with a link to Wikidata (which would be technically possible), the uninitiated editor is redirected to the Wikidata website and must then first experience a completely different world of text and data, which is usually only English to begin with. (Sorry, that is already too much for many uninitiated editors). Then years ago there was a project called "Wikidata Bridges", but it seems to have fallen asleep and the source code in the Catalan wiki has also been deconstructed.
Proposed solution: The solution would be simple lines of code that are understandable for everyone. 1) The first line of code would have to show a button that I use to connect the data from a field in an infobox or template to a statement in Wikidata. And this in the simplest way possible. (Example: {WikidataStatement|P17|State|localValue} and integrate this into the source code of the infobox or template). 2) As a second line of code, the "action=edit" must then be done and, if possible, in the respective local wiki, i.e. without physically jumping to Wikidata. 3) Nice to have: Maintenance categories, which indicate whether a value comes from Wikidata or the local wiki and, if necessary, looks to see if the information is the same or different.
Who would benefit: All processors, as they would no longer jump in the projects. All data collectors for Wikidata, since the maintenance would be stored directly there. All small wikis, since the information could be displayed directly. Commons Wikidata infobox, since it already lives on good data and so can only get better. SO: ALL
More comments: For queries feel free to send me a ping
This could use a better title ("editing Wikidata information in infobox templates without leaving the site"?). Maybe Wikidata Bridge could just be rolled out - IIUC it's already deployed to some small Wikipedias which volunteered so it might not be that far from done. --Tgr (talk) 03:02, 5 February 2023 (UTC)[reply]
Um den Titel des Proposals zu ändern, muss man die Seite verschieben, dazu geht man oben in das "Mehr/More" Drop Down und klickt of "verschieben/move." Die Url wird dann der Titel des Proposals. KSiebert (WMF) (talk) 18:26, 26 January 2023 (UTC)[reply]
Add a LUA function to check whether given page is in given cat
Problem: No way to check from a template or module whether a certain page is in a certain category. This is needed for some templates on wiktionary.
Proposed solution: Add a LUA function to check whether given page is in given category. It will take two strings (name of category, name of page), and return a boolean revealing whether the page is in there, irrespective whether the category page is created (ie blue) or not (ie red)
Who would benefit: Template and module contributors on wiktionary and probably even other wikis, consequently all users.
More comments: There is a hacky extension for exactly this purpose, but it is not enabled on any WMF wiki. This is a trivial task, so a native implementation would be way simpler than bothering with another extension, and is thus preferable.
When such a Lua method would reference a different page, that would mean the current page would have to be updated whenever the referenced page is edited in such a way that changes its categorization. That's a kind of change tracking we are not doing currently. When the Lua method would reference the current page, it would require an extra parser pass since categories can be added later on in the page source. I doubt either of those are feasible changes. --Tgr (talk) 19:06, 6 February 2023 (UTC)[reply]
Да ли може да се имплементирају домине и да се тако сложи текст на викиречнику. Предлог је да се узме ћирилица или било које писмо и да се направе речи од једноставних слагалица. на пример реч реч се може направити од ре еч, дакле две домине и то [р:е] и [е:ч] тако да и даље фунционише систем. Настављајући тако треба урадити 900 комада парова ако један језик има 30 слова. За друге језике исто то урадити и слагати слагалицу. Када се направи стабло лако се прави и макро језик тако да једна реч постаје једна велика домина која и даље наставља низ. постоји само један два и три. дакле улаз кутија и излаз. једна реч или једна домина улази у кутију и даље излази из кутије. празан лист је једна синтагма а друга синтагма је лист папира. тако да добијамо просту реченицу празан лист папира или на домино начин слажемо пр ра аз за ан нл ли ис ст. а следећа домина је лист па ап пи ир ра.
И тако имамо целу википедију у ланцу или блоку. 12 23 34 45 је реч од пет слова 12345.
12345 is 1234 and 2345, 1234 is 123 and 234, 2345 is 234 and 345. and so on. Piramyd. Tree. abcde is abcd and bcde. All words is on this principle make on any language. one two three is one two, and two three, repeat letters in the midle word. [a:b] + [b:c] is [a:b:b:c] become [a:b:c] is abc. and so on [ab:bc] is [abc]. [abc:bcd] is [abcd] Asinis632 (talk) 10:34, 8 February 2023 (UTC)[reply]
Problem: If you make more than one change to a Wikidata item (e.g., language labels, descriptions, or aliases), each change will be saved as a separate edit.
Proposed solution: All the changes should be saved in a single edit with something like "Multiple changes" or "Changed labels (or descriptions or aliases) for n languages" in the edit summary.
@GeoffreyT2000: Thank you for submitting your proposal! Can you tell us a bit more about why separate saves are a problem? How would it help to have everything saved (language labels, descriptions, or aliases) as a a single edit? HMonroy (WMF) (talk) 01:48, 8 February 2023 (UTC)[reply]
Comment from the Wikidata dev team side: Combining more edits for labels, descriptions, aliases into one is already happening in the new termbox we have on the mobile site for Wikidata. This new termbox is not yet available on the desktop site but we plan to make that happen. The exact timeline is not clear at this point. The ticket for the next step for making the mobile termbox available on desktop is phab:T261488. --Lydia Pintscher (WMDE) (talk) 20:42, 9 February 2023 (UTC)[reply]
Does not require engineering resources
Comment As mentioned above, something is not always better than nothing. I do not believe a person should translate a language they are not familiar with. Wracking (talk) 06:32, 30 January 2023 (UTC)
