Good ideas should not get lost in the Archive. In 2022, the Community Tech Team committed to showing the larger ideas to the Wikimedia Foundation leadership so that they may be aware of them during annual planning. Leadership, as well as other Wikimedia Foundation Product department teams will be made aware about these larger asks.
Can participants vote on these larger suggestions wishes?
During the voting phase, participants are welcome to add their "Support" on these wishes, but please note that regardless of popularity, there is no guarantee these proposals will be implemented. Supporting the idea helps communicate its urgency.
Problem: The WMF's funding is larger than ever, reaching obscene amounts, and none of that seems to make its way into community support / addressing technical requests. This proposal is simple. Allocate at least 1% of the WMF warchest/yearly budget to the Community Tech team. In 2019–2020, the WMF raised $130M, 1% of that is $1.3M. This is small potatoes for the WMF, but would ACTUALLY FOR ONCE yield tangible impacts on the features the community actually want, rather than on... whatever it is the WMF is spending that money on.
Proposed solution: Allocate at least 1% of the WMF yearly budget to the Community Tech team. Hire people. Buy new servers for toolserver. Whatever else needs to be done.
Who would benefit: All the community and volunteers, who would finally get the technical support they've been craving for years.
So the proposal is to allocate 1.3 M$ for this survey. What is the current expenditure? How is the number 1% arrived at? Assuming 1.3 M$ is more than currently spent on the survey, what will be added with the larger investment. Thx, PeterEasthope (talk) 02:16, 11 January 2022 (UTC)[reply]
I don't know what the current budget is exactly, but the Community Tech team is apparently 12 people, whom I doubt are assigned full time on this. If we ballpark an average salary of $30/hour, that's roughly $62,500 per full time coder per year, or ballpark $750,000. $1.3M would get us roughly 20 full time coders at that rate. So maybe the proposal should be increase the Community Tech team to 20 full time coders that are specifically assign to deal with community requests. The 1% is symbolic. Headbomb (talk) 02:50, 11 January 2022 (UTC)[reply]
Obviously it’s not as simple as $1.3m equating to 20 F/T employees, there’s other overheads & expenses involved aside from salary. It’d definitely be good to see exactly how much is attributed to the CMTT though to weigh it up. Jcshy (talk) 08:46, 11 January 2022 (UTC)[reply]
Yes, there's overhead, but it's a ballpark figure. Point if you have $130M annual income, more should be spent on things that aren't PR and feel good initiatives. Headbomb (talk) 10:26, 11 January 2022 (UTC)[reply]
I was actually considering making a proposal like this myself (I did not think about 1% specifically though, and I don't know if it is an adequate number. The point is that the team has to be bigger in several kinds of resources, perhaps at cost of teams that are not working towards direct community requests). --Base (talk) 10:03, 11 January 2022 (UTC)[reply]
Could this be formulated more diplomatically? I think it's the most important proposal out here, but starting with the word cancer is not the best strategy to get overwhelming support. 1% is quite modest, if you compare this with the back-of-the-envolope estimate of current spending. Would you consider adding an additional medium-to-long term goal of say 2.5%? Femke (talk) 10:44, 11 January 2022 (UTC)[reply]
+1. Remove the aggressive "cancer", and instead state what the current budgets numbers are for that team, and name their responsabilities or give a link towards those details. How much less than 1% is it? This proposal is basically a signal from the online community to WMF, that transparency/oversight is wanted over what happens to our donations. --Enyavar (talk) 12:13, 11 January 2022 (UTC)[reply]
+1 on the phrasing change, I can handle being tactful if it makes it more likely to get those who disagree onboard, and +1 on bumping the numbers - let's ask for 2%. Two helpful numbers to include would be the amount spent on knowledge equity and the per/year salary of the new CEO (which, for clarity's sake, I don't think is unreasonable, just a good mark of how small the community tech budget is) Nosebagbear (talk) 12:33, 11 January 2022 (UTC)[reply]
Maybe it could be changed to something like "from what has been described as cancer-like". I'd also like to note that just increasing spending by itself never helped anything:
the money also has to be actually useful and it should be spent well and efficiently. All of this could tie in with my proposal below to add a banner at the top of all software-development Wikipedia articles to engage developers which would link to a page/system to organize, streamline and facilitate the development such as via selected tutorials&tasks, making it easier to set the development environment up, badges and rankinglists.
-1 on the proposed phrasing changes so far, that term is well-known and I immediately knew the page it was linked to.
I think we should strive to facilitate maximum volunteer development (some of that could for example turn into payed development over time) and maximum usefulness of both payed and volunteer development (such as focusing mainly on high-priority tasks of community wishlist proposals and phabricator tasks that e.g. decrease running costs, are relatively quick to implement, got much support or would save much editors' time).
An excellent suggestion. We may want to work on the detail but I'd support any of the wordings so far. An organisation as rich as the WMF should not have a resource bottleneck on the thing it was actually created to do. Certes (talk) 14:38, 11 January 2022 (UTC)[reply]
$30/hour is significantly lower than it should be given the higher than US-average number of staff in the Bay area. It also doesn't factor in the additional costs. I know we are going "you can give more than the 1%", but I reckon they're probably already spending about 0.9% on the Team. Nosebagbear (talk) 15:20, 12 January 2022 (UTC)[reply]
I don't think there is a shot in hell of the Wishlist Survey determining WMF staffing or budgets. Not that it's a bad idea for more full-time help. Just saying. -- GreenC (talk) 19:23, 12 January 2022 (UTC)[reply]
Not determining perhaps, I would see it more like a petition that can go far to mend the relationship between the community and the WMF. Femke (talk) 20:01, 12 January 2022 (UTC)[reply]
FWIW, the budget allocated for "Platform Evolution" (defined as "to provide technical systems to support equitable, global growth such as through the addition of a caching center that serves Africa and the Middle East, as well as investing in the technical future of our projects") was increased from US$2.4 million to US$7.9 million in the 2021-2022 WMF Annual Plan. RamzyM (talk) 02:15, 14 January 2022 (UTC)[reply]
(1) This is out of scope for the Community Tech Team so this is not the right forum. (2) It's also not in the right ballpark. Even at the middle of San Francisco market rates, the annual total cash comp of this team with taxes and benefits would already be well over $1.3M. czar19:07, 14 January 2022 (UTC)[reply]
We will not get it, but we should keep asking, to make it clear to the WMF what the community thinks their priorities should be. The amunt specified should be increased, as Czar and others have pointed out--Using Nosebagbear's estimate, and realizing it will take time to increase capacity, we should ask for a doubling of between $2 and $3 million this year, increasing as possible in the future. The bottleneck is managerial priorities, not financial unavailability. DGG (talk) 21:22, 15 January 2022 (UTC) .[reply]
I've made an alternative proposal on talk, asking for a doubling, and in more diplomatic terms. The goal of this is to convince the WMF, and I think this type of wording will give us a larger chance of success. Femke (talk) 11:47, 16 January 2022 (UTC)[reply]
Agree in principle. I'll echo what some others have said: the framing of the linked essay is antagonistic to the point of being self-defeating. That's not to say it doesn't have a point in there, but if the goal is to be taken seriously, link somewhere else. There's no shortage of "WMF has a ton of money" links. But yeah, I asked about how to get funding increased at a Community Tech Q&A somewhat recently, and don't recall that I got a clear answer (apologies to those who responded if I'm misremembering). I think perhaps this is something we'll need the Movement Charter folks to throw their weight behind (however much that weight is). It's a clear step the foundation could take which would address the widespread belief that not enough of the budget goes to directly support the community. — Rhododendritestalk \\ 15:14, 16 January 2022 (UTC)[reply]
We absolutely do need much more funding directed at the technical side of the project. Currently the developers are clearly overworked; a lot of the early decisions have proven to be ineffective or simply bad (see our "amazing" parser, for example). Now we are also facing an increasing number of security threats that, again, cannot be eliminated simply because of how the project was built. This is a major tech issue and it is my wish to get more tech workpower so I believe that this submission should stay in the Community Wishlist. Le Loy04:07, 18 January 2022 (UTC)[reply]
The money are not everything. We have the money and job offers. But what are the problems? The error in Wikimedia Mowement and WMF. I think:
The normal user don't know about the news in Wikimedia Movement.
The normal user don't know about something more about the news on him local wiki, universities, about metawiki, WMF and about the jobs of WMF.
Wikimedia Movement and WMF only to wait, wait and wait.
I do not read anything about events in the Slovak media in Wikimedia movement. Nothing about job offers.
None The day of developers.
No promotion in SWAN and him entities.
It is the year 2022, none the year 2030. We don't have the Global Council.
Nobody is looking for / addressing talents.
Money-results: where is the report for the past year? If a person sees that it is useful, he makes an interesting contribution, wants to help or join.
IT people are not much.
Job offers:
None global content search.
If I am interested in projects and not programming languages?
What is the labor price?
None special contact / e-mail.
WMF presentation of works is totally like just an institution.
Why should I work for WMF? WMF is one of the other organizations why I should work.
Nobody investing in talent people.
Who needs a detailed knowledge of Wikidata or other languages? In him normal life doesn't need know very detailed. He doesn't generate any complex analyses.
Is working for WMF very special? Or can I use knowledge elsewhere?
International work can be discouraging.
Tech/News – it's Tech news (People can create some small context), or the report with the technical news (Very formal, narrow shot)?
Support especially if it's combined with the proposed banner for more volunteer development of MediaWiki. I'd support substantially more than 1% of funds (it seems that was a symbolic figure anyway). Prototyperspective (talk) 22:19, 28 January 2022 (UTC)[reply]
Support the spirit of devoting substantially more resources to community support, although I'd like to see more financials on the current situation to understand exactly what 1% would mean. {{u|Sdkb}}talk03:57, 29 January 2022 (UTC)[reply]
Support The fact the WMF management aren't investing more into technical and community projects and requests is infuriating especially given how much money there is behind them Ed6767 (talk) 15:39, 29 January 2022 (UTC)[reply]
Support More money to tech teams is a great idea anywhere. I like WMF in all aspects and I have never been concerned with how donations are managed but I do not deny that every good investment proposal related to this subject is beneficial (benign) for everyone. From here in Brazil, without going into the merits of good financial management or not, I agree! Nishimoto, Gilberto Kiyoshi (talk) 06:58, 31 January 2022 (UTC)[reply]
Support. The Community Tech team was created to address serious problems with Foundation's software process and priorities, but it shouldn't exist at all. The Foundation's core job is to maintain and improve our platform, and the Foundation as a whole should be willing or even eager to collaborate with the community in understanding how to do that. If we can't fix that fundamental problem, increasing Community Tech funding is at least constructive. Community Tech was clearly given insufficient resources to handle even the token mission that was promised for it. Alsee (talk) 23:40, 31 January 2022 (UTC)[reply]
Oppose On principle, it is a really bad idea to hard-code funding allocations. Creates laziness and bureaucracy, and once you have created interests hanging from (what now would be a 1%), these become nigh impossible to revert, even after there is no longer need for whatever was mandated in the very first place. Opposed on principle. XavierItzm (talk) 20:19, 1 February 2022 (UTC)[reply]
Support Agreed. All open source projects have paid developers, and with the funding that WP has at its disposal, adding (more?) paid developers to the staff to accomplish some of the work that volunteers can't/won't do, is needed. Hires an editor (talk) 00:26, 2 February 2022 (UTC)[reply]
Support Financial support for qualified Etymology verifiers and the Wiki Bots as well: in other words; for all that have [thank] after the heading of their edits for the public to thank if they wish. A number of etymology edits are still worrying, as particularly in the diversely semantic proposed links between Proto-Germanic and Proto-Indo-European, as in the cases of the origins of CLOTH and WOOD, et cetera. Werdna Yrneh Yarg (talk) 14:11, 2 February 2022 (UTC)[reply]
Support in spirit, even though this is outside the remit of this teams' survey. I do think we are heavily underinvesting in bugfixing and basic quality of the software for the (non-reader) communities and that we should focus much more on their day to day experience. —TheDJ (talk • contribs) 09:08, 4 February 2022 (UTC)[reply]
Support I've seen a small amount of negative comments on social media during annual funding campaigns, specifically about WMF. This, combined with PR/transparency, can make a huge impact, I think, and encourage more people to contribute (and I would imagine, to apply for jobs!). paul2520 (talk) 17:02, 8 February 2022 (UTC)[reply]
Support As Wikipedia and other Wikimedia projects are growing and getting more and more recognition, we need to be able to protect them from big bugs, hacking, etc. So, yes, more money into this makes sense.--Eunostos (talk) 07:04, 9 February 2022 (UTC)[reply]
Support Our donators invariably want to "Keep Wikipedia Running". As the content is volunteer driven, that translates in my eyes to improving the technology it runs on and making it easier to run. WormTT13:54, 11 February 2022 (UTC)[reply]
Support Maybe this way CommTech can finally deliver on stuff they are obligated (for the lack of better word) to take each year. [With no hard feelings to CommTech people, they are awesome and deserve more funding and more experienced colleagues.] stjn[ru]17:47, 11 February 2022 (UTC)[reply]
50 wishes
B This proposal is a Larger suggestion. There is no guarantee this proposal will be implemented. Supporting the idea helps communicate its urgency.
Problem: The wishlist system creates scarcity, making volunteers compete for solution to bugs that should be working without volunteer's need to ask for. Each year, only the 10 most voted are evaluated and, some of them, are declined despite the popular vote. This creates more frustration. Even those that are not declined after the vote, may be forgotten or even not done: 2021 1/10 done, 2020 2/5 done, 2019 4/10 done. In the last three years, 25 proposals were made, and only 7 of those are done. Most of the projects proposed here, discussed and voted by volunteers, investing [hundreds of] hours of volunteer time, are declined, postponed or never done. Only a minority (less than a third) of the projects may be done, and some of them are even proposed to be voted... the next year. This creates even more frustration. Why should we be here proposing or discussing something that we know won't be ever done?
On the other side, we find that the Wikimedia Foundation has funds and budget. The WMF is in good financial shape, but delivers a really scarce part of their budget to solve serious infrastructure issues that can put all our other efforts at risk.
Finally, most of the things that are asked here are not even wishes... but only asking for things to work, even things that were working but broke due to some change made by the WMF. Solving basic infrastructure issues shouldn't be something we ask for in [a scarce handful of] wishes, this should be solved by default, without users and volunteers noting that things are broken.
Proposed solution: Just implement the first 50 wishes [each year]. That would make thinks work.
Who would benefit: All the community and volunteers. All the readers, who are reading us in obsolete ways. All the free software environment, because we create more free resources.
Wait... I thought all suggestions would be voted on "Support" or "Reject", and the Support's would be then be tried to tackle. Only 10 get selected per year?? --Enyavar (talk) 12:17, 11 January 2022 (UTC)[reply]
I mean sure.. but realistically this is like asking the genie, as one of your 3 wishes, to give you 50 wishes. Sounds a bit unrealistic. I'd prefer more concrete proposals, like the 'x%' one on this page. —TheDJ (talk • contribs) 13:37, 11 January 2022 (UTC)[reply]
I fully support the description of frustration and desperation this process produced. I was one of the most motivated promoter for Wiktionary community and our proposals increased year after year (in quantity and votes) to finally have one proposal that reached #5 in 2020 (the year dedicated to undersupported projects) but it was finally not done neither. So, I will just copy-past this proposal and not do any publicity for the process anymore. This is just a loss of time for any wikimedian from a small community. I know the Community Tech Team is really well informed of this issue and willing to improve the situation. Thanks a lot for all the job you do, really. I am not judging any decision you made about your priorities, you did what you can do, but it is not what is needed. I think this discussion about funding more people to challenge more issues is fundamental now, but it is also a choice of organization and I think more teams are needed to have product managers closer to the communities, and teams dedicated to each project rather than only team for transversal issues that do not adapt properly the new features to small communities. Noé (talk) 11:10, 12 January 2022 (UTC)[reply]
The wishlist process to date has been treated as a way of 'satisfying a few popular community needs', something nice to have on the fringes of development, rather than 'listening to the most active users and community developers to help prioritize where to tune / generalize / fix systems and pay down technical debt'. The top proposals may be a better source for the latter than the former. [The historical list of most-popular wishes covers a range of things, and is not just "most popular quality of life improvements" :) ]
Energy spent ensuring that wishes can be resolved effectively at the scale of a few dozen a year would likely be more impactful than many other current initiatives. Some of the wish-granting effort seems to go into overhead that might scale nicely if this were part of a thorough plan for refactoring codebases and related architecture, and the wishes simply helped determine which areas were tackled first. –SJtalk23:30, 23 January 2022 (UTC)[reply]
In the future, it would be fine to count opposes as well as the supports. We should count based on the support and the support/S+O rate. Thingofme (talk) 14:40, 6 February 2022 (UTC)[reply]
Voting
Oppose CommTech team are not genies and even for a genie in a bottle this would be cheating. That's not how software engineering works nor how humans can deliver value. I do understand the sentiment behind it but it's like wishing for bag of money falling out of sky. And no, we don't have money for wishes like this. Amir (talk) 18:34, 28 January 2022 (UTC)[reply]
Support Having a bigger pool of tasks to pick from makes sense. There are some wishes, that are relatively easy to implement, even though they don't make it to the top ten. Šedý (talk) 11:15, 29 January 2022 (UTC)[reply]
Support scrapping Community Tech and for the Foundation as a whole to improve partnership and respect with the community. On one hand that's such a simple and obvious thing, but on the other hand, after so many years, it feels like I'm wishing for the moon. Alsee (talk) 23:57, 31 January 2022 (UTC)[reply]
Support Unfortunately, it is a shame we are forced to vote for this kind of proposals to be heard and not feel that they play around with this us anymore in this process. The Wishlist has become somehow a fake genius that looks promising and that is not ready to accomplish its most basic tasks. Xavier Dengra(MESSAGES)23:38, 3 February 2022 (UTC)[reply]
Weak oppose Having just voted to support the 1% proposal above I think this would actually undermine anything that might accomplish. The 50 most popular might not necessarily be the highest and best fixes we need to do ... there might be small, obscure fixes that if made could make it much easier to fix others, or obviate entirely, the need for many more popular fixes. Or a popular proposal might require so much work as to make all the others go by the boards. Daniel Case (talk) 19:26, 7 February 2022 (UTC)[reply]
Support Some of the wishes on here are rather small and may be easy to implement, it would be nice if they didn’t clog up the bigger issues, but could still be fixed TheFrog001 (talk) 14:53, 10 February 2022 (UTC)[reply]
Support It's not easy to churn out 50 wishes worthy of implementation in yearly surveys. 20 is a more sensible number. Make it double. Don't set the bar too high. 4nn1l2 (talk) 13:32, 11 February 2022 (UTC)[reply]
Support Supporting this for the plain reason that the current system is a bit abhorrent. Fighting for scraps that do not get developed because even the team that is developing them is underfunded and understaffed is really weird and capitalistic in the worst ways. The ideal way to solve it would be to fund teams working on all deployed software, not just on some bits and pieces like VisualEditor, Vector etc. stjn[ru]17:53, 11 February 2022 (UTC)[reply]
Dark mode
B This proposal is a Larger suggestion. There is no guarantee this proposal will be implemented. Supporting the idea helps communicate its urgency.
More comments: This was ranked the #2 wish on 2019's Wishlist Survey. While there were internal planning conflicts, hopefully those have resolved in the last two years so that New Vector can get dark mode. The most popular websites, web browsers, and operating systems, offer built-in support for a dark/night mode without hacks or workarounds. This also contributes to site accessibility and user energy savings (on OLED screens).
Community Wishlist Survey/FAQ#Avoid proposals that were declined in the past has Dark Mode as the first example. Procedurally, this proposal should be archived, but I have a hunch too that things have changed in the past two years. People seem to really enjoy mw:Extension:DarkMode and w:Wikipedia:Dark mode (gadget), so the work is nearly done and the popularity among users more or less proven. It just needs some final refinements and being seen through WMF deployment. So instead of archiving, I'm going to move this to our "Larger suggestions" pile, which is a place to for the community to express their desires for the visibility of other product teams and the broader Foundation. Please continue the discussion there and place your votes when the voting phase starts. I do apologize that Community Tech will have to decline this though, as much as we don't want to! MusikAnimal (WMF) (talk) 23:47, 10 January 2022 (UTC)[reply]
@MusikAnimal (WMF), is there any indication that this still conflicts with mw:Desktop Improvements, or that any other team would take up the work? If not, and if it remains a top request two years later, why wouldn't it run in the Reading section for Community Tech consideration with other Reading proposals? If the team overlap conflict from two years ago still exists, so be it and the team can deny it, but isn't this worth checking as long as there is large, long-standing interest and no issue of technical infeasibility? Relegating this to "Larger suggestions" does not seem appropriate here. czar03:27, 15 January 2022 (UTC)[reply]
@Czar As I understand it, the solution of using the CSS invert filter wasn't approved. Additionally, our Varnish caching meant we couldn't offer the feature to logged out users. Then a different solution was presumably going to be part of Desktop Improvements, or at least things were going to change enough that we wouldn't want to attempt any other solutions because of potential conflicts. Obviously dark mode still isn't here, and I do not know for certain if it is still on the road map for Desktop Improvements (it doesn't appear to be). But either way, Community Tech's attempt at this was rejected. I personally don't really see a workable solution without using the CSS invert filter, in the absence of some other major changes that somehow would allow us to control parser output on desktop without stomping on any community-maintained designs, which would put it much too out of scope for our team, so even then it would still belong here under Larger suggestions. Sorry! I do believe this category will get a lot of attention during voting, if that means anything. The goal here is to give the WMF and broader movement an unfiltered window into the technical desires of the community. I hope this proposal gets the attention it deserves, because believe me when I say if we could have at any point deployed mw:Extension:DarkMode, we would have ;) MusikAnimal (WMF) (talk) 21:37, 15 January 2022 (UTC)[reply]
My historical concern with "dark mode" proposals was that it's tricky to style on-wiki content for a dark mode. If an official dark mode existed it could add one or more official CSS classes for use with TemplateStyles, making it easy to provide downstream support for a dark mode in templates and such, which sometimes make assumptions that backgrounds are light and text is dark. Having the support be official, rather than relying on ad-hoc gadgets and such, would make a big difference by providing infrastructure for us to build better content-side support for the feature. {{Nihiltres |talk |edits}}00:27, 11 January 2022 (UTC)[reply]
I agree. Wikipedians seems to be extremely against (if you look a the bug tracker) it which is a bit ridiculous. Lets just fix it. Almost every average user would enjoy it. Mrconter1 (talk) 06:29, 11 January 2022 (UTC)[reply]
I don't think that's a fair assumption @Mrconter1: - it didn't accidentally end up at the top of a previous wishlist because Wikipedians didn't like it, after all! And the usage numbers of the various dark mode CSS etc also suggest we'd like it. Lots of the bug trackers just indicates that making a dark mode that doesn't occasionally either cause significant problems or blind the editors wandering around the less travelled paths onsite is...difficult. Nosebagbear (talk) 14:04, 11 January 2022 (UTC)[reply]
Don't confuse 'against' with 'this is more complicated than ppl make it out to be'. Developers on Phabricator generally discuss the work that needs to be done, not the desire of the feature. —TheDJ (talk • contribs) 10:31, 12 January 2022 (UTC)[reply]
There is already some infrastructure for the mobile apps that provides dark, black, or even sepia modes. While it struggles with some custom inline css in the content, for the most part it works pretty well. Obviously, it is based on Minerva. So the real and more specific proposal/need here is Dark Mode for (improved) Vector and Minerva in the web browser. --GerakiTL13:07, 11 January 2022 (UTC)[reply]
As a frequent reader, but occasional editor, I really want dark mode and don't care if it doesn't work in edit mode. The majority of "content" sites/apps on the net are adopting dark mode for nighttime reading, wikipedia now stands out as an exception. I've installed the extension which mostly works, and am a little mystified why it wouldn't be a priority for wikipedia. Its by far the most obvious problem with WP as a reader.—The preceding unsigned comment was added by Aaron Lawrence (talk) 03:29, 13 January 2022 (UTC)[reply]
Yes, dark mode is important and Wikimedia is left behind. Leaving all of the technical limitations, we should have dark mode for dark reading at night. Thingofme (talk) 14:41, 6 February 2022 (UTC)[reply]
+1, this would definitely make the list of "most popular QoL improvements". It would reduce the amount of energy currently being wasted on developing + trying to maintain other gadgets and extensions, and as Nihil notes help others build better content-side support. –SJtalk23:35, 23 January 2022 (UTC)[reply]
It would also reduce the amount of electrical energy consumed by displays! Rich Farmbrough 21:26 29 January 2022 (UTC)
Where is the problem? Where is the problem to have the native dart mode? Dark mode is not extra new thing in world. WMF (owner of MediaWiki) have the money. Tools? We have the Less or another's, create some preprocessor. Missed people? WMF, You find the people found on the project or buy a solution from another company. Or, can create the comunity create the dark theme? Does the idea / solution open the door in the main stream? If yes, community, make a collection.
The ways exist, so, do we want to have that? If yes, so, stop me compliance and moan.
✍️ Dušan Kreheľ (talk) 19:09, 10 February 2022 (UTC)[reply]
I'm shocked this was ever turned down for "technical reasons." This is an accessibility issues. I already need sunglasses just to look at a computer monitor without getting a migraine, and this hack-designer propensity for turning websites into white slabs glowing with the glare of the sun just because Apple and Google rolled the style out everyone is insanity. Some of us need dark mode to see. Having to research it like a technical problem to find a work around is horrible blight to force on someone who your website is already giving eyestrain. Were you a government website in my country, I'd file a complain with the Human Rights Commission, because Wikipedia is a similarly important website which I am funding. And to be sure, I'd be much more likely to donate again if I need I could put it towards dark mode specifically. I read before that there were implementation details - I don't care. Better is not the enemy of perfect. The barest bones most general and generic CSS toggle would make a world of difference. I am unfortunately used to the possibility that my disability will confer a second-class experience, but I would kill for a second-class experience over inaccessibility.
--Seocwen (talk) 16:54, 31 December 2023 (UTC)[reply]
Just to continue this rant, let me explain the horrible process a disabled user might be facing as they go looking for dark mode.
- You've already had a terrible headache several days straight but still have research to do for work.
- You go looking for dark mode on the front page - this is Wikipedia, how could they not have an accessibility feature as simple and basic as dark mode?
- I have to go Googling about how to get Darkmode working.
- I find out that for God-knows what reason Wikipedia has no dark mode, and that a bunch of technical work arounds will be necessary.
- So, I have to go recover a years old account just so I can sign in to implement the "easiest" workaround,
- The easiest workaround requires me to navigate through a huge bloated settings interface.
- There's so many things on the page i'm looking for I need to control-f and search for dark mode.
- I click the box for dark mode and nothing happens.
- I save my setting and nothing happens. I go looking around some more.
- Finally, I find the word dark mode on User-related UI, which is unfamiliar since using an account is new.
- It works - thank god -
- But it only works on Wikipedia... Here on Meta.wikimedia.org, it's back to burning my eyes.
- All of this, I have to read an navigate while my eyes are on fire because I have no dark mode.
Conclusion: Quit pining for some-gold played Military procurement solution and at least for the time being roll out a total piece of shit dark mode that's at least better than being skull-fucked by your website's brightness. It might not be a priority for normal-sighted people, but for disabled people, it most certainly is. Seocwen (talk) 17:11, 31 December 2023 (UTC)[reply]
Support I use a browser add-on for most sites but feel obliged to edit Wikipedia as readers see it. It's hard on my eyes, especially after sunset. Certes (talk) 02:07, 29 January 2022 (UTC)[reply]
Support It would require a function that allows article editors to identify alternate image files for cases where one image is optimal on a white screen but a different image is better (or even necessary) on a dark screen. CdnMCG (talk) 05:27, 31 January 2022 (UTC)[reply]
Support Most dark mode gadgets I've tried are not great, a formal version would enable improvement over time. Personally, I propose modelling off Discord's Nosebagbear (talk) 12:04, 31 January 2022 (UTC)[reply]
Support This would also require adding supporting classes for templates (via TemplateStyles). — AfroThundr (u · t · c)13:40, 31 January 2022 (UTC)[reply]
Support Forcing readers to use black text on a white background is becoming increasingly anachronistic. Most major websites, mobile apps, operating systems, office applications etc. have a dark mode these days. Modest Genius (talk) 21:02, 31 January 2022 (UTC)[reply]
Support Dark mode is currently possible with browser plug-ins, but that's a very imperfect solution. As one example, the plug-in Dark Reader works,but table borders and certain images turn invisible. Fandom already beat us to this, so it's definitely possible. JDspeeder1 (talk) 09:08, 5 February 2022 (UTC)[reply]
Support "Easy" (says the person not contributing to the code) win that I think would generate a lot of positive attention. Especially if there was an intuitive way for users to enable even if not logged-in (like a lightbulb, toggle, etc.). paul2520 (talk) 17:05, 8 February 2022 (UTC)[reply]
Problem: To vote in a SecurePoll election, you need to be redirected to votewiki (vote.wikimedia.org). This leads to potential vulnerabilities (see phab:T298849) and it also requires the interface language of votewiki to be changed based on the language of the local wikis who are running an election there at each given time.
Proposed solution: Refactor the code of SecurePoll to properly use CentralAuth and SUL, so that users don't have to leave their local wiki at all to vote.
Who would benefit: Wikis that hold elections using SecurePoll (currently enwiki and fawiki, soon to include zhwiki and more).
More comments:
Phabricator tickets: phab:T298849 (it is private for security reasons)
No, more likely the privacy/security aspects of it. That's gonna make this a really big task. Also steers it outside of the expertise of the community tech team a bit I think as they would have to consult lots of other teams. —TheDJ (talk • contribs) 13:42, 11 January 2022 (UTC)[reply]
It seems to be a fix for earlier days without SUL, but now, as we have it, it seems better to host elections locally (unless there's CU concern). 1233 （T / C） 16:29, 19 January 2022 (UTC)[reply]
Problem: We're having these surveys every year but only a very small fraction gets implemented.
There's also a large backlog of code issues on phabricator, and many even very basic features haven't been implemented so far.
This is despite of the code issues not including many existing and potential proposals.
Often code issues, if implemented at all, take over 5 years from creation to implementation. There could be much more development.
Proposed solution: Add a banner asking developers to help with MediaWiki development.
The banner is only displayed at the top of all software-related articles (at least all software development related ones). Alternatively it could also be displayed on all pages.
Who would benefit: Wikipedia as a whole and all existing and potential sites using MediaWiki software.
More comments: It could be further improved by setting up e.g. a competition-like leaderboard of volunteer developers who helped the most on the page the banner links to. Maybe there could also be functionality to donate to teams/people who implement Wishlist proposals to fund their implementation. However, I think it would be best if the first time such a campaign is run, only volunteer development gets facilitated, especially because it may be difficult to design this in a way that's fair and well-functioning if that's possible at all (I think it could be fairly simple).
Engineering would be required to put the banner only on software development related pages. This could be done by using categories. It would also be required for things like rankinglists and badges. The badges could be rewarded for certain tasks like closing a difficult issue or a number of issues and would get certified. Users could then use these badges on their userpages and even outside of Wikipedia. Moreover, engineering could help ensure that people can get started with the development well and quickly and that efforts are streamlined in a way that ensures contributions are constructive. Further details and additional ways could be worked out later or get added to this proposal (via edits and comments).
It seems like at the talk page AyackOtourlyStryn and Sänger expressed discontempt with how Wishlists have been implemented so far.
Wikipedia runs on MediaWiki software as its core and most proposals here are about this software. It is this page or a similar page, that the page of the banner should link to or whose information the page should contain.
Note that many proposals are not yet code issues. For example, I have many proposals I never published so far because I'm still waiting for more important issues to get solved first (like a button on the Watchlist to see all changes since last visit per page which could save a lot of editors' time).
I also think that more of the WMF's financial resources should be dedicated to software development of the Wishlist proposals and phabricator tasks (this also got substantial support on reddit). However, this proposal here is "only" about the banner (and everything directly related to it on the landing page etc). I think that regardless of what's decided related to the use of funds and funding-mechanisms, we should strive to maximize volunteer MediaWiki-related development.
Note that visibility, feedback and being part of a campaign (roughly described), rather than an unfacilitated strive to help out by interested individuals, can substantially increase motivation. This could also be the idea behind #1lib1ref.
I don't think that such a campaign would draw substantial human resources (or time, expertise, effort) away from other important software development. In particular, away from open source software development/maintenance of important packages.
How many experienced developers would be reading the Wikipedia articles for those languages in question? Wouldn't just having a global banner be much more appropriate with a wider reach? Ed6767 (talk) 22:33, 10 January 2022 (UTC)[reply]
Proposals should require engineering work; this one doesn't really do so. The only somehow engineering-related part of the proposal is to identify "software-related Wikipedia articles", so the proposal could be reduced to "create software that automatically identifies software-related Wikipedia articles and provides a list of them for displaying banners"… I don't really see how this is an improvement to be made by the Tech Team. Mostly, the page you're looking for seems to be CentralNotice/Request. ToBeFree (talk) 19:09, 10 January 2022 (UTC)[reply]
Yes, it's that simple that it doesn't really require any engineering work of significance, so it's really just the decision(-making / willingness) of the WMF that causes this to not get implemented. However, it still requires a minor effort of engineering, which Xaosflux asked about above: how to identify said pages. Moreover, if a rankinglist and things like that are added these would also require engineering work. --Prototyperspective (talk) 20:31, 10 January 2022 (UTC)[reply]
You've listed this as something for "admins and patrollers" - is this something you'd only see showing for such groups - or is this something you want to target general readers of projects? — xaosfluxTalk19:10, 10 January 2022 (UTC)[reply]
@Prototyperspective, this has been archived but I was originally writing a comment regarding this proposal.I think your proposal and Reddit post is pretty inaccurate and outdated, and ignores so many points - you mention "intransparency" in the WMF despite literally everything being logged and your only citation being an opinion on a talk page? You mention the WMF is "unwilling to facilitate volunteer developers to help with the thousands of already-existing code issues", despite the fact the WMF provides Wikitech, Wikimedia Cloud Services, technology grants, hackathons, and so much more. You also said "basically nothing could be done about it", which is a very pessimistic view. I could go on, especially with your irrelevant raising of log4j and heartbleed. You have to remember too that there is a big difference as many MediaWiki features are implemented through extensions and gadgets - these are the things that often go unmaintained and become neglected - adding a feature to MediaWiki itself isn't necessarily as simple as you'd think.You also seemed to ignore that moving from Gerrit to GitLab is already planned and timelined? I just don't feel you've done the adequate amount of research required for a proposal like this. You do raise some good and well known issues however, and there are many more valid criticisms regarding the current developer situation that could be made, but you completely missed the point here with weak rationale. It is true that development is lacking and not many people know they can and/or want to contribute to MediaWiki development and how current resources and developer support isn't advertised or promoted as much as it should be. My advice is you should go back and rework your proposal and come up with a plan for how developers from outside the Wikimedia community would feel more welcomed and have more resources available to them, then submit it through the appropriate venues, rather than the community wishlist. Ed6767 (talk) 20:10, 10 January 2022 (UTC)[reply]
Provide proof of your claims (which are wrong). I removed the largely irrelevant mention of log4j etc. With this unwillingness I was referring to the blockade to add such a banner. I already knew and discussed the GitLab switch before making the post. Your points basically all misunderstood my points and aren't about the proposal. The Wishlist is a perfectly suitable place to propose this. I already read that page. I reworked the proposal to remove the log4j side note. --Prototyperspective (talk) 20:57, 10 January 2022 (UTC)[reply]
@Prototyperspective, I'm not a fan of your dismissive attitude, but sure:
> With this unwillingness I was referring to the blockade to add such a banner This was not clear, but if you have a solid proposal all you need is consensus through the appropriate venue, the community wishlist is for engineering proposals, the infrastructure for global notices is already in place. I was also responding to some of the points made in your Reddit post.I'm not saying I'm opposed to this, onboarding more developers from the wider public would be a great thing - however, I'm saying you need better planning and better rationale. Onboarding too many developers at once may create a massive influx that would need planning in place, not to mention the responsibilities that would be in place for security, reviewing and setting up each proposal and documenting it. Simply throwing as many developers as we can at the wall and seeing who sticks isn't the best strategy and would, in my opinion, make things even more disorganised. Ed6767 (talk) 22:13, 10 January 2022 (UTC)[reply]
I wanted to keep it short on purpose. (Other than that, it's not like I've never discussed related things before.)
The annual plan is what I linked to because it does not show exactly where the money goes. I mean I could be wrong but so far I can only find very large composite expenses for whole areas of expenses like Programmatic (and some other users have expressed similar concerns). Basically, the only main reason for why I didn't link to it directly but a Talk page is because it obviously gives the reader another impression.
The technology-related efforts are great and all and I wasn't saying there was nothing going on there at all, I mean one would reasonably expect there to be efforts. I was referring to the banner only and related facilitation of volunteer development like larger, more visible hackathons, rankinglists, badges, outreach, and so on. I just don't think the banner is an "only" – it would be the starting point of larger things, basically a requirement to get the development capacities and do whatever else you'd like to do to improve the Wikipedia software (including facilitating more development).
> but if you have a solid proposal all you need is consensus through the appropriate venue, the community wishlist is for engineering proposals, the infrastructure for global notices is already in place
This proposal is appropriate here in three ways: it fits the description "community wish/proposal" and "platform improvement", it's about Community Wishlists in a meta way, and engineering is required to make it work. The infrastructure for global notices already being in place makes it even easier to implement, making it more strange that it hasn't been done before. But that's not all the engineering that would go into this, especially depending on how well it's implemented (the better the more engineering would go into it...even though the survey isn't called "Community's Engineering Wishlist").
The linked reddit post was not meant to be a major point, it was just to show that externally there is considerable support for doing so – reddit is not the Wikipedia/Wikimedia community so it has not a significance as large as you may have thought I'm suggesting it to be.
> Onboarding too many developers at once may create a massive influx that would need planning in place, not to mention the responsibilities that would be in place for security, reviewing and setting up each proposal and documenting it.
See? These things would require engineering. However, it would be about implementing proposals, not about creating more proposals. Maybe I should also add more details about that (including streamlining and onboarding) beyond badges which would also require engineering.
Having such a large wall of text under "Discussion" is a problem though so maybe it should be wrapped in a collapsed template one can expand.
It seems that as I've critiqued your idea you've clarified and developed your idea, but in a contradictory way - and what I said is more than engineering, but would require policy, funding and planning. These are some great ideas to increase onboarding, and I think having a much larger hackathon event that is publicly advertised to an audience wider than the general community is a brilliant idea that should be developed, but there needs to be much more in depth planning as for a project as large as MediaWiki, it's not trivial. Not to mention some of your comments disregarding the WMFs software engineering team [1][2][3] and arguing with people on Phabricator seem, in my opinion, quite disrespectful towards their continued hard work, especially as a developer I have worked on and benefitted from their work and support, along with many others.Ignoring that we're swerving vastly off topic, I still don't think this is appropriate for the wishlist:
Overlaps with another team: see mediawikiwiki:Developer Advocacy (you may want to open a phab ticket with a more developed suggestion there for their consideration)
You still haven't proven that this needs engineering work (i.e. development of a new tool/tech/etc.) - the tech exists, policy page and program development is different and would require further discussion at a more appropriate venue
This isn't just one problem that needs solving, but rather something that should be developed into deeper proposals in a different venue - this is not what the community wishlist is for
Of course, it goes without saying that the quickest way to get what you want in FOSS is to aim to fix things yourself so that you can also contribute and help the community, and it may also help with giving your perspective for developing future proposals. Ed6767 (talk) 02:04, 11 January 2022 (UTC)[reply]
You said it didn't require engineering work. I certainly don't oppose related efforts of "policy, funding" (and planning) which you think are required for this.
I'm very grateful for the developers. I was saying there should be more development. And not even once were my concerns addressed in my arguments there even though I repeated them about 10 times, trying to make them ever clearer than before. I always remained respectful, not sure why you're suggesting I wasn't. Other than that, I think there ought to be certain humility when using donated money.
I don't think that "we're swerving vastly off topic" – you've done that by causing a large a wall of text beneath this proposal that's largely not about the proposal at all.
It's not about FOSS but about Wikipedia/Wikimedia and it's a very due platform improvement proposal which does require engineering (lots of it if you do it very well). --Prototyperspective (talk) 11:24, 11 January 2022 (UTC)[reply]
Support Sounds like a great idea to pique the interest of students, casual coders, and full-time SEs with free time. I'm very much in favor of anything that can be done to encourage open source contributions. paul2520 (talk) 17:11, 8 February 2022 (UTC)[reply]
> Pick one specific problem and describe it in detail
Here are two. No charge for the 2nd. =8~)
(1) Two links are presented to edit a page or section thereof. "edit source" allows editing the markup text which is translated to create the HTML of the page. "edit" allows visual editing.
"edit" is slow to load and restricts capabilities. "edit source" loads quickly and allows all editing. Visual editing is relatively recent. Before it was added there was only source editing.
(2) Multiple "skins" are offered. Consider this principle of the Web: the server presents content with minimal imposition of presentation; the client has as much freedom in presentation as feasible. Imposition of skins is unnecessary. Focus on content.
> Don't worry about finding the solution
Here are my proposed solutions. Again, no charge. =8~)
(1) Drop visual editing. Keep source editing.
(2) Drop the skins. Impose as little style as feasible. If you want to help readers with presentation, offer style sheets which a reader can use according to taste. Ref. https://support.mozilla.org/en-US/questions/1271227 =8~)
"Two links are presented to edit a page or section thereof. "edit source" allows editing the markup text which is translated to create the HTML of the page. "edit" allows visual editing." is a result of your preference/configuration. You can change that in your personal preference according to my understanding. C933103 (talk) 08:23, 17 January 2022 (UTC)[reply]
In Preferences I found the switch and shut off visual editing. The wording suggests it's temporary for beta. I'd rather it be permanent. Thx, ... PeterEasthope (talk) 05:17, 21 January 2022 (UTC)[reply]
The VisualEditor has been worked on for years. It was created to make it easier for users who are not used to working with wikimarkup to be able to edit a page with relative ease. It will definitely not be removed. If the "Edit" button is bothering you, you can simply remove it through a userscript. Xxmarijnw (talk) 18:54, 11 January 2022 (UTC)[reply]
Accidentally clicking the "edit" link for the visual editor results in a delay while editing is set up. =8~( If the visual editor is permanent, then the configuration switch to turn off the edit link should also be permanent.
Dismissing legitimate concerns as curmudgeonly will only discourage some capable and well meaning people from contributing. Look at what's happened with the Web. Many pages aiming to present simple information are severely burdened with JavaScript. Consequently a bus schedule which might be presented efficiently as a table in HTML5, is bogged with JavaScript. No problem for a contemporary iPhone or Android phone containing a JavaScript ASIC. Yes problem for reading the schedule with an old computer and Dillo. Try Dillo on a desktop machine. If possible an older generic machine. Immediately you'll notice how quickly Dillo opens compared to Firefox. Not a criticism of Firefox. Rather an illustration of the pervasive imposition of JavaScript. The endless push to more complex and resource consuming systems is a grave problem for the biosphere.
We don't have to play into the hands of mega-corporations. Of all people, Wikimedians should exercise principled autonomy and initiative. Regards, ... PeterEasthope (talk) 16:33, 27 January 2022 (UTC)[reply]
In Wikibooks, my default was "edit" and "edit source". In Preferences, I switched off "edit". Here I have only "edit" (= edit source). Apparently visual editing isn't available here.
This discussion is itself an example of why I advocate for simplicity. This morning I've spent at least an hour here which could have been spent on editing and writing. Exactly my concern. When a technology becomes established, focus shifts to embellishment with unnecessary complexity. Consequently some of the original value is lost. Illustrated by the Web as noted above. At some point people should recognize success and stop. Regards, ... PeterEasthope (talk) 18:26, 27 January 2022 (UTC)[reply]
Thanks for elaborating, Peter. Of course we should focus on simplicity, a minimum of JS bloat, and the like. It was your final comment about the "inescapable question" that struck me as unhelpful. The visual editor has increased the # of people I've successfully gotten to edit many times over, and was the most-requested feature by non-editors in the years leading up to it. –SJtalk03:24, 28 January 2022 (UTC)[reply]
'... most-requested feature by non-editors ...'
Fair enough but please leave a permanent option for visual vs. source editing preference. As mentioned, inadvertently choosing visual wastes time. Might be only 20 seconds but a distraction nevertheless and seconds add up. The principle of "user centered interface", familiar to Mac users, is significant. A user should be presented with only pertinent and significant information. If a user uses only one of the two edit interfaces, there is no need for two edit links. It's a matter of psychology. Less can be more.
'...comment about the "inescapable question"...'
Accountability may be embarrassing but is necessary where a cooperative effort is aimed to a result. Without accountability efforts go astray. A harsh reality.
┌─────────────────────────────────┘ After writing the preceding sentence I happened to the read the "Wikipedia has Cancer" essay by Guy Macon. Disturbingly congruent to my concerns. Any donor should be seriously concerned about the noted refusals for financial accounting. The scenario of bankrupcy and acquisition by a mega-corporation is gravely disturbing. Exactly the fate of Mountain Equipment Coop, started in Vancouver by a group of outdoor enthusiasts. For several decades a wonderful success. Then it began to grow like a mushroom, opening stores across the country. Opposition to the growth was met with stonewalling. =8~| No problem for a few years. Then the economy shifted. MEC became bankrupt and was forced to sell assets to a private interest. I really don't want Wikimedia to fall to the same fate but, without accountability, that might be inevitable. =8~( Regards, ... PeterEasthope (talk) 15:42, 29 January 2022 (UTC)[reply]
Valerio Bozzolan> Comment "Please invest more than 1 minute in writing a good proposal."
Before I attempt to rewrite the proposal please make one specific criticism or ask one specific question. The meaning of "less embellishment" is clear. I gave two examples. An alternative statement in one word: simplify. Sorry to resort to a flippant cliche but what part of simplify is not understood?
> "The world is watching this conversation."
Encouraging although authorization of a change and implementation are controlled by a few people. If the authority doesn't support a proposal, it won't progress. Hypothetically, the board of directors has ultimate authority. The board can advance an interest or delegate to paid staff, few of which will support a proposal limiting employment. In any case there is risk of benefit to interests of a relatively small group of people on a relatively small time span. As noted above, the analogy to MEC is frightful. =8~(
Incidentally, the absence of an answer to my "inescapable question" suggests exactly one explanation: the answer is too embarrassing to state.
A third simplification, additional to the two above.
(3) For some links to articles, hovering the mouse pointer on the link gives a small preview of the article. I question the worth of the preview. In a page containing a high density of links, just moving the pointer across the screen can produce several unwanted activations. Every unwanted activation is a distraction and delay. Rather than use computational resources for preview, simply open the full article with a click. In absence of a click, do nothing. If previewing must remain, make it optional; provide a option to shut it off. Wirth's dictum again: resouces needn't be consumed merely because consumption is possible. PeterEasthope (talk) 16:57, 13 February 2022 (UTC)[reply]
@PeterEasthope: I'm on your side, but if the proposal is poorly written, the proposal readers (lot of people) invest too much time to understand how to help and sustain you, resulting in no one being able to support you. If you think that «Embellishmentosis - Example: "edit source" suffices; remove "edit".» is a good proposal, I thank the six people who put +1 understanding what you wanted. I didn't get it. Valerio Bozzolan (talk) 09:45, 14 February 2022 (UTC)[reply]
Support This is a real warning suggestion. Every organisation tend to extend beyond its core goal, which makes its grow more exponential, and finally causes implosion. Havang(nl) (talk) 10:18, 1 February 2022 (UTC)[reply]
Problem: Functionaries get doxxed on and off Wikimedia projects, and receive threats of harm and have had things happen to them in real life. Many countries, including the United States, do not have proper legal protections regarding publication of private information, and county and state records including birth certificate and property deed information wind up on data sharing sites.
Proposed solution: For functionaries, provide an identity protection service like DeleteMe and/or general identity theft protection (plenty of companies do this in the US). Provide equivalent services in other countries. Also write up a guide as to basic identity protection practices (there are plenty out there for high-risk journalists, for example).
Who would benefit: Functionaries, and users served by those functionaries.
More comments: It might be possible to convince companies to provide this service as a gesture of goodwill and charity.
so... this deleteme service basically files "Right to be forgotten" requests with google and makes things disappear from google and other search engines ? —TheDJ (talk • contribs) 09:17, 14 January 2022 (UTC)[reply]
Well I'm seeing as an immediate issue, the fact that the Foundation has formally stated its opposition to the concept of "right to be forgotten" and suchlike. I can't imagine they'd be in favour of backing this, even though they are, of course, against the editors being doxxed. Nosebagbear (talk) 15:46, 18 January 2022 (UTC)[reply]
I'm not sure how relevant that is - we talk about people who are notable, but then we don't go and publish celebrity home addresses on Wikipedia. --Rschen775419:03, 18 January 2022 (UTC)[reply]
Voting
Support I doubt this would turn out to be worthwhile but it's an important enough problem to merit official investigation of the proposal, IMO. Tgr (talk) 00:46, 30 January 2022 (UTC)[reply]
Oppose The underlying issue is important but I don't see why it should be limited to functionaries or how companies providing "identity protection services" would help here. For instance if you're part of a group of people that is persecuted (either by states or other groups of people), having your identity revealed can be really problematic in any case. For instance if you're homosexual, in some countries you can be killed for that (https://en.wikipedia.org/wiki/Capital_punishment_for_homosexuality), and contributing to articles on the topic. For instance [[LGBTQI+ rights in <country where homosexuality is illegal>]]) can get you in trouble. The same issue applies to some political topics in many countries. The consequence is that repression against people directly affect the neutral point of view of Wikimedia projects like Wikipedia. To fix that, the Wikimedia projects themselves should rather be proactive in protecting contributors identity rather than trying to fix it when it's too late and not fixable anymore. Wikipedia pages (including the history) can be archived for instance. Nowadays:
The CreateAccount page on Wikipedia (https://en.wikipedia.org/w/index.php?title=Special:CreateAccount) already has the following text: "Consider using a username other than your real name, as usernames are public and cannot be made private later." (that page doesn't work with Tor though).
What we could do to improve the situation is probably to find what prevents people from contributing to projects like Wikipedia in these situations and fix it. For instance before writing this reply, I wasn't aware of the policies, and I assumed that it was not possible to create additional accounts to avoid political persecution. Though I do edit Wikipedia through Tor and for that I had to request an exemption. Though sometimes even if I'm logged, I've to use a new route to edit as I'm somehow blocked even with the exemption, but after very few retries it usually works. Without the exemption I don't think I could do any editions at all from Tor. Another area of work would be to have guides to help persecuted people contribute to projects like Wikipedia and still stay safe. Using the tor-browser (with or without bridges depending on the country and the political situation), avoiding being identified through Stylometry, etc could probably help too. The issue here would be to find people persecuted people that are willing to explain why they don't contribute. The Tor and the Tails projects already interviewed people anonymously to understand better the needs of their users, so they also have experience with that. In addition they have to distribute bridges in countries where you could get in trouble for that, so some people involved probably have some experience with helping people facing persecution in ways that don't backfire. GNUtoo (talk) 21:25, 1 February 2022 (UTC)[reply]
Support This is important to not harass or bribe the functionaries (Checkusers, oversighters, stewards). Also we can give the global bureaucrat permission (some are not comfortable to sign the confidentiality agreement) Thingofme (talk) 13:14, 5 February 2022 (UTC)[reply]
Building an entire new app AND what is essentially a new 'wiki', seems a bit outside of the scope of the wishlist. I mean i'd love to see it too, but.... Anyway, I think this could be easily prototyped by someone as a website, which pulls from different parts of our wiki eco system. Projects like these need people who are personally invested into making them succeed I think. Better one dedicated volunteer with a vision and some tech skills, then a group of random developers. —TheDJ (talk • contribs) 10:09, 13 January 2022 (UTC)[reply]
Oh, and I think that what you proposed in term of engagement etc. is actually better than lots of the 'wikikids'-wiki proposals I've seen out there. Also makes sense to do that on mobile, the kids I know seem to only use iPads/phones, I've only seen them use Chromebooks for school when they become 12yo or something. —TheDJ (talk • contribs) 10:12, 13 January 2022 (UTC)[reply]
I think what is needed is to cut down the scope of this proposal heavily in order to fit into community tech wish list. I see the proposal can be cut down to only "Adding children mode into the existing wikipedia app" with main features needed including "sensitive content filter", "access time limitation", "article reading history report", as well as "random DYK articles". But even just these aspects are already quite complicated by community tech standard. C933103 (talk) 22:36, 15 January 2022 (UTC)[reply]
Hello and thanks for taking the time to write this proposal. Echoing what folks said here, this is definitely out of scope for our team but an idea that's valid nonetheless. I am therefore moving it to the Larger Suggestions Category. Thanks again! Regards, NRodriguez (WMF) (talk) 17:49, 17 January 2022 (UTC)[reply]
Simple English Wikipedia is constantly short of editors; for this reason, things like "Portals" don't really exist. The "Fun facts" take at least a month to compile; of course Wikipedia isn't censored, so the "access restrictions" will be difficult to implement there. As long as there are not more editors on SEWP, this is not realistic.-Eptalon (talk) 22:34, 17 January 2022 (UTC)[reply]
@Eptalon Ya I see this too. The creation of this app might encourage editors to contribute. Though, I don't think we should build something when the content isn't even there to support it yet. We're going to have to find a better way to encourage contributions to Simple or come up with some other way to deliver simplified content. Lectrician1 (talk) 11:16, 19 January 2022 (UTC)[reply]
Support Sounds lovely- would really encourage learning + provide an app for those parents that somehow maintain the insane belief that Wikipedia is unreliable Bristledidiot (talk) 19:07, 28 January 2022 (UTC)[reply]
Support This would need to have a team dedicated to it, but could be incredibly valuable to new generations. "no censorship by default"; I would say is a little broad. I would think the app would censor what is shown by default. People could tag articles as "safe for children" or "not safe for children" and parents could enable or disable, etc.. Fazart (talk) 00:52, 29 January 2022 (UTC)[reply]
The problem with this is the following: at least internally, you need two users, one or more users 'Parent1..n' who could set the information of what is acceptable for user child to see. Then perhaps 2-3 different "levels of settings":
1) Age group: (3-5,)5-7, 7-9, 9-11,11-15,15-18
2) Different "Knowledge groups": Animals, Geography, People, Customs,...
3) Perhaps a negative list: no nudity, no atheism, no new religious movements, only christianity-related articles about religion.
etc.
No first of all: all these groupings need to be done using manual (or more likely: automatic) filtering. If your girl searches for bikini, do you want her to also be able to see information about 'micro bikinis' (they were developed by nudists in the US, because some states outlawed nudism), or pasties (even more minimal?). Or just information about the Bikini atoll (where nuklear tests were done, in the late 1940s-1980s, and local population was chased away, and some islands won't be habitable for a long time, see the dome they bulit on Runit island where they pur 'radioactive material')? - Note that the way the Wiki is built, there can be links from any article to any other article. So if your kid can see bikinis but not micro-bikinis, how would you make it obvious for them that 'micro-bikini' is off limits?
Note: no matter how it is implemenzed, the 'permissible-content-selction' needs to be done in the Application, and not on any of the Wikipedia projects. It might be difficult/ewrror prone to implement. Eptalon (talk) 20:53, 30 January 2022 (UTC)[reply]
Strong oppose - While the content may be there (for English), I do not see enough editors willing to contribute (as editors). In addition, the idea of 'customizable-content-selection' is non-trivial to implement, and I currently do not see the manpower available. As noted above: In my opinion, 'content-selection'/'censorship' needs to be implemented off-wiki (that is: in the app).-Eptalon (talk) 21:04, 30 January 2022 (UTC)[reply]
Problem: The problem is how to prevent corporate (not individual) sock-puppets - where teams of employed (or conflict of interest) editors collude to steer a narrative. While Wikipedia has a strong ability to moderate and manage those efforts by individuals to distort, rewrite, or promote a particular viewpoint, it is not at all as strong when dealing with large corporate interests, especially when pushing a narrative that, at face value, may appear to be robust and peer-reviewed, but is actually politically or financially motivated. As one of the most visited websites in the world, where people come to find out 'the truth', there is an increasing responsibility to prevent political/financially motivated agendas.
Proposed solution: This behaviour could be identified using modern graph analysis tools based on edit and comment behaviours. Current sock-puppet approaches use tools such as stylometric conformance analysis, but I believe that additional tools could be implemented that look at cross-user behaviours, especially where comments and edits are often shared, following patterns of behaviour that indicate focus on specialised content. This is particularly noticeable where there are a group of editors who are aggressively defensive in their given subject area.
For example, of a potential positive hit, it is not unusual, given any area of expertise, for editors to agree most of the time - however, when they agree all of the time, then their relationship becomes suspect.
Who would benefit: Everyone who matters benefits from increased vigilance.
The example you showed only indicates sockpuppet identification through stylometric conformance. What I am suggesting is different, and involves co-ordinated efforts being made by separate editors who are working for the same lobbying organisation. 20040302 (talk) 11:19, 11 January 2022 (UTC)[reply]
@20040302 Thanks for clarifying, and for Pppery for mentioning Masz which I wasn't sure was public knowledge :) Anyway, I worry this project might be too big for Community Tech, but now knowing that Masz isn't what you're looking for, I will unarchive this proposal for the time being. Later when Community Tech reviews the proposals we may or may not deem this one too large, but if it is, we'll be sure to move it to our Larger suggestions category so it doesn't get lost here in the archives. Best, MusikAnimal (WMF) (talk) 16:44, 11 January 2022 (UTC)[reply]
Upon further investigation I think it's clear this is out of scope for our team, but it's otherwise a fine proposal so I'm going to move it to the Larger suggestions category. Regards, MusikAnimal (WMF) (talk) 23:27, 17 January 2022 (UTC)[reply]
Yeah, I don't think this is in the pile of things the team has time for, and it would need significant fleshing out. --Izno (talk) 00:19, 17 January 2022 (UTC)[reply]
A big task, perhaps better suited for its own persistent team. But I would say this is one problem we will eventually have to solve (or shut down). The # of editors who primarily edit because they are paid by syndicates or as editing consultants has been rising even as total editors slowly declines. In some smaller wikis and some topic areas these may already be dominant forces. –SJtalk23:45, 23 January 2022 (UTC)[reply]
I'm no expert but I wouldn't have expected detection to be the main COI/PAID/SOCK issue, but enforcement. We need WMF Legal to start sending scary letters to the corporations and individuals blatantly in violation of our Terms of Service, as proud declarations on their websites of their "services" to clients make abundantly clear. — Bilorv (talk) 20:31, 28 January 2022 (UTC)[reply]
Oppose I already have significant concerns with the morality of @Ladsgroup:'s process - the community can't judge its accuracy for itself, we don't know its error margin, how much of the review (in the sense of "this is how confident we are in the closeness") is done by the CUs and how much is automated and just told to them, and knowledge of its existence is generally pretty low (I knew prior to it being posted here, but only because I was told about it by a CU). More relevantly, the comment above is absolutely right, we don't need better mapping tech, we either need Legal to become significantly more aggressive on dealing with them or a public relations campaign to see if we can impose pressure that way...and I think the latter would only help them. Nosebagbear (talk) 10:08, 1 February 2022 (UTC)[reply]
Hello there, we looked at the discussion inside T4700 and decided that from an engineering perspective, this would be too large for our team. We are moving it to Larger Suggestions because we still think it should get visibility. Thanks for understanding, regards NRodriguez (WMF) (talk) 01:18, 18 January 2022 (UTC)[reply]
FWIW, in the English Wikipedia we have a very powerful referencing template {{R}}, which allows to define and invoke citations and footnotes. At its core it is a wrapper around MediaWiki's Extension:Cite, therefore it is fully compatible with references using <ref> tags, and both styles can be mixed on the same page as inline references or list-defined references. It is also compatible with any other citation templates typically used inside<ref> tags to format references (including the suite of CS1/CS2 citation templates).
Due to the way it works, the pipe trick, substitution, and nesting all work when defining references through template {{R}}.
I agree that MediaWiki's parser should be improved to support these features directly, but for those who don't want to wait for this, using {{R}} might be a workaround. --Matthiaspaul (talk) 22:01, 28 January 2022 (UTC)[reply]
Using {{R}} is, however, annoying for users who edit using the visual editor, because it has very poor support for references created inside templates (see e.g. T52474). A technical solution that avoids such templates would be nice. Matma Rex (talk) 22:10, 28 January 2022 (UTC)[reply]
I would phrase that rather differently. The purpose of {{R}} is not to be a workaround to the problem stated by the OP, it exists (like other templates on top of Extension:Cite) because it provides many desirable features of a citation system in its own right - it just happens to also work around the OP's problem and therefore could be conveniently used for this purpose as well.
Yes, this still makes it desirable to have an improved MediaWiki parser so that the mentioned features work also inside of <ref> tags. One does not rule out the other.
But, no, suggesting that references in templates should be avoided (or even technically forbidden) is setting the priorities wrong. If VE does not cope well with references in templates, the problem is VE (implementation-wise or even conceptually), not references in templates. VE is a non-essential convenience extension for beginners, whereas the possibility to use references anywhere in an article (including inside of templates) belongs into the group of essential features to lay the foundation to properly referenced encyclopedic articles, the very reason of why we are here. So, if VE can't cope with it, VE (or the framework around it) should be improved, not other much more important functions put down. But not the topic of this thread... ;-)
Support I realise Community Tech probably can't do anything about this, but want to express my support for someone at least looking into it. It's a totally counter-intuitive bit of behaviour, just look how many duplicates of the bug have been filed over the years. the wub"?!"15:13, 31 January 2022 (UTC)[reply]
Problem: The current system for tracking Long Term Abuse (LTA) is barely functional. LTA case pages are often abandoned or jammed with IPs from a decade ago. Self-made lists (e.g., en:User:EvergreenFir/socks, en:User:NinjaRobotPirate/Socks) can be helpful but are idiosyncratic and incomplete.
Proposed solution: Create a system like Sockpuppet Investigations (SPI) where cases are filed, reviewed, and archived. Adding reporting abilities to Twinkle would be a huge help.
Who would benefit: Admins, vandal fighters
More comments: Having CheckUsers be able to confirm would be helpful (like SPI) but I imagine this being much more about behavior and geolocation. Maybe a subsection in SPI itself could work.
Comment@Zeleni, TheInternetGnome, Kcomerfo, and Thibaut:, pinging supporters. Since this was moved to larger suggestions there’s no guarantee of it passing but especially if you add the low support compared to other suggestions. I suggest to create a user group in meta for long term abuser monitoring, move all the databases from Wikipedia to meta, and this user group will be in charge of maintaining it. It’s possible to ping users monitoring their own lta databases. -Gifnk dlm 2020From Middle English Wikipedia 📜📖💻 (talk) 07:53, 4 February 2022 (UTC)[reply]
As I said, merging to one central LTA list will happen with the "IP editing" project (linked above). Creating an meta list could speed up the proccess, as it has been decided that the "IP editing" central list will be merged by the communities. Just be aware the list will not necessarily remain on meta, although it still will be central. Snævar (talk) 18:06, 4 February 2022 (UTC)[reply]
@Gifnk dlm 2020: Yes and no. The technical aspect needs to be communicated with the "IP editing" team, but merging and maintaining it is entirely upto the community, so the RFC below is good for that. We need to know what format the "IP editing" team wants for the list. Snævar (talk) 00:18, 9 February 2022 (UTC)[reply]
For LTA list, we should have a database, SRCU, and links between globally banned users (their editing behavior) and list of socks (to help coping with SRG which has a lot of requests). Also we can have an alternative way of SRG - a page similar to GSR or WP:AIV in enwiki, just to report socks of blocked users to lock and record. Thingofme (talk) 13:20, 5 February 2022 (UTC)[reply]
Support there are already such lists across different wikis. Just move all the content in multiple languages to one list on meta. -Gifnk dlm 2020From Middle English Wikipedia 📜📖💻 (talk) 20:01, 29 January 2022 (UTC)[reply]
Problem: Votewiki & Securepoll (V&S) are currently failing to meet several key requirements of communities demanding secure electoral capacity. Worse, yet, they are even less well suited to the impending increase in demand (such as new Arbcoms being encouraged into being by the Universal Code of Conduct) and variability in electoral methods (potentially the U4C, likely the Global Council, etc etc). Example issues include, but are not limited to: inability to handle simultaneous elections in different languages; extreme user-unfriendliness for Single Transferable Vote with more than a few candidates; lack of a tied-candidate mechanism for the STV option; difficulties in adding additional voting systems; the system is also technically fragile, with major bugs impacting elections requiring WMF staff activity to resolve.
Proposed solution: There have been discussed interim solutions (Such as creating a second vote-wiki to allow for two simultaneous elections), but they are just that, interim. A significant scoping work and re-development across the board would be needed, rendering this well beyond the Wishlist team's capacity.
Who would benefit: Every community that has non on-wiki elections, but especially every voter and every candidate
More comments: Everyone should feel free to add phab tickets below, as appropriate. I've not directly added the issue of struggling to find trusted/qualified individuals to scrutinise elections as that's not strictly a system issue.
Firstly, given the movement-charter adjacent nature of this proposal, just to confirm that this proposal is solely from me, without prior discussion with the MCDC and is not intended to indicate their opinion on the proposal. Nosebagbear (talk) 15:14, 18 January 2022 (UTC)[reply]
So I think that proposal would make an excellent interim solution, especially if twinned with making the current system somewhat more stable, but ultimately it's still going to prove insufficient for needs (and thus makes a good more practicable suggestion vs the issue raising this more is, for now) Nosebagbear (talk) 10:19, 20 January 2022 (UTC)[reply]
Problem: The current pageview analytics are not specific enough to direct an editor's attention to the portion of an article that is most in need of being improved.
Proposed solution: The proposed solution is analogous to the YouTube engagement analytic that shows, statistically, at what time in a video viewers are leaving. However, the proposed solution for a Wikipedia article needs to account for multiple entry points into the article, as opposed to YouTube viewing which usually starts at the beginning of the video. Therefore, the proposed solution is to provide article editors with data showing how much time readers spend on each rendered section of the article, starting at the reader's entry point into the article.
Who would benefit: The article editors would benefit from the feedback and the article readers would benefit from articles that have had their worst parts improved.
Good idea. Such analytics might also give an idea of which parts of an article can be deleted! Similar to the grammar-check proposal. In general Wikipedia needs to get with the times and make more use of automated tools. They represent free productivity, there for the taking. That should be a priority for a project built on volunteer labor. --Rollo (talk) 19:17, 16 January 2022 (UTC)[reply]
I agree that it could help with deletions. I think deletions are the most difficult edits because of the risk of discouraging volunteers from making future contributions. However, deletions often improve the article and having some data to help rationalize deletions would make deletions a little less difficult. --Gj7 (talk) 15:34, 17 January 2022 (UTC)[reply]
This is very much out of scope for Community Tech, but we're going to put in with our Larger suggestions category so it can still get some attention. Without having ran this by the Analytics team (who maintains the pageviews pipeline), I suspect there are many concerns with this. One is that we'd basically be monitoring what parts of the page the reader is viewing, which is something perhaps not everyone is comfortable with (even if anonymized). It could also be of performance concern for mobile readers, given we'd have to continually make roundtrips to the server even though the user hasn't done anything beyond scrolling. It also would be subject to many false positives and could send editors the wrong signal. For instance, a reader may view the table of contents for an article on a music artist and jump straight to the Discography section. This doesn't mean there's anything wrong with the content in between; they just want the discography and nothing else. In my opinion an encyclopedic article isn't that comparable to a YouTube video in this regard. MusikAnimal (WMF) (talk) 23:45, 18 January 2022 (UTC)[reply]
The rewording of the wish changed its nature. The original wish was not to track a reader's movement through an article as the current wording suggests. The problem, as I see it, is that article editors are blind to the statistical patterns of reader access: including time and order. In the case of your example, if 90% of the readers of that article on a music artist jump straight to the discography section, would that not be useful information for article editors to help reorganize the article, for example by putting the discography section first?
Oppose: this information would be both informative and motivating to many editors in many situations, but this is outweighed by privacy (and possibly performance) concerns. We should be proud about not collecting this sort of intrusive analytic data. — Bilorv (talk) 20:35, 28 January 2022 (UTC)[reply]
Oppose: There would be a performance hit from such analytics. Wikipedia doesn't need this anyway - let's strive to have excellent articles, not just excellent sections. --Šedý (talk) 11:24, 29 January 2022 (UTC)[reply]
Support Obviously it would need to be implemented in a privacy-conscious way, but I think more information could help with article decisions Ph03n1x77 (talk) 07:07, 5 February 2022 (UTC)[reply]
Problem: Communicating about smaller things or conversations that require frequent back-and-forth are time-intensive and annoying to conduct on Talk pages. As a result, communities have been set up on other platforms like Discord and Telegram to conduct these types of conversations. All wiki conversations should conducted and centralized on their wiki for openness and collaborative efficiency, but because of the current lack of communication methods they are not and have moved to different platforms.
Proposed solution:
A chat client that can be accessed on any wiki page through a button at the upper right by your profile icon that opens a chat dialog box where you can access all of the chats you are subscribed to. The client will also have its own dedicated page so that you can keep it open in a separate tab. Realtime notifications could be enabled.
Chats will be derived from containers present on talk pages. For example, a talk page will have a normal Wikitext container and then a chat container (maybe one after the other or side-by-side?). The chat container will house a custom client that shows a list of active and previous chats for that page and allows users to start a new chat about a topic or subscribe to one just like current talk pages. Once created or subscribed-to, these chats will be realtime/live-updating and able to be accessed from the chat client when you are away from the talk page.
Chats will be structured in a thread-like format. Every response to the last message sent by another user will be by-default considered a reply to that message or series of messages unless a specific message or series of messages is selected to be replied to. This way, chats can be converted into Wikitext conversations if-wanted and vice-versa. If the topic changes from what was originally being discussed, a message can be marked as the starting point for a new chat. That message will create a new chat on its page (or could even be moved to another) to indicate to other editors it is a new topic, but will still remain a continuation of the chat it was derived from.
Chats would primarily be enabled on personal and community talk pages like User, WikiProject, and wiki-encompassing talk pages, but not article pages.
Chats will not replace Wikitext conversations. Wikitext conversations are beneficial for topics that require the attention and input of an entire community that would see a talk page. They act as a permanent notice and community forum, rather than a chat where points mentioned by users in a conversation can quickly disappear. For example, discussions about changing something fundamental about a WikiProject would be appropriate for a Wikitext conversation.
Continuous non-thread-like-chats may want to be created to provide a fun off-topic place for editors to converse. That way we don't have to rely on Discord for that either.
Who would benefit: All editors.
More comments: See also Wikimedia Social Suite. This is a set of communication services hosted by Wikimedia itself including chat services like Mattermost, Rocketchat, and Zulip. This proposal is different in that it seeks to build an on-wiki centralized chat service.
It seems like this would require a lot of Wikipedia's resources (making a bespokse chat client is hardly a small task) for something that is already solved by users using Discord or Telegram. I don't think an additional on-site chat client will stop users prefering to use Discord and Telegram either. --//Lollipoplollipoplollipop::talk09:39, 11 January 2022 (UTC)[reply]
The convenience of having a chat on-site and accessible while editing would be extremely convenient. New users wouldn't even have to search for if a Discord server exists for a Wiki because an available chat client would be right there and you could easily connect with any Wiki user you want to, without having to worry whether they are on Discord or not. Therefore, I think users would totally use this over Discord and Telegram, even if it wasn't as feature-rich.
This would require quite a bit of resources to implement, however tools similar to this like Structured Discussions can be used as a baseline technologies for demonstrating that non-wikitext thread-like chats can work and exist. Really, the key infrastructure that will require work will be connecting users live and connecting of them in groups. Lectrician1 (talk) 13:14, 11 January 2022 (UTC)[reply]
Would normally be in another browser tab, but certain browsers have the ability to "float" a tab and make it "on top" of other things. — xaosfluxTalk14:21, 12 January 2022 (UTC)[reply]
@Xaosflux The problem is that you cannot directly identify users. Also, IRC would not allow for people to create new chat topics for a page like I described in the proposal since IRC only has channels (unless you want to set up a server for every page that has a chat container). You also don't have the ability to create threads or ping users. It would be much better to create a MediaWiki-based chat extension that gives us the ability to implement and have full control over such features. Lectrician1 (talk) 19:34, 13 January 2022 (UTC)[reply]
This would be particularly useful for adding interactive sessions to Wikiversity. In a traditional classroom setting students ask the instructor questions, and discussions among students are often held as part of the class. This is an important learning mode that is absent from Wikiversity. If a chat room was readily available to students, linked from a specific course that would be helpful. Additional features that could allow a discussion leader to announce a time and place for a discussion session or seminar would make this even more useful. Thanks! --Lbeaumont (talk) 15:00, 12 January 2022 (UTC)[reply]
I think this is very useful and will benefit everyone. Especially the commment about wikiversity is a compelling argument imo. -Gifnk dlm 2020Happy New Year 🎄❄️⛄️🎇 (talk) 17:48, 13 January 2022 (UTC)[reply]
@Fastily I love the Discord too, but wouldn't a chat on-wiki that would be faster to use, public and available to everyone, and allow you contact anyone with a wiki account be a better solution? I don't think anyone thinks that the community being fragmented in communication among the various chat platforms and talk pages is a good thing. If a MediaWiki extension was made, all Wikimedia projects and all MediaWiki wikis could utilize it too. Lectrician1 (talk) 13:04, 14 January 2022 (UTC)[reply]
Getting DMs via MediaWiki while editing feels oddly invasive, and it's certainly not something I'd want enabled by default. "Fragmentation", which I'm still not convinced is an actual issue, could be remedied by simply declaring Discord to the be the official platform for chat. -FASTILY23:27, 14 January 2022 (UTC)[reply]
I'm in general against a chat feature. User A: "In chat, user B has called me a stupid idiot. Block them!" WM projects are not chat rooms and I consider these being out of scope. New projects enwikichat, dewikichat, frwikichat, eswikichat? No, IRC as is now is sufficient. --Achim55 (talk) 19:44, 17 January 2022 (UTC)[reply]
User A: "In chat, user B has called me a stupid idiot. Block them!"
Judging by how this rarely happens on any of the chat platforms currently used by the community or talk pages, I doubt this would happen. People tend to communicate more respectfully when everything they say is public. Though, I do understand the concern - I just don't think it will manifest itself.
WM projects are not chat rooms and I consider these being out of scope. New projects enwikichat, dewikichat, frwikichat, eswikichat? No, IRC as is now is sufficient.
If IRC was sufficient, everyone would use it. Barely anyone does on the English Wikipedia compared to the Discord server. There's clearly a demand for a chat service. Making it centralized on-wiki will mean people won't "miss out" and everyone can see what everyone is talking about. Also, new projects "enwikichat, dewikichat, frwikichat, eswikichat" is not how this will work. Please read the proposal above. Lectrician1 (talk) 21:10, 18 January 2022 (UTC)[reply]
Existing chat platforms aren't advertised widely. You're proposing to put this in a prominent location for every person who views/edits the website. Izno (talk) 22:22, 18 January 2022 (UTC)[reply]
Hey everyone, thanks for taking the time to write this wish and for the discussion! Adding chat functionality would be out of scope for our team due to technical and design complexity. There are strong cases to be made for including chat and for not including that functionality. We are moving this wish to Larger Suggestions instead of the Archive since we still believe there is value in voicing this as an idea and letting the conversation grow accordingly. Thanks and regards, NRodriguez (WMF) (talk) 00:58, 19 January 2022 (UTC)[reply]
I think a reasonable alternative (as the Wikimedia movement trying to develop its own chat client would be an immense waste of resources) would be to integrate an existing chat system so that you can interact with it from a wiki page (maybe from a messenger popup, similar to e.g. Intercom; maybe from a container that can be embedded in the content). I have been looking into that lately and I think Matrix provides a solid foundation for it, with an open and fairly flexible community-stewarded protocol, the ability to provide our own identity services while being connected to a global network, and some existing (not great but functional) web integrations (like the ones used here or here). --Tgr (talk) 21:52, 23 January 2022 (UTC)[reply]
Modding this would be completely implausible - the Discord (where I am a mod) has a vastly higher dominance of experienced editors than the general project would. Additionally, we don't use IRC because it's not user-friendly enough for our purposes. I consider it unlikely that the WMF is going to make a client that viably competes with Discord on those grounds. Nosebagbear (talk) 11:32, 24 January 2022 (UTC)[reply]
I could imagine finding this useful, but I wouldn't make it a priority. In particular, I hang out on a smaller Wikipedia where we haven't yet been overwhelmed with the amount of discussion on talk pages. A. Mahoney (talk) 18:53, 31 January 2022 (UTC)[reply]
Voting
Very Strong support will be very useful to be able to have instant chats. Someone has suggested they can be used to have lessons for wikiversity courses. I agree with this compelling argument, it will be possible to set a scheduled 90 min chat as a lesson, and it’s content will be archived for people in the future willing to learn that lesson. In Israel, there are groups in WhatsApp with scheduled lessons and a teacher for high school students and it’s useful and works, so there’s no reason such an idea won’t. Also the creator of the course will be able to verify his identity easily because it will be using the same account system. There’s no reason modding this will be different from modding talk pages, actually it will be easier because users won’t be able to vandalise other comments, and their comments will be signed automatically. -Gifnk dlm 2020From Middle English Wikipedia 📜📖💻 (talk) 18:17, 28 January 2022 (UTC)[reply]
Before someone asks, using the proposed client for lessons will be better than WhatsApp or discord chat since the archive is in wikiversity and can be linked in the course main page. Users will be able to learn from the questions of previous people. In order to avoid abuse, only users with a special permission will be able to schedule chats. -Gifnk dlm 2020From Middle English Wikipedia 📜📖💻 (talk) 18:32, 28 January 2022 (UTC)[reply]
If approved it will be able to do something previously impossible with courses in wikiversity. This definitely can’t be done with regular talk pages so previously the only way was to use other platforms. With this proposal, it will be possible to have lessons on wikiversity and then the lessons will have a public archive in wikiversity for people in the future to learn from the questions of people in the past. -Gifnk dlm 2020From Middle English Wikipedia 📜📖💻 (talk) 19:15, 28 January 2022 (UTC)[reply]
Support Would be useful to be able to chat on-wiki, rather than having to install third-party tools to do so. Ideally should include public logging to the talk page afterwards. Telegram seems to have become particularly popular this last year, sadly, even though it's completely closed and non-transparent. Thanks. Mike Peel (talk) 18:59, 28 January 2022 (UTC)[reply]
Support Finally I can chat with people to coordinate edits or permission to edit specific pages in which otherwise I would be unable to edit. Rzzor (talk) 19:52, 28 January 2022 (UTC)[reply]
Support Some people still have not understood that Wikipedia is also a social network since it's inception. That's how it initially developed, and a significant part of new users come precisely from the social network part of it (either on Telegram, Facebook, wherever. It would be really great to have a native platform to chat with each other, instead of relying in 3rd-party stuff. - DarwinAhoy!15:01, 5 February 2022 (UTC)[reply]
Oppose First, a chat client would lead more people to use it for purely social purposes. The temptation is always there. Second, I have always been proud of our insistence that we make people write and memoralize what they say in on-wiki discussions so that there is a record of decisionmaking for anyone to examine. It may be cumbersome by today's standards but it keeps us honest at a time when we need to be. Daniel Case (talk) 03:29, 8 February 2022 (UTC)[reply]
Weak oppose OpenStreetMap has a very nice way of recommending nearby communities (chats, mailing lists, local groups) when you are in edit mode. I think that could be a generic solution. --Valerio Bozzolan (talk) 16:52, 11 February 2022 (UTC)[reply]
Show Abusefilter changes in watchlists
B This proposal is a Larger suggestion. There is no guarantee this proposal will be implemented. Supporting the idea helps communicate its urgency.
Problem: Currently, there is no way to monitor for changes to specific AbuseFilters without going directly to the filter itself and viewing the history of changes. They cannot be not shown in watchlists like other pages can.
This is going to be too big of a project for Community Tech, but it's a good idea nonetheless. I'm going to move it to our Larger suggestions category. I've also tweaked the wording of the proposal a bit to be more clear. Hope this okay, MusikAnimal (WMF) (talk) 21:43, 19 January 2022 (UTC)[reply]
Problem: MediaWiki doesn't allow page merge and fork. Editors have to copy-paste content manually, edit history is lost. Edit history can be merged via deleting, but it leads to unreadable mess.
Proposed solution: Extension to enable merge and fork features like a version control system.
Most likely, but I'll share my thoughts anyway: it seemingly wouldn't be too hard to have a Special:ForkPage for instance that simply copies the revisions to a new page. However they would of course be new revision IDs, and that brings up the question of what to do about timestamps. Do we use the original timestamps? That seems weird because those edits to the new page weren't actually made at the same times as the original edits. Finally, this feature could be abused. How bad does it make me look if you forked edits I made and put them under some inappropriate title? Food for thought.
Judging by the size of phab:T113004, I'm definitely going to say this is out of scope for us, but I will move it to our Larger suggestions category so the idea doesn't get suppressed in the archives. Best, MusikAnimal (WMF) (talk) 23:27, 20 January 2022 (UTC)[reply]
Forking involves some copyright concerns. Allowing page history to be a DAG instead of strictly linear seems not super hard in terms of backend implementation, but how do you display merges and forks to the user? It would be a massive project (although potentially quite valuable to support offline editing and FlaggedRevs style functionality where contributions can be on a "side branch" until they get reviewed; of course there are many ways that could go wrong). Tgr (talk) 21:59, 23 January 2022 (UTC)[reply]
Well, if you "continue" the page history in the forked page in some way, there are copyright issues to deal with. If you duplicate the page history, there aren't, but then there will be duplicated edits in user contributions, inflated edit counts etc. Tgr (talk) 02:35, 24 January 2022 (UTC)[reply]
A full merge/fork tool is hard. But an interface for the current process (single-edit fork or merge, appropriate defaults for the edit summary) seems possible. I don't think you need to copy any revisions at all, just provide an interface that makes it easy to see them all in one history page or to compare revisions across the different article titles [something already possible if you know both article-revision-IDs]. –SJtalk23:56, 23 January 2022 (UTC)[reply]
Support Nice to have to create new sandboxes. Maybe as user gadget. This would help in respecting copyrights, since most of the time an user just copy-pasta the content without leaving any information in the destination subject entry (so no way to go back to the original permalink or to the original page or to the original history). Valerio Bozzolan (talk) 16:57, 11 February 2022 (UTC)[reply]
Show navbox templates on mobile
B This proposal is a Larger suggestion. There is no guarantee this proposal will be implemented. Supporting the idea helps communicate its urgency.
The blockers for this are well understood. 1. Navboxes are too large. they are very verbose and are huge contributors to pagesize. This is a solvable problem with lazy loading, but that does require significant engineering. 2. Navboxes are tables that don't work nicely on mobile devices, the UI concept needs work 3. Navboxes are mostly used by editors, not by readers (so lots of burden to benefit just a few). I would however love to see the design department simply EXPLORE this topic, come up with interaction ideas for people with this content. We really need a vision for this stuff, not just someone to flip a toggle and make these things visible on mobile. —TheDJ (talk • contribs) 10:17, 13 January 2022 (UTC)[reply]
Yes it means only downloading the content after engaging with some part of the UI to indicate you want the content. (not like expand now, because that shows you something that was already downloaded). —TheDJ (talk • contribs) 09:09, 14 January 2022 (UTC)[reply]
Most navboxes are text-only. The larger ones with more complex styles might be a few dozen KB large but I doubt they would be as large as a single image, in term of data needed to be transfer. If those few KBs are of concern then I think a check box for user to opt out of such feature would already be sufficient. C933103 (talk) 08:00, 16 January 2022 (UTC)[reply]
The Covid 19 navboxes were 2MB at some point. On most covid pages, they were half the page load and for some smaller articles the covid navboxes were more bytes than the entire article. Of course that is a pretty extreme example, but navboxes are much larger than ppl think (because they are collapsed ppl don't really think about them). Regardless, MediaWiki has to take extreme cases as the default. If it can happen, it will happen, because its user generate content. —TheDJ (talk • contribs) 10:08, 19 January 2022 (UTC)[reply]
I think many readers also use navbox. Like even when I am not in a mode or mood of editing Wikipedia, I would still frequently use the navbox to check out what are some other related pages or topics that could contain information I might want to see or need to find. This definitely benefit readers. And I think a simple table is enough, as long as the table can be allowed to scroll horizontally. C933103 (talk) 22:41, 15 January 2022 (UTC)[reply]
I fully support adding navboxes on mobile web and apps. They are an important part of Wikipedia and the reading experience is impoverished without them. Do you have any empirical evidence, like from usage studies, for the claim that "Navboxes are mostly used by editors, not by readers"? It seems highly dubious to me. --Albany NY (talk) 04:49, 16 January 2022 (UTC)[reply]
If we want to talk about dubious, that navboxes are used at all by any significant proportion of anyone is dubious. :) --Izno (talk) 06:12, 18 January 2022 (UTC)[reply]
All I know is that I use them frequently and find them a helpful way to learn about a topic. But I don't think it's wise for any of us to make claims about how people in general use Wikipedia without evidence from usage studies. --Albany NY (talk) 19:44, 18 January 2022 (UTC)[reply]
There definitely are some studies on this, I've seen them at Wikimania in the past. But finding them back is really hard. the search terms are so common... If anyone can find them, I'd love it. —TheDJ (talk • contribs) 10:23, 19 January 2022 (UTC)[reply]
phab:T124168 goes into all the detail, but in short: there are many concerns about blanket-enabling all navboxes on mobile. They can potentially contains enormous amounts of markup and visually consume a lot of space, which is problematic for mobile users. This is proposal is certainly out of scope for the Community Tech team, but we know it's a long-desired feature for some, so we will move it to our Larger suggestions category so it can be discussed further with the community. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 23:54, 20 January 2022 (UTC)[reply]
Support , particularly in the sense TheDJ mentioned of providing a vision. We need this to help make editorial decisions, like whether or not to discourage see also links that are also in a navbox. If we don't know what Wikipedia in 2030 will be like, we can't plan to build it. {{u|Sdkb}}talk04:09, 29 January 2022 (UTC)[reply]
Problem: Other than the Watchlist which supports live updates, MediaWiki is severely in lacking AJAX-based real-time features, making it rather painful to participate in discussions where new comments are being made in quick succession, among other issues.
Proposed solution:
Echo alerts and notifications should automatically refresh without a reload/navigation being required – so that users are notified in real-time when discussions they are following have new messages, or when they are pinged. (phab:T34284)
Browser-based push notifications should be implemented for Echo alerts and notifications – so that users are notified even if they just have Wikipedia open in one tab but are working on something else. (phab:T113125 / phab:T276409)
On talk pages, visual indicators like "There are x new comments in this section. Click to reload" could be added (this is currently provided by Convenient Discussions gadget, but could be made more broadly available)
Page history could show an indicator if new edits are made to the page while user is viewing. (phab:T298419)
While viewing the latest diff or permalink of a page, if a new edit is made, there could be a indicator that the content is no longer current. (phab:T295225)
Create an abstraction (such as via polling or EventStreams or WebSockets) that can be used to implement all of the above. It will also empower extension developers to integrate similar features. (phab:T146032?)
I general, broad proposals like these are good for support votes, but in my experience will get rejected as too big/unspecific by the team. I'd just split it in these individual features you gave as an example. —TheDJ (talk • contribs) 13:04, 12 January 2022 (UTC)[reply]
This approach was suggested by @Trizek (WMF) in phab:T294382#7474807. The main part would be coming up with a generic framework for real-time notifications, after which the implementation of specific use-cases mentioned above could be left for other teams or volunteers. SD0001 (talk) 03:44, 13 January 2022 (UTC)[reply]
@SD0001 THAT is the line you should start that proposal with, in my opinion. Not just all the features that it will (eventually) unblock (because those are not all gonna be delivered within a single wishlist project, not possible). —TheDJ (talk • contribs) 11:01, 13 January 2022 (UTC)[reply]
Hello there, and thanks for your proposal! As TheDJ mentioned (Thank you @TheDJ!) this is a larger ask in nature, and unfortunately while it's a collection of sound ideas, they're too big for our team. We still believe in the importance of letting other participants indicate the extent to which they support this. We are therefore moving this to Larger Suggestions rather than the Archive. Thanks, NRodriguez (WMF) (talk) 13:00, 21 January 2022 (UTC)[reply]
Problem: In VisualEditor, editing templates such as an infoboxes or an episode table of a series, etc., can be more tedious than it appears. In order to change the values of the template, you have to first open the template editing dialog. It would be easier if the infobox was directly editable visually, without the need for a dialog.
Proposed solution: Add support for making some templates directly "visually editable" as if they were tables
@Mohammad ebz: Could you link to some example templates you believe are not supported? I highly suspect all that's missing is the TemplateData. This is what instructs VE and TemplateWizard what fields are available and what kinds of values they accept. Only the community can implement this. It's pretty easy though; just go to the documentation page for the template and hit edit, then you should see a "Manage TemplateData" button at the top-left. MusikAnimal (WMF) (talk) 20:03, 11 January 2022 (UTC)[reply]
@MusikAnimal (WMF): I mean, do not open another page and edit it in the same way as regular text that is edited in Visual Editor mode. In fact, the idea is to edit the text and template information directly and visually, without the need to enter information in the window that opens. Mohammad ebz (talk) 04:42, 12 January 2022 (UTC)[reply]
@Mohammad ebz Okay, I think I may be on to you now: You're saying some templates are transcluded on a page, and you have to go to that template page to edit it, when you'd rather be able to edit it directly from the article. Is that right? It would be still be helpful if you could give an example. Link to a specific article with this problem, and let us know which template you're unable to edit. (or whatever the issue is, if I'm still misunderstanding you :) MusikAnimal (WMF) (talk) 04:46, 12 January 2022 (UTC)[reply]
@MusikAnimal (WMF): You still do not understand what I mean, let me give you an example: Suppose you want to modify an actor's infobox on his Wikipedia page. To do this, click on the word "edit" at the top of the article, then select Visual Editor mode and then click the actor's infobox, Now a floating page opens, I mean this page; If the last step is removed and the template contents are edited completely Visual like the original text of the article, the editing speed will be much faster. Mohammad ebz (talk) 05:08, 12 January 2022 (UTC)[reply]
Yes! That explains it perfectly, thank you :) I might recommend using what you just wrote as the problem statement. Your proposal says …has the problem of opening additional pages and is the same as a source editor which made it sound like you meant opening new pages in a separate tab. This "page" is what we would call a dialog or modal window.
Anyway, I'm afraid what you're after may not feasible. Without having done any sort of technical investigation, a few issues that come to mind:
Templates can have logic in them that make them appear differently based on values you give them. This would offer a very weird experience, say if the value of one field is supposed to make other fields disappear. That would be confusing if this happened in real time. This is the same reason you may notice sometimes that after applying your changes to a template, there's a brief time where it's still "loading" (in the processing of applying them). This is the parser doing its thing.
You did mention specifically "commonly" used templates, which are generally more predictable, but there's still no guarantee their behaviour won't ever change in a way we could reliably predict in VisualEditor.
What if you want to add or remove parameter to the template?
What about templates that pull their data from Wikidata?
Honestly, I think our upcoming Real Time Preview for Wikitext feature might help you in this situation. Yes, it's for wikitext (not VisualEditor), but it solves your problem of having to edit both visually and in wikitext. With Real Time Preview, you see what you're going to get when you save (just like VisualEditor). If you're like me and love VisualEditor, the current template editing dialog that is shown may be what you have to get used to. I personally find it better because it also allows the parameters to be documented and ensure the editor knows what each field is intended for, etc. (what they call TempalteData).
You also mentioned tables. Some tables are built using a template, but any raw wikitext table such as in this example should be editable directly with VisualEditor.
@Mohammad ebz Our team has concluded this wish is out of scope for us. However we're happy to promote it in the Larger suggestions category, which is intended to promote ideas to other WMF teams and the broader Foundation, rather than it being buried in our archives of rejected proposals.
However I think the proposal could be reworded better to describe what you're after. Now I understand what you're after, would you mind if I reword your proposal some? Then after you approve, I will move it to Larger suggestions. Thanks, MusikAnimal (WMF) (talk) 04:08, 18 January 2022 (UTC)[reply]
In my opinion, no problem, do your best to get a better result, my only suggestion was to improve the editing on Wikipedia; In any case, thank you for your attention Mohammad ebz (talk) 07:23, 18 January 2022 (UTC)[reply]
Okay, thanks for clarifying! I will move this to Larger suggestions. I have also tweaked the wording to make the proposal more clear. Hope this okay! Thanks, MusikAnimal (WMF) (talk) 23:10, 20 January 2022 (UTC)[reply]
By Community Tech scale, it would be too much to do so in one year. This is a very big proposal, which means it could change all the items and how VisualEditor works. But I think it would make VE more friendly. Thingofme (talk) 13:13, 12 January 2022 (UTC)[reply]
Support First of all, VisualEditor need to be implemented to documentation page and other testcases (TemplateData needs to be fixed) Thingofme (talk) 14:09, 5 February 2022 (UTC)[reply]
Problem: MediaWiki hasn’t been designed to make dictionaries or thesauri, to manage a distributed multilingual content, to interface lexicographical and semantics data and “sentence-plain” contents. The only improvement made to fix that point is Cognate extension, whereas many ones are needed so Wiktionaries can address their goals.
Proposed solution: Create a dedicated team, including a project manager to coordinate these efforts, a product owner in liaison with communities, a UI/UX engineer to design some propositions and to test them with readers and editors, developers to implement chosen improvements, a communication manager to cover this work and to assist the transformation of practices.
Who would benefit: All Wiktionary editors and readers, from all language communities.
Clearly out of scope of Community Tech team. However, keeping only UX side, Community Tech could work on skin improvements and JavaScript features to redesign Wiktionary reading (facilitate browsing through sections — languages and subsections). The problem it would fix would be “It is hard for Wiktionary readers to find the information they look for in right language when they are on the right page.” --Pols12 (talk) 20:24, 11 January 2022 (UTC)[reply]
Thanks for the translation. I'll keep it as such because the need is clear and broader than a reading issue. Moreover, your proposal is neat, it could be another wish. Noé (talk) 10:50, 12 January 2022 (UTC)[reply]
Support I've almost never edited Wiktionary, but I've increasingly been using it lately and it's clear that while it is a platform with an astonishing amount of content, it's built and run on tools that were not designed for it. Uanfala (talk) 22:54, 9 February 2022 (UTC)[reply]
Improvement of private vote systems
B This proposal is a Larger suggestion. There is no guarantee this proposal will be implemented. Supporting the idea helps communicate its urgency.
Problem: Chinese Wikipedia plans to use SecurePoll to carry out administrative rights (such as admin and checkuser) elections. There are a number of issues: First, as a workaround the content language must be changed to make interface translated so it would be a pain if other elections are ongoing. Furthermore, many works need to be done to carry out one election, where admin elections may be somewhat frequent.
Proposed solution: # (most important) allow user to view votewiki in specific language (without changing content languages)
allow polls to be created by a community user group without developer effort
For example "bureaucrats" may (1) create new poll (2) strike out ineligible votes and (3) get a tally (thing to consider: to prevent misuse of #3 to get individual votes, either such action should be logged, or after a tally is generated, the poll is locked and may only be unlocked by a steward); stewards may strike votes and do checkusers on voters. (In this sentences it is assumes bureaucrat do not require NDA, but it is also OK to restrict poll management to a NDA group)
(optional) let users to vote in their own wiki instead of votewiki (therefore votewiki will only be used for vote management; or even use another wiki, such as Meta, to manage votes and get rid of votewiki entirely. Frankly I do not know why we need a dedicated wiki for this)
another solution is developing enother extension for private votes, though it is not much realistic
Problem: Commons hasnt received regular maintenance over the last few years, many of the upload tools dont use Two Factor Authentication(TFA), video2commons and videoconvertor both constantly fail especially on large files like those recorded from Wikimania 2021. There have various suggestions as to why this is happening but it comes back to there is no one taking responsibility for the project. Until this is addressed all the projects cant look at implementing newer more user friendly content
Proposed solution: Fix outstand phabricator tickets, and have a dedicated team looking after Commons(Volunteer and Staff)
Who would benefit: readers, content creators, and projects future potential
Hiding the gap to make less visible to wikipedians that there is a gap, is only going to enlarge the gap. You won't be able to move the gap under the carpet permanently. I am afraid to say that actions like this (kind of a dumpster category, instead of keeping it within its adequate context) are the ones that really damage the credibility of the Wishlist. Xavier Dengra(MESSAGES)17:22, 24 January 2022 (UTC)[reply]
Thank you @Xavier Dengra. We (the Community Tech) are quite upfront about this piece but still many people are not aware of that. That worries us, so we're upfront all the more.
In the FAQ, we repeatedly explain that our team is only allowed and able to work on a specific type of tasks. Please read "Does this survey determine all technical changes in Wikimedia?" and "How do I create a good proposal?" (particularly "Less than a year-long project, more than a bug"). The Community Tech can't decide to hire a new team, so this is not a proposal for us, therefore this is not a valid proposal for the Community Wishlist Survey. Instead of archiving such proposals to make them less visible, we make a list of "Larger suggestions". Later, we will share it with our leadership.
In the last three years only 7 of the 25 upvoted proposals were made. Why should we be using our volunteer time to discuss, propose and help in a process that is rigged form the very beginning? Theklan (talk) 09:37, 25 January 2022 (UTC)[reply]
Support: Commons is a mess and as well as being a valuable project in its own right, this has an impact on all us other Wikimedians (such as myself, a Wikipedian). — Bilorv (talk) 16:36, 29 January 2022 (UTC)[reply]
Support Commons, Wikidata is not a "normal" project, it's an international project that many people are choosing this as their main wiki. Thingofme (talk) 14:11, 5 February 2022 (UTC)[reply]
Problem: In some cases of harassment, for example when a long terme abuser discloses personal information about legitimate editors (doxing), there is a need of using private information in an abuse filter (to prevent those information to be disclosed on wiki). As all AbuseFilter editors can currently access it, this is not possible for privacy reasons.
Proposed solution: Create CheckUser-level and Oversight-level abuse filters, only accessible to checkusers and oversighters. Corresponding logs should also be private, obviously.
Who would benefit: AbuseFilter editors, harassed editors, everyone
More comments: Maybe only one type of private abuse filters, accessible to both checkusers and oversighters, would be enough; it remains to be discussed. On the other hand, there may be specific variables handy for checkusers only (see phab ticket below).
@Jules*: Hello and thanks for taking the time to write this proposal. Unfortunately, this is out of scope for our team but an idea that's valid nonetheless. I am therefore moving it to the Larger Suggestions Category. Thanks again! Regards, DWalden (WMF) (talk) 18:02, 24 January 2022 (UTC)[reply]
Support Earlier this year I was actually talking to some of my homewiki (enwiki) Oversighters about something like this. Could be super useful. Giraffer (talk) 22:24, 7 February 2022 (UTC)[reply]
Problem: There is no clean way, with AbuseFilter, to detect an edit is a revert. Which is important, several long term abusers having for habit to revert editors edits as a way to harass them.
Proposed solution: Create a variable revert (if possible with the username of the author of the reverted editor) in AbuseFilter.
Who would benefit: Abusefilter editors, harassed editors, everyone.
More comments: This change has a dedicated phabricator ticket (see below). From what I understand (thanks to Daimona Eaytoy explanations), this task is currently stalled because a change is needed in the mediawiki core code, regarding when abusefilters are processed, and when an edit is marked by mediawiki as a revert.
Thanks for letting know, @MusikAnimal (WMF):. If hope other WMF teams will help to improve AbuseFilters: this is a very useful feature for communities (in order to fight vandalism and also harassment), but the WMF seems not to allocate enough ressources on it. I know that Daimona Eaytoy is working on it, and I have no doubt he's doing good work (it seems there was a lot to do to improve the core code of the extension), but from my non-technical point of view, it seems that there should be more devs on it. And I have no clue how to make this feedback to the WMF.
Problem: Vandalism and spam/promotion is a serious problem in Wikipedia. Fighting it is tedious and boring and sometimes makes the user target of harassment. This is already damaging image of Wikipedia (e.g. Germany's John Oliver did a full story about how spam and promotion is happening and going unnoticed: https://www.youtube.com/watch?v=FNsTaKwyAzI). As pointed out in the story, number of articles to patrol has been doubled in the past decade while number of volunteers shrank to half. WMF hasn't done anything to improve workflow of patrollers in the past five years (the last I remember is RCFilters, then PageTriage but that was only on English Wikipedia). Some Wikis have tried drastic measures such as banning all IP editing that goes against Wiki's guiding principles and harms the wiki in the long-term.
Proposed solution: Expand ClueBot NG to more wikis or build a similar one.
Who would benefit: Editors will be less burdened with the firehose of vandalism and spam and promotion. Readers will enjoy a higher quality Wikipedia.
More comments: Note that ORES is not designed to be used for automatic reverts. It's good at reducing the pool to review (a little, not much because ORES relies heavily on user being logged in or not) but still it's not accurate enough for automatic reverts (I have tried it several times in two different wikis). I also don't mind any other proposal that improves lives of patrollers.
CB NG is old and I don't know how maintained it is, but regardless it would need a new training set for each language.... which I suggested be pulled from ORES, but if ORES isn't good enough, I'm not really sure how well a new bot is going to do. :( --Izno (talk) 00:33, 17 January 2022 (UTC)[reply]
@Izno, this is a rather recent discussion about what you're mentioning, apart from ORES. And this is a discussion started in regard to ORES. ORES and CB look to be, unfortunately, dusty. :/ Klein Muçi (talk) 01:35, 29 January 2022 (UTC)[reply]
For language training sets, language are complex and more spam-related words are different in each language. For global bot Cluebot NG to happen, we need to reform SRG as a page like WP:AIV, which has a bot to function and have a queue job (won't archive at all, like WP:AIV already, have a dedicated page for bot-reports). Some discussions of SRG are lengthy, and it makes a backlog to stewards. Larger discussions will still exist, at the page like Long-term abuse (shortcut: LTA) or other sections of this page, and it would reduce the area of immediate action for stewards. Thingofme (talk) 14:18, 5 February 2022 (UTC)[reply]
Indeed, if ORES isn't good enough, there's nothing Community Tech can build in a reasonable amount of time that will be better. I'm moving this to our Larger suggestions category instead of archiving so this proposal gets the attention it deserves. Thanks, MusikAnimal (WMF) (talk) 22:03, 24 January 2022 (UTC)[reply]
Ah, yes, there was also an email a few months ago in wikitech-ambassadors@ from User:Samwalton9 (WMF) who was researching such anti-vandalism bots. Sadly, I never got to reply to it.
As for the proposal itself, I really like the idea, but IMO it might be prohibitively difficult to accomplish, especially as a universal solution for all projects. PSS 9 has shown some surprising effectiveness in its 5 years of operation, but it's mostly an expert system that took literally years to fine-tune to the specific vandalism in bgwiki. It would fail miserably in any other project and it does fail sometimes spectacularly even on bgwiki—like when 3 years ago it blocked a couple of global sysops (true story).
The bot was developed in response to one group of particularly zestful, resourceful, and cunning vandals, which was a great opportunity to learn about how vandalism works. Simply looking at the content of the edits soon proved to be inadequate, so the bot began correlating different variables and tracking behaviour patterns reaching as far as the choice of usernames. Even speaking of edit content alone, training can be a daunting task—human resourcefulness should never be underestimated.
Despite all the hype, AI can indeed help tremendously: I had disabled PSS 9 several times in the past because of its problems, only to have the community each time ask to have it brought back. But AI also does need tremendous amount of work, and not just in bringing it up to the task, but also in keeping it relevant as the bad actors raise the bar. TL;DR: I'm definitely not saying that the goal isn't worth pursuing, but the huge amount of resources needed must not be underestimated. — Luchesar • T/C14:22, 11 February 2022 (UTC)[reply]
Problem: Every time I go into Wikipedia using Chrome on my Android phone and sometimes when I do so using Safari on my iPad, the Mobile version, not my strongly preferred Desktop version, appears, even though I change it to Desktop every time. This is especially an issue when coming from Google search results.
Proposed solution: Remember the last setting used by this user in this browser.
Who would benefit: Mobile device users who use a browser rather than an app to access Wikipedia.
I've seen similar reports of this but we have never been able to consistently reproduce. The mobile site is currently designed to do this by using cookies. Perhaps there is an issue somewhere in that code or this needs to work without cookies. A bug report detailing information such as browser version, device and version, cookie settings and replication steps would be greatly appreciated and if we are able to reproduce would happily be solved outside the wishlist. Jdlrobson (talk) 16:55, 11 January 2022 (UTC)[reply]
Thank you. In fact, I have mainly encountered this using Chrome on a Samsung 10 phone, where reverting back to Mobile view happens every time. I know it formerly worked properly on my earlier Samsung Galaxy phones - 7, 4, and original Galaxy - and other browsers, including the Samsung browser. I have been using the 10/Chrome combination since September 2019. I rarely encounter it on my iPad Mini 5th Generation using Safari, but sometimes it happens when I choose certain types of Google results. RSLitman (talk) 20:05, 11 January 2022 (UTC)[reply]
Hello and thanks for taking the time to write this proposal. We identified this is related to this task, which is out of scope for our team but an idea that's valid nonetheless. I am therefore moving it to the Larger Suggestions Category. Thanks again! Regards, NRodriguez (WMF) (talk) 00:35, 25 January 2022 (UTC)[reply]
Support Could be something as simple as d.wikipedia.org being automatically desktop regardless of browser in the same way m.wikipedia.org defaults to mobile? DMacks (talk) 21:01, 29 January 2022 (UTC)[reply]
Problem: Mapframe uses the Cartesian coordinate system, which works well across most of the globe. However it breaks down at the poles, displaying a lot of whitespace and massively distorting the lowest/highest latitudes. For a live example, see commons:Category:South Pole Telescope
Proposed solution: Re-render maps that are close to the pole (say, anything above or below 80° in latitude) by rotating them to the equator before displaying them
Who would benefit: Users/editors working on topics that are close to the north or south pole
More comments: I proposed and withdrew this in the 2019 survey. At the time I was thinking of different projections, but a simple rotation avoids this. There is still the issue that editing the map on OSM at the poles is difficult, though.
As some images locations are having different projections in the lower coordinates and poles, I think we should leave it here, like in google maps/earth, after 85 degree north and south it changes to different projection that works on the pole. Thingofme (talk) 01:24, 16 January 2022 (UTC)[reply]
@Mike Peel: Not with our current technology. Instead, if we were to switch to using vector tiles clientside, we can just switch the projection there. Mapxbox has a demo of that available. Vector tiles client side requires integration mapbox gl js, openstreetmap tiles and an vector stylesheet providing the render details for the client. This is a significant amount of work, but would give us all much more flexibility. The static tile rendering we have right now as a fallback however, might not be able to make use of another projection like that. —TheDJ (talk • contribs) 15:41, 16 January 2022 (UTC)[reply]
Hello and thanks for taking the time to write this proposal. We have discussed this proposal as a team, and have identified this is out of scope for our team due to technical complexity but an idea that's valid nonetheless. I am therefore moving it to the Larger Suggestions Category. Thanks again! Regards, NRodriguez (WMF) (talk) 00:40, 25 January 2022 (UTC)[reply]
@NRodriguez (WMF): OK. That's surprising, since I didn't think this had too high technical complexity (tricky, sure, but on the timespan of a year I thought). Would be interesting if you have any feedback on why you think it's so high complexity. But anyway, does this mean this doesn't count towards the limit of 5 proposals, and I could submit another one? Thanks. Mike Peel (talk) 07:34, 25 January 2022 (UTC)[reply]
@Mike Peel: I think the limiting factor here is the Wikimedia maps infrastructure, rather than the technical problem of reprojecting map data. Two probable solutions seem to be to a) serve vector tiles which can be reprojected by the client (although there are issues with this for people with low-powered devices), or b) serve a new set of raster tiles rendered in a different projection. Both are quite large undertakings, when they need to happen at Wikimedia's scale and with our audience. As far as I know the whole maps project is in maintenance-only mode and to extend it with new features is too much at the moment, and definitely too much for our little team. SamWilson02:16, 26 January 2022 (UTC)[reply]
Displaying the map on a 3D interactive globe is probably the best option as it actually shows everything to scale and is inclusive of all regions. Using CesiumJS to do this is an option. Lectrician1 (talk) 21:16, 28 January 2022 (UTC)[reply]
Problem: I want to compare deleted content to live revisions under the same title, or live/deleted revisions for a different title. This is especially useful to check whether a page is a substantive copy of the deleted content and is a key tell to determine whether the author is a sockpuppet. I could do this via Special:Diff or the API... but it is very difficult to discover the revision ID. There should also be associated UI improvements to page history, Special:Undelete and Special:Deletedcontributions to integrate this functionality. The ultimate goal is to demonstrate some user conduct partly based on deleted content.
Indeed, it seems this would involve a substantial reworking of how we store and reference deleted revisions that is going to be too much for our team. As such, I'll move this to the Larger suggestions category. Thanks, MusikAnimal (WMF) (talk) 02:01, 25 January 2022 (UTC)[reply]
Problem: Currently, each wikidata QID entry, representing a concept, are only allowed to link 1 article per each wikiprojects, e.g. each wikipedia language edition.
But there are, for example, Wikipedia written in languages in multiple scripts, that are unable to convert mechanically, and thus require individual articles for each concepts. And then there are also the like of Multilingual Wikisource, Beta Wikiversity, and Incubator, which are designed to contain multiple languages version of same item.
They currently cannot be linked to wikidata normally, and require pre-wikidata-era interwiki links to provide proper inter-language linking between them, and creating wikidata items that are completely duplicate of other existing items, through the property of d:Property:P2952.
This basically rendered wikidata useless for entry in such situation.
Proposed solution: Support more than 1 link to each wikiprojects in each QID
Who would benefit: Anyone who try to use Wikidata expecting each QID to contain all relevant language edition of Wikipedia articles.
Anyone who try to access wikipedia in different languages that are written in more than 1 script.
Such situation is currently handled using the P2952 property in wikidata as mentioned above, in situation as described in discussion leading to the original creation of the property d:Wikidata:Property_proposal/same_as_(permanently_duplicated_item), however this do not actually link different articles/entities from different wikiprojects together as they still have two different QIDs, thus things like interlanguage links and template using wikidata data would not work properly.
Partial fix on interwiki linking have been implemented to the Multilingual Wikisource, by designating the wiki as a multilingual wiki thus links to them are stored differently in wikidata. However, such workaround still unable to make Multiligual Wikisource entry in Wikidata QID item to show up in other language edition panel of wikisource of other languages, as far as I am aware of.
That comment isn't useful for at least cdo and hak (and probably nan?!), as their problems aren't simply "Bonnie and Clyde" articles. Though we could have some COIs about Wikisource (somewhat off-topic), I would still support your such proposals to allow linking multiple links for one Wikidata item on the selected (not all, please, this really needs "blaocklist" by default, and whiteallowlist for some rarely-defined wikis per local and/or meta consensus), but @Superchilum, ChristianKl, and Sannita: do you three still oppose such a solution? --Liuxinyu970226 (talk) 01:41, 17 January 2022 (UTC)[reply]
Just a note on the situation of Multilingual Wikisource: I'm not sure the multiple items problem applies there as much as for Incubator wikis, because separate Wikisource works are supposed to be separate editions and modelled as such in Wikidata (i.e. separate items). SWilson (WMF) (talk) 03:31, 17 January 2022 (UTC)[reply]
But there are also Eastern Min and Hakka pages on mul.wikisource, and for linking them, this solution would still have benefits or otherwise are not possible, isn't right? Liuxinyu970226 (talk) 04:10, 17 January 2022 (UTC)[reply]
@SWilson (WMF): Not all languages get their own wikisource project. Those that don't are designated to be stored on the Multilingual Wikisource (https://wikisource.org). And unlike Incubator, some of those are not expected to become a full wikiprojects in any foreseeable future. See related phabricator task phab:T275958. The phabricator ticket on interwiki link to Multilingual Wikisource through Wikidata is now marked as "resolved" through a workaround, but it still have a few problems, including a.) Link to the project is located under the "In other projects" section instead of the "In other languages" section, making users unable to find the link when they are looking for the text in other languages and also make it not possible for mobile apps and mobile webs to include this in the "other languages" section of those frontends, and b.) It still doesn't appears to allow multiple entry to the Multilingual Wikisource in same Wikidata QID item (Like for example if there is a text in Linear Scrip A and then another text in Linear Script B, with content being the same, after uploading them to the Multilingual Wikisource, it still doesn't seems possible to link both of them in the same Wikidata QID items and it would still be impossible to link to both of them from, say, English Wikisource, through the "In other languages" section of the toolbar.) C933103 (talk) 07:38, 17 January 2022 (UTC)[reply]
@C933103: You're right, it's not ideal. I think the problem is not with sitelinks though, but with the need to have two pages on one Wikisource that are of the same thing (i.e. in two different scripts). It seems like it'd be better to keep the "one page, one concept" idea (and so have singular sitelinks), and fix the other issues where they occur. That said, it looks like trying to resolve all of this is too big for CommTech to achieve within a reasonable time, so we've moved this to 'larger suggestions' (where it can still be voted on, and the relevant team will be able to act on if appropriate). SWilson (WMF) (talk) 03:12, 25 January 2022 (UTC)[reply]
I cannot see that as a good way of organizing content on Wikisource when Wikisource usually have even different copies of same document in same language on different pages. C933103 (talk) 16:15, 25 January 2022 (UTC)[reply]
There are three groups of wikis.
One (biggest) have always 1 page for 1 item - this is valid for majority of wikis.
Second - multilingual - are dedicated to be multilingual, have usually multiple pages for 1 item, but every page have it'S own language (betawikiversity, incubator, maybe commons galleries, language specific pages (eg. village pumps) in meta, commons, wikidata etc.)
And the last group are (usually) wikipedias and mul.wikisource with more pages for 1 item, which differs in script or dialect. But probably these can be defined - there is probably no need for this in most of main languages and large wikis. And this should be solved by adding second (third...) language link
Let'S imagine, there is language XX which should have two entries for every item. For ordinary wiki we write langcode (en, de, cs) or name (enwiki, dewikibooks, cswikinews). For XX we should use xx or xxwikipedia, when need to add second page xx1 or xx1wikipedia. (the first link should have alias xx0) This can be easily stored; can be both be written in sitelinks list and probably should be patch for recognizing [[xx0:Foo]] and [[xx1:Φοο]] as valid interwiki for xx.wikipedia. (I found case, when lad.wikipedia have three entries (2, 3), so simly use lad2.wikipedia, and hope than no more than 10 entries will be for one item in one wiki). JAn Dudík (talk) 09:33, 17 January 2022 (UTC)[reply]
Oppose This is absolutely not a viable solution. The 1:1 linking on Wikidata has a reason to be, and Wikidata should not adapt to what other projects do, since it is a project with its own standing and its own purpose. What should be done is try to find a concerted solution all together - Wikidatans, Wikipedians, and Commonists - on how to overcome such a situation. Every project has its rights to its own particular situation, and so does Wikidata - it's been 9+ years of life for Wikidata, and people still do not understand this. --Sannita - not just another it.wiki sysop11:14, 17 January 2022 (UTC)[reply]
P.S. This, of course, does not apply to beta projects, mul.wikisource, and the likes - which all come with their own set of problems. I am merely talking about the rest of the projects and the perennial discussion about duplicated items, which should be solved by the communities by talking to each other, and not forcing solutions down people's throats. Sannita - not just another it.wiki sysop11:21, 17 January 2022 (UTC)[reply]
Why should not? This is already a blocker of deploying phase I (sitelinks support) for Incubator as per 2016 Wishlist. Just remember: Not all people like the de facto 1:1 link schemes, there are really peoples to break it down. Or, do you really know what cdowiki and hakwiki wanna have?! Liuxinyu970226 (talk) 14:04, 17 January 2022 (UTC)[reply]
The current use of permanently duplicated item is not going to benefit wikidata more than the proposed approach. Since wikipedia articles are being linked into multiple different entries on wikidata, all the data field in the two different QIDs could not be shared, and result in data quality discrepancy. Not to mention people from outside WMF projects, like even Unicode emoji proposals, are trying to adopt QID as an identifier on objects, and by keeping the QIDs non-unique for each concept does not appears to be a good idea for data consumer either. C933103 (talk) 21:50, 17 January 2022 (UTC)[reply]
There are two articles on Wikipedia featuring content correspond to same QID. You say you are not a fans of storing the two articles on two different QIDs. Yet you are against storing them on the single one QID. So what are other possible alternative solutions? Not storing them at all? Or storing them in even more numbers of QIDs? C933103 (talk) 12:11, 24 January 2022 (UTC)[reply]
If there is the problem of recalling the right data from the right item, it can already be done with arbitrary access. As simple as that. It's a rough patch, but it works, and it doesn't require years of destroying and reconstructing a software, just because.
The problem with wikis such as nap, eml, cdo, hak, etcetera is that we are asking users to do the same articles all over again two or more times, just because they need to switch the script or the local variant. This to me is the real problem, and it will not be solved by violating the 1:1 rule on Wikidata, but investigating a way to make easier switching between scripts/variants.
Will it take time? Yes. About as much time it's taking to realise the 2016 wish to make Incubator and Multilingual Wikisource linkable by Wikidata (which is based off the idea of violating the 1:1 rule of linking), but at least we'd be asking the right request to devs. Sannita - not just another it.wiki sysop20:41, 24 January 2022 (UTC)[reply]
The solution of hosting multiple scripts as different articles on Wikipedia have long existed before the creation of Wikipedia, and breaking this will also break the Language Committee policy unless in specific situations according to my understanding, in addition to causing difficulty in navigation.
There are already Language Converter in the Mediawiki software which handle situation where such conversion is possible, but Latin to Han character conversion is not among such circumstances. First of all, in addition to characters with exactly same pronunciation, the romanized writing system of the Chinese languages do not include tones, which increase the number of possible Han character with same romanized spelling by a couple of times, requiring human to select characters for each word from candidate list if one is typing Han character through such romanization scheme. It is not realistic to combine both versions of articles into a single one just to have every single words notated with proper character, creating a source code for each articles that no one can easily understand or edit. In addition, imported words are also treated differently according to script versions. Romanized writing system would simply include the Latin script name of foreign words when they're importing such words, except for some with established localized name, however the Han character version always have to translate these words into Chinese characters by identifying whether they should be translated phonetically or contextually, and that which characters among homonyms would fit the context of the word the best if phonetic translation is opted. This process is not something that can be automated. In some case, depends on the words being imported, like if you say the word "Googling" devised from the word "Google", in romanized text it would be reasonable to keep such word in the sentence, however in Han Character edition it would be necessary to reword the entire sentence structure to write it out with Han script. In order words, this is the sort of translation that even Google Translate with their machine learning couldn't perfect, and I think it would be much easier for Wikidata's system to adopt for actual real world usage by numerous Wikis than to rework all the relevant wikis according to Wikidata's standard, not to mention doing so require something even more powerful than the best commercial translation software in the world nowadays.
And that is not to mention the like of Multilingual Wikisource, which the project goal outright state that they are supposed to contain text of multiple languages. And of course, even if automated translation is available, it wouldn't make sense to use them on Wikisource, because Wikisource is supposed to keep the original form and spelling and word choice of text, unless translated versions.
As for "investigating a way to make easier switching between scripts/variants", that is of course also part of the problem. Currently there are only 1-to-1 linking within each Wikipedia. Such interarticle linking was the supposed purpose of the development of Wikidata. If Wikidata couldn't handle this, then should additional Wikibase instances be installed at every relevant Wikiprojects, so as to allow linking between different projects linking within themselves, and have Wikidata pointing to each of those individual Wikibase instances? I don't think that is something desirable to anyone due to complexity in operation and maintenance. C933103 (talk) 13:27, 25 January 2022 (UTC)[reply]
I am here to clarify what I mean: Min Dong is written in Han script (cdo-hani) and Latin script (cdo-latn), so we introduce two virtual site id: cdo-haniwiki and cdo-latnwiki. Users can add sitelinks to these two virtual site ids. Wikibase will map them to pages in cdowiki and guanaratee one cdowiki page may only be linked once. Another example in Alemannic Wikipedia, you may introduce "alswikisource" vitrual site id and link pages there which automatically maps to alswiki page.--GZWDer (talk) 20:15, 17 January 2022 (UTC)[reply]
@GZWDer: you propose xx-variant, I propose xx1, technically the same ;-) But xx-variant is better for case this feature is limited to certain wikis. xx1 is more universal, but means more mess JAn Dudík (talk) 07:16, 19 January 2022 (UTC)[reply]
Just my 2 cents, how about linking dependent pages (/doc, /styles.css, /LANGCODE, ...) to a section named subsitelinks or similar? Therefore, d:WD:N will not be violated, as they won't get an item for their own, and users who want to read, say, template documentation on other wiki can quickly find what they need. NguoiDungKhongDinhDanh21:06, 3 February 2022 (UTC)[reply]
Support Opposing this will also oppose many communities that are interested in multiple scripts, this is inappropriate for at least Asian users. About some oppose comments like "this is absolutely not a viable solution", I would say that permanently duplicate items are even not a solution, they are dummy items. --Liuxinyu970226 (talk) 08:03, 29 January 2022 (UTC)[reply]
Oppose I would rather prefer we take the time to build a system that allows Wikimedia project pages to link to their relative Wikidata item instead of Wikidata items linking to their relevant pages using the sitelink system. That way we can stably have multiple pages link to one item. Lectrician1 (talk) 20:42, 29 January 2022 (UTC)[reply]
Such alternative approach can only provide unidirection link from individual wiki article to specific wikidata item, and cannot enable linking into those affected articles. Making those articles similar to orphan pages. C933103 (talk) 10:27, 30 January 2022 (UTC)[reply]
Hence that's part of the reason why current approach is not sufficient, without getting into more in-depth cases of wikidata usages C933103 (talk) 17:26, 1 February 2022 (UTC)[reply]
Strong oppose As I already said during the discussion phase, this is absolutely not a viable solution. The 1:1 linking on Wikidata has a reason to be, and Wikidata should not adapt to what other projects do, since it is a project with its own standing and its own purpose. If there is the problem of recalling the right data from the right item, it can already be done with arbitrary access. As simple as that. It's a rough patch, but it works, and it doesn't require years of destroying and reconstructing a software, just because. Moreover, what should be IMHO done is try to find a concerted solution all together - Wikidatans, Wikipedians, and Commonists - on how to overcome such a situation. More specifically, the problem with wikis such as nap, eml, cdo, hak, etcetera is that we are asking users to do the same articles all over again two or more times, just because they need to switch the script or the local variant. This to me is the real problem, and it will not be solved by violating the 1:1 rule on Wikidata, but investigating a way to make easier switching between scripts/variants. Will it take time? Yes. About as much time it's taking to realise the 2016 wish to make Incubator and Multilingual Wikisource linkable by Wikidata (which is based off the idea of violating the 1:1 rule of linking), but at least we'd be asking the right request to devs. Sannita - not just another it.wiki sysop12:03, 31 January 2022 (UTC)[reply]
Note that those are also "the 2016 wish to make Incubator and Multilingual Wikisource linkable by Wikidata (which is based off the idea of violating the 1:1 rule of linking)" is also part of the wish here as that doesn't seems to be fully implemented C933103 (talk) 17:39, 1 February 2022 (UTC)[reply]
Oppose Rendering a page in more than one script is a valid problem that should be solved, but not by breaking a fundamental principle on which Wikidata is built. Silver hr (talk) 15:21, 3 February 2022 (UTC)[reply]
It have been analyzed and concluded as cannot be solve, because each script lack necessary information to be convert to another script. C933103 (talk) 17:53, 3 February 2022 (UTC)[reply]
If the problem for converting some scripts is missing information, then that's a subproblem that should be solved by adding the missing information. Silver hr (talk) 21:01, 3 February 2022 (UTC)[reply]
@Silver hr: The scripts are structured as do not write in such information. As an example, English as we are writing here cannot be convert into IPA-script, because when we type English with these 26 characters, we do not specify which type of accents we are speaking in. Your proposed solution is like reforming the English writing system and add extra symbols and markings into it so that it can reflect phonetically how different people speak different words in different occasions. C933103 (talk) 13:43, 4 February 2022 (UTC)[reply]
@C933103: English can be converted into IPA, either by specifying a particular pronunciation, or by using the standard pronunciation (or if there's no official standard, some sensible default). As I said, the problem you're presenting is valid, but it seems you're too fixated on a single, non-optimal solution. Let's find better solutions by discussing the actual problem. Silver hr (talk) 17:10, 4 February 2022 (UTC)[reply]
@Silver hr: Yes, imagine requiring editors "specifying a particular pronunciation" for every words in English Wikipedia when editing and see what hassles that would be. This would be what you are proposing to necessitate conversion of articles written in Abjad scripts, which do not usually have vowel, into other scripts, or converting articles written in Latin or Syllabric script, which do not carry the etymology of each sound, into different Han characters. Not to mention special orthographical rules. You can try to match each character to a default, but the conversion is far from guaranteed to be correct because there are many possible corresponding output for quite a number of single input.
Language Converter facilitate such conversion, and also allow specifying special conversion rules for each conversational topics and each individual Wikipedia articles, but using Chinese Wikipedia as example, despite there're only a small part of the Chinese script that have special non-1-to-1 conversion rule between Traditional and Simplified script, and even after all the aforementioned conversion table at various levels being implemented, it is still not without additional burden on editors having to fix incorrectly converted words inside article text, and every once in a while there are still incorrect conversion that need customization of rules to match usage conversion, and that's after 2 decades of continuous work to make it as functional as in current state, and this is for such a large wiki as in Chinese Wikipedia. I simply cannot see it as workable in languages where its different scripts have more complex relationship between each others than the two Chinese scripts, or in cases where it is "just" as complex but doesn't have as much users to maintain, or when only a relatively small portion of the whole wikiproject user base is interested in the non-mainstream version of script.
Note that, even if a conversation system have 99.99% accuracy in converting one word in one writing system to another, when you apply it to a 5000-words article, by binomial distribution, it would still mean there would be 40% chance at least a word in the article will be converted incorrectly. And that's just one article. C933103 (talk) 23:14, 4 February 2022 (UTC)[reply]
@C933103: In this hypothetical example, editors specifying a particular pronunciation for every English word would not be necessary. If one wants to read an English article in IPA script, one would select a pronunciation and the whole article could be automatically converted because the conversion is already defined for every word. If it is important that a particular word have a particular pronunciation, then an editor can specify that as a manual override. I don't see why conversions between other writing system pairs couldn't be defined as well. From what you're saying, it can be a lot of work, and I'm sure it is, but the amount of work is finite and it'll get done at some point. Until it is, we'll have to deal with imperfection and fix mistakes when we see them, which is pretty much standard for volunteer projects. Silver hr (talk) 01:56, 5 February 2022 (UTC)[reply]
What is the point in viewing the one-one policy in Wikidata? Language converters can't work in some titles, but for example: we type a page title in zh-tw (Taiwanese dialect of Chinese), it sometimes say "This page is auto-redirected to proper zh term article, or manual redirect (with tw template) (I don't know Chinese, so I can't give any examples). Sometimes, it does not exist and we have to search it. Also, we need to improve auto-redirect by capitalization. And Wikidata would work as the same way as before. Thingofme (talk) 14:27, 5 February 2022 (UTC)[reply]
@Silver hr: Please see the table at w:en:Heteronym_(linguistics)#English, it have to either be specified or guessed each instances these words appear. And then this list of English word having such problem is just a minor part of English language, and many of the languages I mentioned before have the same problem for essentially all words in the language. C933103 (talk) 14:45, 5 February 2022 (UTC)[reply]
@C933103: Right, so the problem is that by just looking at a single word, out of context, it can be impossible to determine its meaning, such as lead the element vs lead the activity. The solution I prefer is to enable editors to express their meaning clearly in such cases (with defaults selected according to grammatical, and potentially semantic analysis). If a language exists where such ambiguity of meaning between different writing systems is the rule instead of the exception, then it makes more sense to treat them as different languages, at least from a technical standpoint. Silver hr (talk) 17:11, 5 February 2022 (UTC)[reply]
@Silver hr: Yes that is a proposed solution to the wish from GZWDer and JAn Dudík in the discussion section above. But again my concern is whether it's going to be even more technically complex than my proposed form of implementation. However I am open to whichever form of possible implementation that can get the task done. It would probably be up to anyone who end up changing the code to decide which is easier to implement. C933103 (talk) 17:47, 5 February 2022 (UTC)[reply]
Comment Regarding LanguageConverter, it's confirmed impossible for Romanian due to political problems accounted by another RFC, and could be hard-than-world for each Min languages and Ladino as explained by each Wikipedias. See also Wikipedias in multiple writing systems, and feel free to add informations if you know. Liuxinyu970226 (talk) 04:14, 6 February 2022 (UTC)[reply]
@Liuxinyu970226: Romanian script conversion is not impossible because that would mean it's contrary to the known laws of physics. And I do realize it's a hard problem in some instances, but solving a problem the right way is worth it, no matter the difficulty. Silver hr (talk) 06:23, 11 February 2022 (UTC)[reply]
Support only in Incubator, Old Wikisource and Beta Wikiversity (should merge Beta Wikiversity and Incubator), and each test wiki only has 1 link, and Oppose for others. No need to do this at all (but conversation of Chinese scripts are concerns) Thingofme (talk) 14:22, 5 February 2022 (UTC)[reply]
On for example Minnan and Hakka projects, the topic of concern is to link to Han script pages in addition to Latin script page, as it isn't possible to convert from Latin script to Han script with reasonable accuracy. C933103 (talk) 14:46, 5 February 2022 (UTC)[reply]
Oppose This doesn't exactly sound like a Wikidata issue — if the issue is language conversion, maybe we can find other ways to do it in the wikis where it is a problem. Xn00bit (talk) 09:23, 8 February 2022 (UTC)[reply]
It have been explained that automatic language conversion is not possible and thus the fastest way is manually retype the article in different scripts. C933103 (talk) 20:33, 8 February 2022 (UTC)[reply]
Support either this proposal, or Lectrician1's idea. This is definitely needed for the wikipedias: different language versions make different choices about how to partition topics (and groups of topics) into articles, and there are many, many cases where there isn't anything like a 1:1 match between articles. See d:Wikidata:WikiProject Cross Items Interwikis (and also e.g. this discussion for the quandaries that arise when dealing with articles about single-species genera, of which there are thousands on the English Wikipedia). Uanfala (talk) 23:14, 10 February 2022 (UTC)[reply]
Problem: When people make edits, sometimes, they tend to word it wrong or miss some kind of punctuation. That makes it hard to read, people don’t understand.
Proposed solution: A built-in grammar editor that corrects edits you make. For example, if I wrote “An win in Week 18 sealed afc east for bils”, it would be corrected to “A win in Week 18 sealed the AFC East for the Bills.”, with an explanation.
Who would benefit: People who read Wikipedia, and the editors, they know how to word something next time.
More comments: I would like to add my own insight and contribute to this if my idea goes through, really hoping it will. There are lots of edits out there with messed up grammar, and I want to fix it. Thank you for taking this into consideration.
I doubt it could be done reasonably. Take something like Grammarly, for example, which commonly makes lots of mistakes and something like this would be difficult to make in a very exact manner. MrMeAndMrMeContributions22:10, 11 January 2022 (UTC)[reply]
In the past, amongst devs, I have seen some that believe that grammar should be done from within the browser and is therefore the responsibility of the user. When considering a service like Grammarly of course one has to consider what happens with our requests and if our writing is being stored on some server after being processed. So it's a really nice idea to consider having a related functionality in the editor that we can trust.
I have been asking around about this within the members of the editing team to find out if anything related exists on their roadmap.
Some things that stood out are that they are two challenges to this:
1. right now we don't have a UI to show suggestions to the user
2. we would need an open source grammar library that would provide these suggestions
The editing team has been thinking about alternative which would be allowing contributors to suggest grammar corrections.
In addition to that there's two ideas that some teams have been discussing that are somewhat related that we would like to share here to discuss and would love your input on the talk pages:
- Growth team’s “copyedit” structured task: this is an idea that would propose copyedits to users one at a time for them to correct, they would be surfaced in a different feed though
This is a great summary of what the Editing Team has been thinking about as it relates to providing people feedback, in real-time, about the edits they are making...thank you for sharing it here, @KSiebert (WMF)!
Browsers already have grammar spell checking, and there are tools like grammarly etc that will be much better at this than we can ever be (and they, a company with 800 employees, is already not too good at it). Language is hard. —TheDJ (talk • contribs) 10:49, 12 January 2022 (UTC)[reply]
If implemented please make this optional because it could significantly increase page load time over slow internet. — The preceding unsigned comment was added by C933103 (talk)
Since something along these lines is already on the Editing team's radar, there's no need for us to step on toes or invent something different. But I assume by allowing this to go into voting, we could get valuable feedback from the community and the show of support could illustrate how important it is to the community, so I'll move this to our Larger suggestions category. Thanks, MusikAnimal (WMF) (talk) 04:00, 25 January 2022 (UTC)[reply]
C933103> "If implemented please make this optional ..."
Yes, a configuration switch to disable is essential. Absence of an unwanted automation is worse than imposition of it.
Problem: Templates are different on each wiki and language edition. When you edit in multiple languages or multiple wikis, you have to re-learn the syntax for the templates. For example, in English Wikisource, writting "wikisource" hyphenated on two pages would be {{hws|wiki|wikisouce}}, while in the French Wikisource, it would be {{tiret|wiki|source}}. This makes contribution in multiple languages really difficult.
Proposed solution: Have a global library of templates and Lua modules, where it is possible to access the templates from any wiki.
Who would benefit: Anyone contributing in multiple languages or on multiple wikis
We have archived Make enWiki templates available in deWiki as Vorlage as a duplicate of this proposal. The concept of Global templates was declined in a previous survey, as it was simply too large of a project for our team. See our FAQ for more information on the scope of this survey. This proposal is however an ideal candidate for the new Larger suggestions category, where we advertise and allow voting on wishes for other teams and the broader movement's benefit. I do think this proposal needs some rewording, first. We'll want to point out mw:Global templates as well as Wikitemplates, etc. @Cassiodore89: Would you mind I tweak your proposal to more clearly say the current state of affairs and previous attempts at solving it? MusikAnimal (WMF) (talk) 04:30, 25 January 2022 (UTC)[reply]
Support Reduce the workload by a lot. Most local templates are copy and pasted from enwiki anyway, then became outdated fast, and increasingly too much to maintain FenyMufyd (talk) 17:14, 31 January 2022 (UTC)[reply]
Problem: Data in articles is stored in raw text and often unspecifically referenced. That same data is or could be stored and cited from Wikidata and be directly referenced.
Proposed solution:
When editing an article, a system automatically recognizes textual data in articles that could be represented on Wikidata and shows small prompt dialogs by the statements asking the user to convert the text to a template that derives data from Wikidata such as Template:Wikidata (Q8478926). If the statement does not exist on the article's or a related item yet, the system will prompt the user to create the statement and will provide a UI in the article to do so. If reference(s) are nearby the statement, the system will also be able prompt the user if they want to use that reference for the statement.
Example usage: A user is editing Barack Obama. A small dialog box appears above the text/wikitext He graduated with a [[Bachelor of Arts]] degree in 1983 and a 3.7 [[Grading (education)#United States|GPA]]. stating, "This phrase can be converted to be sourced from Wikidata." If the user selects to do so, the phrase will reference this statement on Obama's item and the text/wikitext will be replaced with: He graduated with a {{Wikidata|qualifier|linked|P69|Q49088|P512}} degree in {{Wikidata|qualifier|P69|Q49088|P582}} and a 3.7 [[Grading (education)#United States|GPA]].
Who would benefit: All projects. When statements with references are added to Wikidata, anyone on any wiki can use that data.
Identifying wikidata statements from natural language might be a huge project. I think it is better to create a tool to make referencing statement from wikidata more easier. Integrating SPARQL or Wikidata Query Service into VisualEditor or WikiEditor may also be a good idea. --Steven Sun (talk) 01:31, 12 January 2022 (UTC)[reply]
@Matěj Suchánek Yes, I know that the system would have to be optimized for other languages and their grammatical structure.
Also, I don't see Abstract Wikipedia as replacing Wikipedia anytime soon or maybe even ever (I still love it though :) ). Human-edited Wikipedia articles are still going to exist. Having Wikidata-sourced data wherever possible will benefit them because that way we know the data mentioned in the article and between articles of different languages is consistent and has a source. Lectrician1 (talk) 19:34, 12 January 2022 (UTC)[reply]
This would not really be accepted in all projects. In the majority of cases where the issue of lack of wikidata use has come up on wikidatas own Project chat, the issue has been a lack of actions against vandalism.--Snævar (talk) 11:43, 12 January 2022 (UTC)[reply]
(Edit conflict.) I'm struggling to see the benefit of this. from an editing perspective the original text is explicitly clear - say that you needed to change 1983 to 1984, even if this is someone's first time ever editing a wiki it's fairly obvious what they need to change. The replacement is a complete mess with templates plonked in the middle of sentences which make the text realy hard to read, and doing something as simple as altering a date requires you to understand the property and item structure of wikidata and to go to an entirely different project. The data you've given as an example here is completely static and is never going to change, so I don't see the need to load it from a database rather than just hardcoding it. You also state that this would improve referencing, but in the original article this statement is properly sourced to his profile on a university website (at the end of the sentence, right next to the text you quote) while wikidata is sourced to "Imported from the English Wikipedia", this seems to be about normal for wikidata entries, even in an entry like Barak Obama most of the data is unsourced. This also opens up another vector for vandalism to creep in to pages as information in the article is now dependant on another project. Per above if you want to write articles pulling all their information from wikdata Abstract Wikipedia is the project to look at. As a final point the use of wikidata in articles is highly contentious, at least on the English project, something that the proposer should be well aware of given that they have spent the last year trying to get wikidata integrated into wikipedia only for their proposals to be repeatedly rejected (e.g. [9][10][11] and others) This tool would almost certainly not be allowed to run on the English Wikipedia (other projects may think differently) and the text of this proposal (mentioning adding wikidata info to articles on the English Wikipedia) does seem to be an attempt to bypass the existing consensus of the English Wikipedia with an official WMF tool. 86.23.109.10112:08, 12 January 2022 (UTC)[reply]
Please assume good faith. Three is no evidence whatsoever that this is "an attempt to bypass existing consensus of the English Wikipedia". The OP has only a few edits on that project, and is mostly active elsewhere. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits13:03, 12 January 2022 (UTC)[reply]
I'm struggling to see the benefit of this. from an editing perspective the original text is explicitly clear - say that you needed to change 1983 to 1984, even if this is someone's first time ever editing a wiki it's fairly obvious what they need to change.
I would also agree that it is very obvious and simple to change the value. But what if that value is used on other language Wikipedias or is mentioned multiple times in an article? Their values won't be changed... Or, what if someone wants to add another reference for a value? Nobody can reasonably do all of those things on every language Wikipedia. But with Wikidata, you can!
The replacement is a complete mess with templates plonked in the middle of sentences which make the text realy hard to read, and doing something as simple as altering a date requires you to understand the property and item structure of wikidata and to go to an entirely different project.
The current state of Wikitext on articles is already an unreadable mess of templates, links, and references. But, we have the Visual Editor for a reason! I believe that the increased usage of templates will benefit the quality of articles much more than the tradeoff of the Wikitext being a bit more of a mess than what it already is.
The data you've given as an example here is completely static and is never going to change, so I don't see the need to load it from a database rather than just hardcoding it.
The reason this example is beneficial is because we can directly derive the reference for the data. With the current state of references often being placed at the end of sentences, we can't easily do this. Also, if someone wanted to add another reference for the data in the future, they could do this and all other wikis that fetch the data would have it. Finally on a less-useful-note, finding out where and how Wikidata data values are referenced on Wikimedia projects could be useful for data analysis in the future.
You also state that this would improve referencing, but in the original article this statement is properly sourced to his profile on a university website (at the end of the sentence, right next to the text you quote) while wikidata is sourced to "Imported from the English Wikipedia", this seems to be about normal for wikidata entries, even in an entry like Barak Obama most of the data is unsourced. This also opens up another vector for vandalism to creep in to pages as information in the article is now dependant on another project.
That's why we would require fetched values to have actual references. Also, as explained in the proposal, the system will be built to look for references nearby the data and prompt the user which they would like to add them to Wikidata. That should help clean up those "Imported from the English Wikipedia" references.
Per above if you want to write articles pulling all their information from wikdata Abstract Wikipedia is the project to look at.
See my response to that above.
As a final point the use of wikidata in articles is highly contentious, at least on the English project, something that the proposer should be well aware of given that they have spent the last year trying to get wikidata integrated into wikipedia only for their proposals to be repeatedly rejected (e.g. [1] [2] [3] and others) This tool would almost certainly not be allowed to run on the English Wikipedia (other projects may think differently) and the text of this proposal (mentioning adding wikidata info to articles on the English Wikipedia) does seem to be an attempt to bypass the existing consensus of the English Wikipedia with an official WMF tool.
Hopefully the tool will be easy to use and recognizably useful enough for editors to realize it's benefits. My goal is not to bypass an consensus. I just want to offer ideas that will improve the state of all wikis, not just the English Wikipedia.
At most a value is going to be used three times in an article - the body, the lead and the infobox, updating all three together is not a massive deal and if you're changing figures you will often need to adjust other things to make sure the text still makes sense. You could update articles in other projects, but personally I don't think it would be a good idea for me to be changing sentences in languages I don't speak and am therefore unable to check.
I don't use the visual editor regularly because I find it slower than editing wikitext, but my experience is that editing templates in it is a chore. If we were to implement your proposal when you try to edit an article seemingly random bits of sentence won't be editable as text and instead will require you to navigate multiple layers of pop-up menus to fill in "P" and "Q" values, or to go to another project. it's still a much worse experience and would be completely inaccessible to a large number of users.
The reason that references are placed at the end of sentences is that the entire sentence structure needs to be sourced, not just the random data points within it - The way you present data can completely change it's meaning. References in articles are going to stay, so I think that wikidata references would simply duplicate what is already there.
Vandalism is only one small part of the reason why Wikipedias are unwilling to use Wikidata, an equally big issue is that most of the contents of Wikidata are unsourced and are generated by bots, user scripts and tools using a combination of guesswork and pattern matching. Last time I was there I saw bots doing all manner of slightly iffy things, e.g. guessing people's gender based on their first name. Wikipediocracy currently has a post on it's front page about an actress who had fake porn accounts added to her Wikidata item, these weren't added by a vandal, these were added by a user with hundreds of thousands of edits because they were using a semi-automatic tool to match up pornhub account names with people.
It's also trivial to come up with examples where it is not possible to map information in sentences 1:1 to wikidata statements. Consider the sentence "In 1945 John Doe moved to Exampleville, where he founded his first company, widgets Inc" what do you link the "1945" to, the date when he moved or the founding date of his company? What do you link "Exampleville" to, his place of residence or the location of the company? This kind of stuff is going to show up all the time when dealing with actual articles.
In summary:
Projects are not willing to use Wikidata in it's current state for a variety of reasons including vandalism, the large amount of unsourced or poorly sourced data, it's poor implementation/enforcement of policies regarding things like protection of living people and privacy etc.
I don't think that the "after" wikitext is an improvement, I think it would be slower and more difficult to write and edit and such editing would be inaccessible to a large number of people who are not familiar with wikidata. The contents of the text is also now dependant upon another project.
Wikidata usage in articles is highly controversial in some projects - in my estimation the probability that this tool would be allowed to be used on the English Wikipedia is approximately 0%. I imagine that the situation would be similar on at least a few of the other WMF projects.
At most a value is going to be used three times in an article - the body, the lead and the infobox, updating all three together is not a massive deal and if you're changing figures you will often need to adjust other things to make sure the text still makes sense. You could update articles in other projects, but personally I don't think it would be a good idea for me to be changing sentences in languages I don't speak and am therefore unable to check.
You're not changing sentences in other articles. You're changing a single data value that is comprehensible in any language. Didn't you see my example? All Wikidata replaces is "Bachelor of Arts" and "1983".
I don't use the visual editor regularly because I find it slower than editing wikitext, but my experience is that editing templates in it is a chore. If we were to implement your proposal when you try to edit an article seemingly random bits of sentence won't be editable as text and instead will require you to navigate multiple layers of pop-up menus to fill in "P" and "Q" values, or to go to another project. it's still a much worse experience and would be completely inaccessible to a large number of users.
The reason that references are placed at the end of sentences is that the entire sentence structure needs to be sourced, not just the random data points within it - The way you present data can completely change it's meaning. References in articles are going to stay, so I think that wikidata references would simply duplicate what is already there.
I don't think placing a reference directly next to a data value is bad if that's what the Wikidata template was going to do (or it could do something else!). It tells users exactly where a fact came from. You can still maintain the references at the end of a sentence if you want. In general, I think references need to restructured to somehow link or "surround" the text they are directly referencing for. Arbitrarily placing references at the ends of sentences and paragraphs confuses machines and readers alike.
Vandalism is only one small part of the reason why Wikipedias are unwilling to use Wikidata, an equally big issue is that most of the contents of Wikidata are unsourced and are generated by bots, user scripts and tools using a combination of guesswork and pattern matching. Last time I was there I saw bots doing all manner of slightly iffy things, e.g. guessing people's gender based on their first name. Wikipediocracy currently has a post on it's front page about an actress who had fake porn accounts added to her Wikidata item, these weren't added by a vandal, these were added by a user with hundreds of thousands of edits because they were using a semi-automatic tool to match up pornhub account names with people.
Um, machines are not going to be adding data from Wikidata to Wikipedia. Instead, humans are because they can actually check the data and its references and appropriately use it. All machines do in this proposal is prompt users to use Wikidata where it could be used. It doesn't execute any edit on its own. Also, as I've said before, all data fetched and inserted from Wikidata to Wikipedia must be sourced and the source reviewed by a human. Despite Wikidata containing bad data (which I completely recognize), none of it should enter Wikipedia. And if it does, watchers would see the change and revert it.
It's also trivial to come up with examples where it is not possible to map information in sentences 1:1 to wikidata statements. Consider the sentence "In 1945 John Doe moved to Exampleville, where he founded his first company, widgets Inc" what do you link the "1945" to, the date when he moved or the founding date of his company? What do you link "Exampleville" to, his place of residence or the location of the company? This kind of stuff is going to show up all the time when dealing with actual articles.
This is why we separate and linked items that describe each of these things in their associated contexts. Also, this system does not have to analyze every place where Wikidata could be used the day it launches. Complex sentences like that would require a lot more neural network training and configuration. There are potentially billions of simple single-subject statements on millions of articles across the English Wikipedia that the system would be able to recognize and correctly replace with Wikidata. That kind of power delivered by a such a tool even for simple sentences in articles would be extremely incredibly beneficial for the wiki as a whole.
I have serious doubts that it would even be feasible to build this tool.
It's completely feasable. If there are neural networks out there that can create original creative works or drive a car, we can totally make one that can recognize data in simple sentences. Lectrician1 (talk) 02:07, 14 January 2022 (UTC)[reply]
I think Wikidata is a big data in information and we can do that if we need. However, this require complex analysis from natural language to coding language and statement trees, and we can change something called items or property in Wikidata. However, I think we should use this idea in other languages, to not have to update information in all projects, only changing in Wikidata. Thingofme (talk) 07:47, 14 January 2022 (UTC)[reply]
Please don't underestimate how many people are working on Tesla's neural net for over 10 years now.. The problem is not technical feasibility, it's how much work would be required to achieve that technical level. —TheDJ (talk • contribs) 15:02, 16 January 2022 (UTC)[reply]
@Lectrician1: It looks like there are two parts to this proposal: a way to add Wikidata values to Wikipedias, and an automated way to highlight particular sentences into which the data might be added. The first can be done with existing functionality (as you point out) but is controversial on some wikis; this is a matter of wiki policy, and it's not something that the CommTech team can do anything about. The second is not currently a feature, and is technically very challenging, probably more than a year; it is, however, a valid proposal, so I'll move this to larger suggestions. Hope you understand and aren't too disappointed that CommTech won't be able to work on it. — SWilson (WMF) (talk) 07:00, 26 January 2022 (UTC)[reply]
Oppose: a steeper learning curve to newbies editing and a phenomenally less user-friendly wikitext for experienced editors is not worth it for a utopian Wikidata pipedream that has proved to do nothing except increase attack surface for vandals so far. — Bilorv (talk) 16:50, 29 January 2022 (UTC)[reply]
This system seeks to make a user-friendly UI that shows the user how to link data present in articles to Wikidata. Users don't even need to know what Wikidata is. The message could just say, "Do you want to link this data to a database?". It shouldn't impact learning how to edit at all.
Wikitext already isn't user-friendly or readable. Adding a basic template to fetch a data value from Wikidata isn't going to impact the Wikitext much. This is also why we have the visual editor.
Problem: Wikipedia (among some other Wikis) have the strict Neutral point of view (or NPOV) policy, but there are some users that don't know it very much, and the articles have bias in, and it difficulties to find an "unbiased" article in whitch complies with styling guidalness.
Proposed solution: As my proposal, I would make an extension specially designed for Wikimedia foundation Wikis (in which have a NPOV Policy) called "POV Detector" (or "Point of view detector"), which activation will be optional by the user (default activated for new users (and/or anonymous). And it will consist in the following: If the system detect a bias when finally editing, will detect if there is any biased information in the article and violates the NPOV policy.
Who would benefit: Would benefit in the articles articles quality, detect biased data, and it will raise Wiki's users abilities.
More comments: The "POV Detector" will appear in a yellow-like colored windows when the user finishes the article.
Seems like a decent idea in theory. After all, such tools are widely used by online community managers to detect abuse. --Rollo (talk) 19:09, 16 January 2022 (UTC)[reply]
There is a lot of research on this that could be used, but I suspect this is outside the size that CommTech would like to deal with. --Izno (talk) 21:11, 18 January 2022 (UTC)[reply]
Hello and thanks for taking the time to write this proposal. We reviewed this proposal as a team and have determined that this is out of scope for our team but an idea that's valid nonetheless. What is being suggested here would require elegant machine learning, which our team does not specialize in. Good idea in any case, I am therefore moving it to the Larger Suggestions Category. Thanks again! Regards, NRodriguez (WMF) (talk) 18:27, 26 January 2022 (UTC)[reply]
How on earth should a bot decide over content issues? (N)POV is something completely about content, nothing about technicalities, this should (and could) only be decided by real people, not some bot. Even the use of bad words (which has nothing to do with POV but is content as well) is something, that a bot cannot do properly, as there as well are too many ambiguous uses if words, and too many circumventions possible. This is an impossible suggestion. Grüße vom Sänger ♫(Reden)05:32, 3 February 2022 (UTC)[reply]
Oppose Wikipedia is messy and it's supposed to be that way because knowledge is the same. Something that's seen as a non-neutral POV today might not be seen so a year from now. Let's not calcify the current knowledge structures. Wikipedia's explicit goal is to capture knowledge in it's current form - (Tr3ndyBEAR) 12:10, 29 January 2022 (UTC)[reply]
Oppose: this would entrench existing systemic biases, at inordinate cost for little benefit. POV problems need more editors, not more bots. — Bilorv (talk) 16:51, 29 January 2022 (UTC)[reply]
Strong oppose. There are a myriad of ways an article can be POV. I cannot, now or for the foreseeable future, see any AI system coming that would be remotely capable of even beginning to do this. Daniel Case (talk) 03:38, 8 February 2022 (UTC)[reply]
Problem: The Wikinews project appeared in 2004-2005, but the MediaWiki engine is very poorly adapted to a news site. Members of both the English and Russian sections, including myself, tried to solve technical problems on their own and make the site more like a regular news site. In particular, in 2008, following the example of the English-language section, I tried on my own to create an RSS feed of fresh news for use separately and for broadcasts to social networks. Much more has been done by many other contributors who have taken on the task of adapting MediaWiki for news. For example, Wikinews needs a built-in updatable newsfeed (was temporarily resolved through the DynamicPageList extension, which however is a "crutch" and does not work properly). All these things, of course, had to be handled by the Wikimedia Foundation and its staff programmers, since MediaWiki is a Foundation project. Wikinews requires much more engine development than Wikipedia to function at least at a minimal level. Unfortunately, the news feed had to be formed by the participants with the help of a bot. Such a scheme of work is unstable. Now the news feed for broadcasting to social networks is not being formed.
Proposed solution: The MediaWiki engine needs to be reworked to fit the needs of the Wikinews project. With new tools and a new interface, news writing and approval, breaking news feed, RSS/Atom/subscriptions/social media feeds, and other innovations needed by the community and readers should be available. If you need to refine DynamicPageList, you need to do it. If it is not possible to support DynamicPageList and you want to deprecate it, you must create a replacement.
Who would benefit: Contributors and readers of all language sections of Wikinews. I believe that the load on the Wikimedia Foundation servers should be reduced. DynamicPageList, as I understand it, does not work well and puts a lot of load on the servers.
More comments: Unlike Wikipedia, which has an infinite time horizon, Wikinews immediately needs a fully developed engine and services to function properly. On the bare MediaWiki engine, Wikinews is not functional. Requires too many manual actions, bot work, DynamicPageList extension. Because of this, Wikinews, in my opinion, is still at the technical level of Wikipedia in 2003-2004. Over the years, the Wikimedia Foundation has funded significant improvements to Wikimedia Commons (e.g., many video formats and transcoding), Wikidata, Wikiguid, Wikifunctions, improvements to the MediaWiki engine with SUL, new designs, new gadgets and features, but nothing has been done for Wikinews. Over the years, RSS technology has come into vogue, been added to browsers, and is now completely out of fashion. Wikinews contributors are truly heroic in carrying out the work that is the responsibility of the Wikimedia Foundation. Unfortunately, the Wikimedia Foundation has dealt with everything but the needs of the Wikinews project over the past 10 years. I myself have been looking forward to improvement in the past 10 years, but, apparently, the current technical condition is as bad as it was more than 10 years ago. If Wikinews puts a lot of load on servers due to bad software, then that is the responsibility of the Foundation, not the contributors. Unfortunately, due to server load, an incident occurred with User:Krassotkin.
This unfortunately is outside the scope of Community Tech, but we recognize it is an important problem for Wikinews and have moved it to our Larger suggestions category for further discussion and voting for the broader movement. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 21:05, 26 January 2022 (UTC)[reply]
there are kind of 3 different things related to dpl that could be done here, and they are all very different in scope:
unbanning Krassotkin/reenabling on ruwikinews - that's political (with a technical component) which seems out of scope here.
increasing safety of dpl by figuring out what is wrong with pool handler that prevents it from working with this extension. That's pretty self-contained, but maybe outside of the area of experience of commtech
rewriting dpl to be backed by elastic search. That's a bit of a larger project.
За Крайне важная потребность. По сути, сегодня развитие проекта заблокировано его технической отсталостью. Посещаемость (просмотры статей) очень высокая, а техническая реализация очень отсталая. VladimirPF (talk) 08:47, 2 February 2022 (UTC)[reply]
Support I am not sure why this is considered outside of scope of community tech, but in any case this is an issue that needs to be solved and that potentially is not even that difficult to solve. --Base (talk) 01:36, 6 February 2022 (UTC)[reply]
Support - Break down the tasks - DPL should be fixed first (T124841). There aren't many active incubated Wikinews projects, but inside the Incubator they can use DPL. Once they get their own wiki, they cannot (it won't get deployed). - Xbspiro (talk) 01:35, 8 February 2022 (UTC)[reply]
Problem: The problem is that some wikis use both; the classic way to mark references inside the article text, and the other way, list-defined references. The latter can't be edited with visual editor as references are marked inside the references template. This makes it difficult for those who use visual editor for editing. And those who primarily use wikitext editor, they don't like "the mess" when there are many citations next to each other in article text because it makes editing more difficult.
Proposed solution: Add a button that hides and shows references in article text when you click it. Only leave the reference name <ref name="xxx"/>. At least this would help some editors.
List-defined references can actually be edited using the visual editor, but only if the references list is created using <references>…</references> rather than {{reflist|…}} or some other template. Matma Rex (talk) 02:09, 22 January 2022 (UTC)[reply]
Hello and thanks for taking the time to write this proposal. We went and checked in with the Editing team about this and they couldn't agree on how to resolve it clearly, we therefore moved it to larger Suggestions as it's valid, but to big for us to implement. Thanks again! Regards, KSiebert (WMF) (talk) 14:38, 26 January 2022 (UTC)[reply]
Apology for my ignorance but what is a list-defined reference? Will someone please cite a page where both forms of reference are used. Thanks, ... PeterEasthope (talk) 14:43, 30 January 2022 (UTC)[reply]
References are list-defined when their definitions (<ref name="myref">…</ref> or {{r|myref|r=…}}) are located in a dedicated "References" section (inside a <references>…</references><references/> block, often wrapped into a template like {{reflist|refs=…}}) rather than interwoven with the prose in the article body. In the prose, you just "invoke" (that is, refer to) them instead of having to define them as well. The syntax to invoke a reference is exactly the same as if a single reference is used multiple times (<ref name="myref"/> or {{r|myref}}). The resulting rendering of a page is exactly the same for list-defined and inline references, so readers won't see a difference. But list-defined references make it much easier to improve the prose (because it isn't cluttered by the inline definitions of references) and also to improve the references (because you can compare them next to each other and edit them all at the same time just by editing the "References" section, instead of having to search for them in the prose), that's why many experienced editors prefer this style and many of the better-developed articles use it. See en:WP:LDR --Matthiaspaul (talk) 15:51, 30 January 2022 (UTC)[reply]
Thanks for explaining; I've learned a better way to "reference". Certainly understandable that some experienced editors prefer list-defined over primitive. Henceforth I'll use the list form. I wonder whether the primitive form might be phased out over a span of years. With the list form, hiding might not be necessary. Regards, ... PeterEasthope (talk) 18:26, 30 January 2022 (UTC)[reply]
Problem: Wikipedia and others projects are too bright. Well, some of users asked for a dark mode, but i think, something like a "yellow" mode would be better. I mean, for people who had modern glasses, there is a "filter" for protecting eyes from the light violet/blue band and my proposition would be something like this. Not really dark, (because its too much i think) but in yellow, just for not letting light violet/blue passing... i hope you'll understand what i mean...
Proposed solution:
Who would benefit: Everybody and people with glasses more specifically.
Indeed! We can still discuss and vote vote for it over in the Larger suggestions category, but there's no guarantee it will be picked up. This one might have more hope since it is just a global hue adjustment, compared to Dark Mode which has to exempt certain elements. The same clashing with our Varnish caching still applies, though, so this "yellow" mode have to only be available to logged-in users. MusikAnimal (WMF) (talk) 22:29, 26 January 2022 (UTC)[reply]
Blue-light problem is very problematic to readers, but there is a concern of the topic is extremely big for the small Community Tech team to handle. They can have better teams to call. Thingofme (talk) 14:38, 5 February 2022 (UTC)[reply]
Problem: We make a ton of assumptions about what new editors need to see on a talk page in order to participate in an informed way. Instead of barraging new users with templates atop the talk page, if a WMF team performed user testing on (1) what editors (new and old) found useful about talk page banners, and (2) what they actually learned from reading them, the community would have a clearer understanding of what information to cover and what to excise.
Proposed solution: Perform usability testing on the talk page banners of several Wikipedias and share findings with the community; bonus: recommend a design with information hierarchy for the community to consider and potentially implement
Who would benefit: All talk page readers and editors, especially new ones
More comments: To my understanding, this is a blindspot of the editing community, as we do not have the communal resources to perform user testing without a centralized team like the WMF's. Many community UI elements could use usability testing but the talk page banners is one of the most glaring opportunities.
So, analyse the levels of banner blindness on talk pages ? I'm guessing its probably about 90% (not reading them) for any page with more than 1 banner, but yeah it would be good to get some insight into this. —TheDJ (talk • contribs) 14:33, 16 January 2022 (UTC)[reply]
(I'd throw Navboxes in to this bucket.) That said, I am not certain this is exactly in CommTech's scope as proposed. --Izno (talk) 21:33, 18 January 2022 (UTC)[reply]
@Czar: would it be accurate for me to understand you/this wish as seeking to understand the extent to which new editors understand the purpose of talk pages and how to use them in constructive ways on desktop? If "yes," then it's likely we'll be able to share answers to the questions you're posing in the coming months.
Reason being: the mw:Editing Team is currently working on a set of improvements to help people who are new to instinctively recognize and use talk pages as spaces to communicate with other volunteers.
As part of this work, we will be running usability tests (T299819) to evaluate how effective these interventions are at helping people, "...to participate in an informed way."
I love this idea, and would see it implemented as a wish. Sometimes you'd have to scroll an entire page to get through the banners (WikiProject, translated, etc etc) Xn00bit (talk) 20:28, 28 January 2022 (UTC)[reply]
Problem: There are many useful features in the web version that are not available in mobile browser. And many others are not so flexible as they are in web version.
Proposed solution: Make useful features available for mobile and make them easy to use
Hello and thanks for taking the time to write this proposal. We are archiving this wish due to a lack of clarification. We needed clarification so that we could accept this wish and mark it for translation so that it could go into voting. Thanks again! Regards, NRodriguez (WMF) (talk) 17:32, 26 January 2022 (UTC)[reply]
@NRodriguez (WMF): FWIW this is more or less a request for phab:T158181 I think, which could conceivably go in the "Larger projects" pile. I anecdotally see people complain about mobile Minerva not offering the same tooling as on desktop and I suspect a wish to that effect would see a landslide of editors hitting the Support button during the vote. Consider whether to de-archive accordingly. Izno (talk) 21:50, 26 January 2022 (UTC)[reply]
This is a great point! Going to re-work the wording of this wish to be closer aligned with the phab task and move into Larger Suggestions, thanks for the tip @Izno and for all your help with the survey. Best, NRodriguez (WMF) (talk) 13:34, 27 January 2022 (UTC)[reply]
The main thing I am frustrated about is that on mobile, the map coordinates of a location on the planet don't show up at all. E.g. in en:Pearl Street Mall I see coords in the upper right on desktop, but nowhere on mobile. ★NealMcB★ (talk) 03:19, 3 February 2022 (UTC)[reply]
Oppose I would rather prefer the mobile app to act as a reader and light editor than making the inefficient effort of trying to implement all features of MediaWiki across the app when they're already accessible from the website. I personally think that we should stop work on the current mobile site and work on optimizing the current desktop site for mobile, especially with the work being done on New Vector. Then, everyone can have access to all of the features on any screen size and input form, and the look of Wikimedia wikis remains consistent across all devices. That way we do not have to build and maintain MediaWiki features on the app, mobile website, and the desktop website. Lectrician1 (talk) 00:45, 29 January 2022 (UTC)[reply]
Problem: Users watching a page are not notified of changes to transcluded pages.
Proposed solution: Implement "cascade-watching" so that users watching a page are notified of changes to transcluded pages.
Who would benefit: All watchers.
More comments: Some use cases:
Changes to templates used in all kinds of pages. Such changes often affect the content and not just the format of the pages, but users watching them are not notified.
Changes to excerpts done via en:Template:Excerpt or other methods. Currently, usage of excerpts in featured and important articles is controversial because users watching the articles are not notified of changes to sub-articles (unless they also watch the sub-articles), see en:Module talk:Excerpt#Should featured articles also use excerpts? Having excerpts on more featured and important articles would go a long way in spreading their existence and usefulness (namely to prevent duplicate work, improve content quality and foster collaboration).
I can see how this interesting suggestion would be useful. There are a few edge cases to specify, especially when a page is transcluded by multiple watched pages and one becomes unwatched, perhaps by a timed watch expiring. We also need to be clear what happens when the transclusions themselves change, e.g. Portal:Fruit stops transcluding Apple and transcludes Banana instead. Certes (talk) 13:44, 19 January 2022 (UTC)[reply]
@Sophivorus: you only mentioned one template above that could be transcluded (the "excerpt" one) - are you intended dev work on this to be limited to only this specific template - or to the general use case of watching all transclusions, cascaded?The later obviously has a much larger use-case. — xaosfluxTalk13:59, 19 January 2022 (UTC)[reply]
@Sophivorus: usage question, so for example if someone were to watch the page w:en:Hoodoo Mountain with this option, then when they view their watchlist they should see changes to that page, and also to:
Discussing with the team, we feel this is probably too large of a project for us. We can offer to move it to our Larger suggestions category for broader attention, or we have a counter-proposal: Offer a way to watch a page and all the templates/pages transcluded on it. The problem of course is unwatching. There's currently no structured relationship between multiple watched items, and introducing that is going to be a massive feat. Additionally, we wouldn't be able to auto-watch anything else that gets transcluded, so watching the Community Wishlist Survey 2022/Watchlists page for instance (which is a great example, thank you) and having it auto-watch all future transcluded pages wouldn't be in scope for us. Sorry! @Sophivorus: Would like us to move this to Larger suggestions, are would the cheap "watch this page + transclusions" feature do it for you? MusikAnimal (WMF) (talk) 22:48, 19 January 2022 (UTC)[reply]
@User:MusikAnimal (WMF) Hi, sorry for the delay! I wanted to try implement the functionality through an extension to understand the difficulty. Today I did my attempt and I think I understand now. Here's the essence of my little extension:
classCascadeWatching{staticfunctiononPageSaveComplete(WikiPage$wikiPage,MediaWiki\User\UserIdentity$user,string$summary,int$flags,MediaWiki\Revision\RevisionRecord$revisionRecord,MediaWiki\Storage\EditResult$editResult){$Title=$wikiPage->getTitle();$Parents=$Title->getTemplateLinksTo();foreach($Parentsas$Parent){// If $Parent is in user watchlist// update wl_notificationtimestamp at https://www.mediawiki.org/wiki/Manual:Watchlist_table ?// or maybe notify the user via Echo ?// or do we need to do something different and probably new to the watchlist ?}}}
I think the problems are actually two:
First and foremost, that there seems to be no adequate field or convention in the current watchlist system to notify the user that "there's been a change to this page because there's been a change to this transcluded page" and sending an Echo notification seems overkill.
Second, that sometimes pages may be listed as transcluded even though they actually aren't, as for example when the Wikipedia:Template:Annotated link (due to it using a Lua method I can't recall right now). I may be wrong about this but I recall this being the case.
Is my assessment correct? Or did you identify other difficulties? In any case, I guess sending it to "Larger suggestions" would be preferable, since the JavaScript solution, however doable and appreciated, seems to me with too many problems. Thanks! Sophivorus (talk) 12:00, 27 January 2022 (UTC)[reply]
Or am I wrong about #1? Thinking a bit more about it, it seems Wikidata already pushes notifications to watchers of a page when a change is done to the linked Wikidata item. Sophivorus (talk) 12:18, 27 January 2022 (UTC)[reply]
@Sophivorus If you wanted to treat a page and all of the transcluded pages as separate watched items, there's no issue in my mind apart from #2, and that you may unknowingly watch a lot of pages some of which you don't care about. For instance, by watching a page you also watch its talk page, so would you want to watch all transcluded pages there, too? Including {{reply to}}, etc.?
My assumption was you'd want to for instance watch Example and if there's a change to a template used on Example, it not only shows up on your watchlist but also indicates it shows up as a transclusion on Example (so that you understand why its on your watchlist). And if you were to unwatch w:Example, it would also unwatch all of the transcluded pages. That's the part that doesn't exist -- a relationship between watched items. We could establish this with a new table, but in order to leverage the existing backend watchlisting system, every transclusion must also be a watched item (in the watchlist table). Your code snippet seems to instead recreate this system by looping through the transclusions on every edit. This could cause performance problems (I'm not sure), among a hosts of other problems in splitting the logic into the extension code rather than using what comes free with Core.
I think all of this is absolutely doable. When there's a will, there's a way. It's just that after having spent ~6 months to bring you mw:Help:Watchlist expiry, we're pretty familiar with the watchlist backend, and were going off intuition that this proposal may be out of scope for us. With your word, we will move this to Larger suggestions. Kind regards, MusikAnimal (WMF) (talk) 16:51, 27 January 2022 (UTC)[reply]
Support Transclusion is a vital tool for reducing redundant content forks, and better watching for it would help it to be done more. {{u|Sdkb}}talk04:21, 29 January 2022 (UTC)[reply]
Problem: The template language in the project is very close to the functional programming paradigm and, if not in form, then in execution, seems similar to the LISP language. I think that on the basis of the Scribuntu module, without spending too much time, one could create a module for the SBCL or ECL runtime environment.
Proposed solution:
Who would benefit:
More comments: The form of passing parameters to templates is almost completely analogous to function parameters in LISP. Most of the data in these projects can be viewed as lists of words rather than strings of letters, which can allow old-school AI experience (SICP and AIMA) to be applied to projects.
No, I mean a full implementation of Common LISP, not as an add-on to LUA. And perhaps immediately using some libraries from w:Qucklisp, such as iterate, babel, cl-ppcre-unicode, cl-csv, cl-json... and maybe even up to maxpc (for writing parsers and lexers). In any case, processor code execution is much faster and more efficient than interpretation in the LUA environment. PS: thanks for the hint, I will definitely look at this gadget too :) Va(🖋️)20:12, 15 January 2022 (UTC)[reply]
This proposal doesn't do a good job explaining why we should bifurcate to another templating language beyond the current Lua and existing MW syntax. It also broadly seems larger than CommTech scope. --Izno (talk) 22:11, 18 January 2022 (UTC)[reply]
You are right - I cannot write a convincing explanation because I have no experience in writing such speeches... But I want to note that I do not mean replacing one tool with another, but adding a tool to expand expressive possibilities. By the amount of work. For LISP, there are already implementations that are designed to be embedded in other systems. And this embedding is no more difficult than for the LUA, for which Scribuntu has already been implemented. As one of the correspondents has already noted, there is even a module that implements the LISP calculation mechanism written in LUA (n:Module:Wikilisp). This means that there is a need. However, such an implementation is not complete, is not efficient in execution speed, and does not allow the creation of modules written entirely in LISP and does not allow you to directly connect ready-made existing libraries etc. Va(🖋️)04:51, 19 January 2022 (UTC)[reply]
Problem: Sites like Wikiwands which aggregate Wikipedia content and then represent them to readers are frequently spotted on search engine result at about as high or sometime higher place than Wikipedia itself. While it's nothing of fault to have Wikipedia content rehosted and represent in different style as long as copyright and content origin are properly represented, increased readership on third party sites instead of Wikipedia itself could have a potential of leading to less chance of attracting readers into contributing to Wikipedia since those third party sites usually don't have as obvious direct link to let readers contribute to Wikipedia when readers want to make improvement, and in the long term it could lead to a reduction in number of new Wikipedia editors, which could be bad to Wikiprojects' long term survival.
Proposed solution: Wikipedia the site itself, together with other wikiproject sites, can probably use better SEO, so that readers are attracted to read Wiki content on sites directly managed under WMF which also provide clear guidance toward new user on how to help and contribute to the project, turning more people into editors of the project in the long run.
Who would benefit: The Wikimedia movement in general would benefit from it, as the Wikipedia site itself can better attract readers to turn into becoming an editor, thus improving Wikimedia project content. General readers can also be benefited by it, by reducing the chance of reader accidentally accessing other illicit sites featuring better SEO, which might contain malwares like mining script, or a false login page that try to obtain user password to compromise cybersecurity of users.
More comments: This proposal is modified from proposal in the Sandbox. Also, note that smaller language Wikipedia, and other Wikiprojects, can easily benefit from having more readerships.
Yes, I have moved it accordingly. We'd love to help with this but SEO is a bit out of scope for us. Without having done any prior research or searching Phabricator, I believe our SEO might improve in time once we are able to serve mobile and desktop on the same domain, since Google at least does mobile-first crawling these days. Don't quote me on that, though. MusikAnimal (WMF) (talk) 20:46, 27 January 2022 (UTC)[reply]
Google and other search engines seem to already rather heavily favor Wikipedia in their search results. Perhaps this is more of a problem for smaller Wikis? Anyhow, I'm all in favor of any measures to get more eyes on more Wikimedia projects. Ottawajin (talk) 05:55, 29 January 2022 (UTC)[reply]
Problem: There are many titles that make good redirects but which should not appear in search suggestions because they crowd out better targets, for example misspellings.
Proposed solution: Add a magic word that (a) hides these titles in search suggestions (possibly excluding exact matches), (b) prioritises the redirect target in suggestions and search results, and (c) deprioritises tagged redirects in search results.
Who would benefit: Readers, anyone else who uses search suggestions
More comments: There is often pushback about keeping redirects from incorrect names, unusual phrasings, spelling errors, etc, even when they demonstrably help some readers find the content they are looking for because they appear in search suggestions ahead of correct names hindering a different group of readers finding the content they want to read. Suppressing such titles from the search suggestions dropdown has been a perennial proposal for many years at en.wp and the phab task linked below indicated it's been perennial on the Hungarian Wikipedia too since at least 2010.
I've never experienced this as a problem.. what exactly do you mean with 'crowd out'? Can you describe that in a bit more detail, preferably with example links/searches ? —TheDJ (talk • contribs) 13:05, 11 January 2022 (UTC)[reply]
Ah so specifically ONLY for the search field's search suggestions... I guess I can see that.. we have similar problem with vulgar language etc. The traditional solution is to delete or even suppress the page yes. Of note might be that the need to keep redirects from spelling corrections is not as high any longer as the search has fuzzy matching to deal with typos these days. So maybe its actually better indeed to delete many of these. —TheDJ (talk • contribs) 15:49, 11 January 2022 (UTC)[reply]
If the internal search engine was the only way people accessed Wikipedia content then that would be a valid argument, but its only one of many ways - direct links, URIs, bookmarks, etc. all take you to the exact title you entered. Thryduulf (talk: meta · en.wp · wikidata) 17:38, 11 January 2022 (UTC)[reply]
Hello @Thryduulf, I talked to the Search team about this one yesterday and they like it would like to discuss it more and it sounded like they might have to even implement it themselves due to its complexity. They really appreciate the idea! So I will discuss with the CommTech team, I don't want to give the false impression that the CommTech team can implement it and let people vote if it's too big for us. KSiebert (WMF) (talk) 11:09, 18 January 2022 (UTC)[reply]
Hi @Thryduulf, the Search team talked about this recently and I can share some of our thoughts. Currently, the WMF Desktop Refresh team is currently working on a better user experience for search completions (i.e. the title matching search suggestions referred to here): while not exactly the same, there is an open ticket to resolve redirects within the list of suggested search completions (https://phabricator.wikimedia.org/T296225). This should at least partially address the concern here that irrelevant suggested redirects will crowd the list of suggestions, as the user will see the resolved redirect title after this change is made (rather than the title of the redirected page itself). There are certainly other potential edge cases that might not be desirable after this change, but I think it makes sense to wait until after the desktop refresh work is done to re-evaluate the new behavior and how it can be improved with respect to which completions are suggested. Hope that helps, and thanks for the thoughts and ideas! MPham (WMF) (talk) 22:41, 19 January 2022 (UTC)[reply]
Thank you for that note. Having read T296225 I think that has the potential to be actively harmful (as I have commented there) and will not actually solve this problem in all cases so I disagree that prioritising that is a Good Thing. Thryduulf (talk: meta · en.wp · wikidata) 03:13, 20 January 2022 (UTC)[reply]
Thanks, Thryduulf for commenting over there, I couldn't have stated it any better. While it could be useful to have some kind of tag on redirect pages so that they don't show up in searches (or at least not with the same priority), replacing the name of the redirect page by its target page in the search will definitely be harmful in many cases and would undermine many uses of redirects. Hopefully, this will not be implemented this way. --Matthiaspaul (talk) 22:40, 28 January 2022 (UTC)[reply]
Support the ability for editors to use simple keywords to alter the visibility (or ordering) of pages in the dropdown search engine, but Oppose the replacement of redirect titles by the page they redirect to per Thryduulf's Phabricator comment. — Bilorv (talk) 17:09, 29 January 2022 (UTC)[reply]
Support – There's an extensive system of redirect categorisation on enwiki, and much of of is about distinguishing between correct alternative names and typos/misspellings/misnomers. It's high time this system were used by the search engine. I don't think simply excluding the "incorrect" redirects is a good idea (what about the people who make the typo when searching?), but assigning them lower priority will be good. Uanfala (talk) 22:24, 10 February 2022 (UTC)[reply]
Make a mobile application for Wikivoyage
B This proposal is a Larger suggestion. There is no guarantee this proposal will be implemented. Supporting the idea helps communicate its urgency.
Problem: No official mobile app for a travel-focused resource like Wikivoyage
Proposed solution: Creating a similar mobile application created for Wikipedia for Wikivoyage.
Who would benefit: Travelers
More comments: People on the go often use their smartphones to stay informed. Wikivoyage is a great resource for travelers, but it needs to be easier to reach its target audience.
I don't think this is a good idea. The Wikipedia mobile apps are already problematic, and I think it would be better to get rid of them and just focus on improving mobile web. Tol (talk | contribs) @ 02:46, 4 February 2022 (UTC)[reply]
Support 3rd party applications like the open source OsmAnd already integrate Wikivoyage as a feature. A dedicated app could help increase visibility. --Mbrickn (talk) 16:37, 29 January 2022 (UTC)[reply]
Oppose No more problematic dedicated mobile apps, already enough with the much botched Wikipedia app. Besides, Wikivoyage is ugly in all modes, and very unfit for its stated purpose - probably should be entirely redesigned. This is not a solution. - DarwinAhoy!20:48, 4 February 2022 (UTC)[reply]
Sadly, it is in the list of never happen. I support your views, but I think the board of WMF do not even now what a Wiktionary is, who are the readers or contributors, its potentialities. Noé (talk) 11:26, 12 January 2022 (UTC)[reply]
I understand your feelings, @Noé. The reason why this idea is on the list you pointed at is strictly related to Community Tech. This team is not able to build (and later, maintain) such big projects. However, having this need in writing yet another time is valuable! SGrabarczuk (WMF) (talk) 20:59, 12 January 2022 (UTC)[reply]
Indeed, we can't afford to create and maintain a mobile app from scratch, much less two, but this is a great idea and deserves attention so I'm moving it to our Larger suggestions category. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 00:10, 28 January 2022 (UTC)[reply]
This is IMO unlikely to happen as long as Wiktionary is wikitext-based. Trying to use wikitext as a database is a huge development burden and makes almost anything beyond just displaying the pages infeasible. A transition to Lexeme would make this a realistic project (although probably still too large for Community Tech). --Tgr (talk) 01:07, 30 January 2022 (UTC)[reply]
Problem: Some languages (Chinese, Japanese, Korean, etc.) were historically written in multiple directions. Sometimes there are directional wordings in text that requires specific matching text direction in transcription to understand. Some might also prefer reading the text in original direction instead of modern direction.
Proposed solution: Support the display of Chinese/Korean/Japanese text in non-default direction.
There could be a default orientation setting for each document
And then user can also change the setting as they like
It will also benefit other non-wikisource wiki projects that are written in those languages, allowing users to read those wikis in the way they like
Who would benefit: People reading historical documents in relevant languages Wikisource. And also just general readers of wikiprojects in those languages. Editor of some of the relevant language sites sometimes used special formatting to keep some text vertical, which would no longer be needed if such support is implemented.
More comments: I have originally drafted the wish in 2018 but was not submitted at the time. Some browsers like Vivaldi have a reading mode that have built in support to change text orientation in the reading mode, however they don't work properly with advanced text formatting.
A great idea, but indeed I think it's too big of a project for our team. As such I'm moving it to Larger suggestions, which is a means to tell the WMF and broader movement how much this means to you. See you tomorrow when voting starts! MusikAnimal (WMF) (talk) 01:22, 28 January 2022 (UTC)[reply]
Problem: Wiki projects presently depend upon users and their client-side tools for checking language use. An unknown percentage of edits are users correcting one another’s language use.
Proposed solution: MediaWiki software could support and interoperate with an extensible set of server-side document-processing tools.
There are two flavors of server-side document-processing tools:
Firstly, server-side document-processing tools can be of use for computer programming languages. Tools, in these regards, include parsers and compilers which can output annotations such as informational, warning, and error messages about portions of source code.
The outputs of document-processing tools can be represented as annotations. Annotations are data structures which reference selections of, or portions of, documents. Annotations from multiple document-processing tools can be merged, aggregated, and presented to editors and readers as they edit, view, or view more information about wiki documents.
Were MediaWiki software to support server-side document-processing tools, this might result in a new type of extension.
Some projects which would be benefited by computer-aided document authoring include:
Wikifunctions. This project would be benefitted by the first flavor of server-side document-processing tools, wrappers for various server-side parsers and compilers, e.g., Python.
Wikipedia and Wikinews. These projects would be benefitted by the second flavor of server-side document-processing tools, natural-language document-processing tools.
Downstream projects. Users of MediaWiki software would be able to create new solutions were MediaWiki to support computer-aided document authoring and server-side document-processing tools.
This is similar to something that was sitting in my head for a longer time. I think we need to take "wikitext" or wiki technology to the next level. Regarding annotations, I personally regret that Purple numbers got deleted from English Wikipedia, I think this was a quite early annotation proposal coming from wikipedia:en:Douglas Engelbert. Would like to work on this item, too. « Saper // talk » 14:11, 16 January 2022 (UTC)[reply]
Yes, as it's written now it's a bit too broad I think. @AdamSobieski: Would you be able to narrow this down to one particular type of processing (e.g. there's already a grammar editor proposal). Perhaps you could focus it just on readability analysis or another of your ideas? Thanks! SWilson (WMF) (talk) 03:11, 19 January 2022 (UTC)[reply]
While a first server-side document-processing tool to focus on could be either spelling, grammar, or readability analysis, I think that this could be an architectural project which provides opportunity for a new type of third-party extension. That is, ideally, server-side spelling, grammar, readability, and other tools would each involve modular third-party extensions. Yes, I can refine the proposal upcoming to include development of a first server-side document-processing tool. This first server-side document-processing tool could be useful to design while considering architectural topics and could have additional eventual use as a coding example, illustrating to developers how to build the new type of extension. What do you think about modular extensions-based architecture for server-side document-processing tools? Which first tool do you think that the proposal should narrow to focus on? You mentioned readability analysis? AdamSobieski (talk) 09:16, 19 January 2022 (UTC)[reply]
@AdamSobieski: Thanks for clarifying. As it sounds like this is a larger architectural proposal, I've moved it to the relevant category (which is where the existing grammar editor proposal is too). SWilson (WMF) (talk) 02:26, 28 January 2022 (UTC)[reply]
Support – it would be really good to have such tools at our disposal, though this doesn't look like the sort of thing we realistically can expect in the near future. Uanfala (talk) 01:33, 10 February 2022 (UTC)[reply]
Semantic search
B This proposal is a Larger suggestion. There is no guarantee this proposal will be implemented. Supporting the idea helps communicate its urgency.
Problem: The only tool to search Wikipedia currently is a simple direct keyword search which looks for literal query matches. If any information is needed, the only way to find it would be to try searching specific keywords or phrases which must match perfectly with the information one is trying to find. Wikipedia is filled with so much information, yet so much of it is hard to find because of this. Even if one knows what article contains the information they seek, the only way to find specific information would be to use keyword matching search (which would make specific information hard to find, especially in long articles).
Proposed solution: The proposed solution would be a Wikipedia semantic search which can help users find information using natural language queries. This means that one could enter a question like "What is the deepest point of the ocean?", and they would be directed to the section of the Wikipedia article about the Mariana Trench which explains this fact. This is not only a possibility, but is already used by many search engines like Google (which has many more pages to index than just Wikipedia). This would have a tremendous impact on the future of free knowledge as it would make finding information significantly easier.
Who would benefit: The group that would benefit most would be those who are looking for specific information or to have a question of theirs answered.
More comments: I have briefly worked on a project independently which allowed for semantic search within a Wikipedia article (i.e. if the user wanted to know when Tiger Woods began golfing, they would choose the Tiger Woods Wikipedia page and search something like, "When did Tiger Woods start golfing?"). While this is on a smaller scale, it can be extended to search all of Wikipedia. Further, along with readers benefitting from this tool, editors who are looking to make contributions to specific articles that contain topics they are familiar with can use this tool to find these articles (and sections within those articles) to which they can contribute.
I liked the idea of semantic search, to improve the search in general, they can add a gear toggle to the search bar and add additional settings and so on. Even other search models can be embedded in that toggle. Mohammad ebz (talk) 13:58, 11 January 2022 (UTC)[reply]
I went to talk to the search team and they pointed out that sadly the term "semantic search" is a bit confusing in general, since really we are really doing quite a bit of semantic search, in in terms of trying to understand the searcher's intent and interpreting it in different ways.
The search team also mentioned that they have discussed this, because it's an interesting idea, and also they mentioned that for the next 2 quarters, they will have to focus on migrating to Elasticsearch 7 at first. KSiebert (WMF) (talk) 17:58, 12 January 2022 (UTC)[reply]
Something along those lines; however, it might also be useful to not only provide the answer to the question, but also bring the user to the section of the page that contains the answer, so they can see the context surrounding the answer. Ajshul (talk) 15:34, 13 January 2022 (UTC)[reply]
This is out of scope for our team. As such I'm moving this to our Larger suggestions category so the Search team can receive your valuable input (this is not to promise they will be able to deliver on it, but you showing them what you want and how much you want it is still valuable :) I think this is a huge project even for the Search experts! Thanks for participating in the survey, MusikAnimal (WMF) (talk) 02:44, 28 January 2022 (UTC)[reply]
Semantic search requires semantically structured data to search through, which is what Wikidata has, and I think Wikidata does need to be searchable by something approaching natural language queries. OTOH, trying to make semantic search work for unstructured natural-language text like in Wikipedia is an open research problem AFAIK. Silver hr (talk) 17:07, 3 February 2022 (UTC)[reply]
Someone has said: The Internet is like a library, where all the books have been thrown in a large pile on the floor.
I agree that searching for information is a difficult task and I appreciate any serious efforts to address it, but I'm skeptical about asking a single natural language question and have the correct answer automatically delivered to you. Instead of doing a full-text search yourself for various keywords, it would be like walking past that unstructured pile of books up to the information desk and asking library staff for the answer; now they have to perform that full-text search for you, and you have thereby effectively turned your question into Somebody Else's Problem, i.e. you are nowhere closer to an answer since library staff has no magical wand by which only they can summon that answer.
Instead, I believe the search process must involve a dialogue between you and the (automated) information retriever (the "robot librarian"), where that natural language question may be a good introduction, but depending on the exact circumstances and nature of your question, you may have to provide additional details for clarification of what you really want to know, and the robot must be able to request those clarifications, say by presenting a few simultaneous answers to make sure the question was properly understood and any ambiguities are resolved (such as when there are two golf players by the same name etc).
While Wikidata is structured, that structure isn't necessarily perfect or universally understood; your mind may well be structured in a slightly different way, sometimes making it difficult to have Wikidata "understand" what you are really asking for. Also, any information repository, be it Wikidata, a conventional library, or your own brain, is by necessity incomplete, and lack of any information, such as an entry for that hypothetical second golf player named Tiger Woods, is in no way proof that he doesn't exist somewhere. Or the information may well be there, but just not in the context where you expect to find it, and therefore it risks being overlooked.
I will still give my support to this proposal, not because I believe in (or even understand) the exact proposed solution, but because the problem it tries to address is both deserving and well described. If it merely leads to some serious experiments with systematic search dialogues, we have come a long way. --SM5POR (talk) 21:26, 3 February 2022 (UTC)[reply]
Support Personally I've often had to look through multiple articles to find the information I wanted. Sometimes using an external search engine helps, but not always Ph03n1x77 (talk) 07:14, 5 February 2022 (UTC)[reply]
Support I feel like I've learned tips/trips and have a good handle on how to find what I want on Wikipedia & other WM projects. That said, I think we need to evolve and be finding better ways to deliver information to an audience that is evolving or at least changing how they access information. paul2520 (talk) 17:28, 8 February 2022 (UTC)[reply]
Problem: There should be some way to search all edits with a specific editsummary. In Wikidata this can also be used to track a series of edits (such as a edit group).
Proposed solution: create a functionality to search edit summaries via SQL (though may not scale for large wikis like Wikidata), or search them via ElasticSearch.
That doesn't really scale well though. Especially if you need to do a full text search (instead of exact field match) or if you want some fuzzy matching. A query with a like predicate already easily takes over 2 minutes on English wikipedia on a partial search. —TheDJ (talk • contribs) 13:17, 11 January 2022 (UTC)[reply]
This is ok, but we have to rely on like custom edit summaries and log reasons. Any edit summary were non-frequently used can't be searched in this way. We can search tags and edit filters log, but it's hard to implement. Thingofme (talk) 08:34, 21 January 2022 (UTC)[reply]
Wikiget (CLI) has this feature, similar to Edit summary search, for specific users and times. The search can be regex, and be include or exclude ex. Show all edits for Jimbo during 9/11 when the edit-comment started with 'A' wikiget -u "Jimbo Wales" -s 20010911 -e 20010911 -i "^A". -- GreenC (talk) 19:40, 12 January 2022 (UTC)[reply]
@GZWDer: I'm going to go ahead and say this is something that we probably can't put into production MediaWiki because the reasons TheDJ mentions above. This is precisely something that is better served as an external tool, where we are allowed to have queries that run over 30 seconds. Sigma's edit summary search tool exists, but it doesn't have localization and doesn't search log summaries. So I think what Community Tech can offer is to build this feature into XTools, along with support for log entries. Would that satisfy your wish? MusikAnimal (WMF) (talk) 17:48, 17 January 2022 (UTC)[reply]
Pinging @EBernhardson (WMF) from the Search Platform team for input. Do you think this is something we could do? There are many more edits than there are articles, and compared to normal search, searching edit summaries is probably not a feature that would be used very much. I don't know if the storage/infrastructure needs of ElasticSearch would be warranted here, but it would certainly help with speed and make a production deployment of this feature more feasible. Thanks for any insight you can provide, MusikAnimal (WMF) (talk) 18:19, 17 January 2022 (UTC)[reply]
Average edits per page are about 1 to 20 but most edis summaries are much shorter than page contents. This is even true when all logs are also indexed (most logs have no summary).--GZWDer (talk) 20:03, 17 January 2022 (UTC)[reply]
As an underlying technology, elasticsearch is probably a reasonable way to do this kind of search. CirrusSearch, the extension to integrate elasticsearch and MW search, on the other hand doesn't really have anything to handle this.
The difficulty is that wiki search is page-based, not revision-based. The only place within the existing search system to put these would be to generate a property per page with the full history of edit messages. This is problematic as we have to generate these a few hundred times a second (edits, re-renders due to templates, re-renders due to age, etc.). Due to the way CirrusSearch and Elasticsearch work together it is not possible to only provide the new edit summary to append (or at least, not in a reliable way).
One method of doing this appropriately would mean creating new indices that have a search document for every revision ever created by mediawiki, and processes to maintain those indices going forward. I worry that this will then run into numerous complications integrating with mediawiki spam prevention. Today Search has a very easy role in spam prevention, we only index the latest content and we trust editors to correct spam in the live pages. Anything revision based will need to integrate with the spam prevention tools and ensure content is supressed.
It would be a bit of an undertaking, and it would have ongoing maintenance costs, but in summary I think elasticsearch could do this given enough investment.
Moving to "Larger suggestions" per above. This certainly isn't something our team could take on. But I will probably still add a edit/log summary search into XTools at some point, so look forward to that :) MusikAnimal (WMF) (talk) 03:19, 28 January 2022 (UTC)[reply]
Problem: Some wiki projects actively uses Wikidata labels. And there are Wikidata item labels that are used in thousands of articles. Items like this need to be able to restrict label editing, while still allowing claims to be filled in and sitelinks to be added.
Proposed solution: Provide an ability to protect labels/descriptions/aliases, statements and sitelinks separately
Who would benefit: Wiki communites who actively uses Wikidata
Problem: Some wiki projects actively uses Wikidata labels. And there are Wikidata item labels that are used in thousands of articles. Items like this need to be able to restrict label editing, while still allowing claims to be filled in and sitelinks to be added.
Who would benefit: Wiki communites who actively uses Wikidata
Proposed solution: Provide an ability to protect labels/descriptions/aliases, statements and sitelinks separately
This is not feasible for our team, since it would involve a fundamental rewrite of the MediaWiki storage model, or a major re-working of Wikibase. It's most certainly a valid proposal, though, so I'm moving it to our Larger suggestions category. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 03:58, 28 January 2022 (UTC)[reply]
Support although I'm not sure how this would practically work, particularly where the items need labels adding in other languages but the existing ones should ideally be protected. Thanks. Mike Peel (talk) 19:09, 28 January 2022 (UTC)[reply]
Problem: editing template in Visual Editor Visual Editor allows editors to insert and edit template without wikitext (as the picture shows). However, when I want to insert templates into those textareas, I have to insert wikitext.
Proposed solution: Add a button next to the textarea, which can search and edit templates and generate wikitext into textarea.
Who would benefit: Editors who need to insert template into template in Visual Editor
This is a good solution but it seems like need a lot of work. I have a temporary solution for this problem: Add a button next to the textarea. Click it and pop up Extension:TemplateWizard, then search templates. TemplateWizard will generate wikitext into textarea. Steven Sun (talk) 09:17, 12 January 2022 (UTC)[reply]
Hard, as templates are not designed to use inside VE. However, you have to write in source code by parameters, but it's less helpful than using the source code itself, it can highlight lines and has a linking, template to add them. Thingofme (talk) 07:55, 14 January 2022 (UTC)[reply]
@Steven Sun:This is a good solution but it seems like need a lot of work. True, but we'd love to work on the best possible solution! These days, we're really trying to aim for quality, even if it means things can be a bit trickier. I'll add this phab task above. SWilson (WMF) (talk) 03:27, 19 January 2022 (UTC)[reply]
I'd also just note that this work is likely out of scope for the CommTech team, because it's in a feature that's managed by a different team. It can of course still be voted on in the survey. SWilson (WMF) (talk) 04:01, 19 January 2022 (UTC)[reply]
Problem: Many Wikipedia articles draw information from Wikidata for infoboxes, templates like the one for the external link to an official website, and uses of the Wikidata template in article prose. This is particularly useful for centralizing information that needs regular updating. However, inexperienced editors often don't know how to get to Wikidata to do an update, so they either give up or overwrite the Wikidata template with the new value. This causes frustration and harms the quality of our articles. A crude workaround, the pencil icon template, makes it a bit easier to get to Wikidata, but this disrupts the appearance of articles, including for readers with no interest in editing.
Proposed solution: Build an interface that allows editors to edit Wikidata values directly from Wikipedia, or that at least makes it easier to get from templates that draw from Wikidata to the Wikidata statement that hosts the information.
Who would benefit: Editors trying to update information drawn from Wikidata, and Wikipedia readers or Wikidata users who would benefit from updated information.
Thanks for the phab link! A full bridge (completely editing Wikidata from Wikipedia) would be fantastic, but even something that just made it easier to get to Wikidata would be a big improvement. The team could address whichever they think they'd be able to handle. {{u|Sdkb}}talk09:38, 25 January 2022 (UTC)[reply]
Support - Not only Wikipedia. We, at Wikivoyage, use Wikidata intensly, sometimes 100 times in one article. Editing Wikidata froma local Wiki would be great. -- DerFussi06:56, 29 January 2022 (UTC)[reply]
Support Not only for Wikipedia, but also Wikisource, Wikibooks, etc. On Wikisource, we could easily fill Wikidata forms from Wikisource forms, in Author: or Index: pages. — ElioPrrl (talk) 15:44, 29 January 2022 (UTC)[reply]
Problem: For many tools and also in articles there is possible to use map. Unfortunatelly, default provided Wikimedia map is too much googlish - only streets, buildings, some water and forests. No POIs. Look at these maps:
Wikimedia map, mapy.cz and openstreetmap.org
On second and third map re visible some POIs, on the left I can only guess if there is some significant building (e.g church)
Proposed solution: 1) Change wikimedia maps tiles and render some POIs and highlight public buildings and monuments 2) Give possibility to choose different map - there exists many OSM renderers which are free to use.
Who would benefit: Anybody who uses maps on Wikimedia projects
More comments: Some wikis uses some derivation of MediaWiki:OSM.js, which have possibility of switching maps. But Kartographer and tools uses only wikimedia map.
Yes, the problem is Wiki size. If I remember correctly, at some point the OSM community politely asked us from reducing our use of their servers (citation unavailable ATM :D). Also, wiki tiles have the tremendous advantage of being multilingual (see ro.wp vs uk.wpStrainu (talk) 08:13, 12 January 2022 (UTC)[reply]
But Wikimedia maps should have our own tile server. Rendering more features into it would be easier than trying to let people choose a different tile server, which will a.) rely on external service and make content unavailable when the external service being down, and b.) not much third party tile server can withstand the traffic of people visiting Wikipedia pages. C933103 (talk) 23:44, 15 January 2022 (UTC)[reply]
I think we should use OpenStreetMap for our map. It's free, and easily editable, and everyone can contribute, just like Wikimedia. Then, the map location should be easier to guess and search for some places. Thingofme (talk) 02:55, 16 January 2022 (UTC)[reply]
The current WIkimedia map is already based on OpenStreetMaps data, just with wikimedia-specific style and host on WMF server instead of using OSM Foundation's resources. C933103 (talk) 07:50, 16 January 2022 (UTC)[reply]
On Wikipedia is sometimes possibility to switch, but on various tools (Wikishootme, Query etc.) is used only WMF map, which have few details JAn Dudík (talk) 12:22, 17 January 2022 (UTC)[reply]
You might have a look to the solution we use at German language Wikivoyage. I just have worked on the page of Cyprus village Lefkara. In the small cartographer window, the standard Wikimedia map is used, we add custom POIs. But if you go fullscreen, you can switch to different maps, e.g. Mapnik, which has the details. There is one problem, you have always to give permission to access data on an external server, that's also the reason, why you can not always use the Mapnik as background map as standard. We would love to have a selectable rendered map and if possible with selection of the language labels. Thats really a problem if open a map from a city in Israel or China, all city names, street names. etc. are in local language, my hebrew reading skills are not that good, but i have to surrender if a map from China oder Thailand opens in local language only. - Mboesch (talk) 10:33, 20 January 2022 (UTC)[reply]
Hello and thanks for taking the time to write this proposal. We reviewed this proposal as a team and have determined that this is out of scope for our team but an idea that's valid nonetheless. I am therefore moving it to the Larger Suggestions Category. Thanks again! Regards, LDelench (WMF) (talk) 15:13, 28 January 2022 (UTC)[reply]
Problem: We have a lot of archive pages. They are actually a kind of separate entity, but we store them next to other discussions and even in namespaces where we have guidelines and policies (which also interferes with the search). Therefore, pages are decorated in different ways and warning templates are added to separate them from other pages.
Some wikis try to color the entire archive page with a grayer background. (For example, in a template with a warning text that this is an archived page, a tag is added that covers all the following page content. The parser automatically adds a closing tag to this tag, which is why editors usually do not bother to put a closing tag manually at the end of pages and because of this tens of thousands of pages fall into categories with Lint errors. Template styles do not allow you to influence the entire page. It is inconvenient to demand and monitor the closing tag in all the many archives and no one is going to. Therefore, the situation is rather hopeless. Also, due to the large tags wrapping the content, the error detection tools in the Special:LintErrors stop showing the exact location of the error.)
Some wikis hide edit buttons in headers (using Behavior switches). But sometimes it is more convenient to fix or copy something by opening a small section for editing, rather than an entire page.
Proposed solution: The ability to switch pages to a special content model or otherwise assign them a group to which a separate warning can be displayed when editing, a separate visual design for pages, and, possibly, setting the level of protection. Each wiki, in its own way or following the example of other wikis, could customize the design and behavior of such pages. Maybe local special styles would be applied to these pages, or an appeal to the Phabricator would be required. When editing such pages, we could customize the warnings displayed. For some wikis, it will be useful to be able to restrict the editing of only these pages for ip-editors (after all, no one monitors vandalism in the archives).
Who would benefit:
Wiki-sites - a centralized approach to archive design will reduce the number of Lint errors and design methods used through templates on each archive page.
Participants will get a way to separate archives from other pages and apply common protections and design to them.
Hello and thanks for taking the time to write this proposal. We reviewed this proposal as a team and have determined that this is out of scope for our team but an idea that's valid nonetheless. I am therefore moving it to the Larger Suggestions Category. Thanks again! Regards, LDelench (WMF) (talk) 15:21, 28 January 2022 (UTC)[reply]
Support The situation isn't desperate, but archive pages are their own distinct entity, and they should have a distinct tag to go along with that. {{u|Sdkb}}talk04:31, 29 January 2022 (UTC)[reply]
Problem: Projects to make Wikimedia articles spoken have not gone ahead and/or the number of audios compared to the number of articles is negligible. This is caused by two reasons: Few editors know how to make these audios and over time these audios become outdated by the edits made.
Proposed solution: One of the possible ways to expand and improve this idea is to make software that reads (with pre-established rules) the text of articles in all Wikimedia projects in all languages automatically, allowing people to choose to listen or read, observe misspellings more easily to correct them, learn the pronunciation of words and the visually impaired can benefit from this.
Who would benefit:
More comments: You might find interesting pronunciation lexicons for XHTML and SSML attributes in XHTML. There could be wiki syntax, possibly templates, for listing pronunciations which could be aggregated into pronunciation lexicon resources referenced with document metadata. There could also be one or more wiki templates for rendering XHTML spans with SSML attributes. As for which document content to synthesize, this could also be done using cascading stylesheets using the CSS Speech Module, specifically the speak property. (AdamSobieski idea)
Agree I think this would be a great idea. This would surely help out those with visual impairments. Although they have TTS, these can often mess up the formatting and read unnecessary information (such as citations) in a way that would confuse a listener. Perhaps before software is made, users can upload audio of them just reading articles? Jmaxx37, 02:10, 11 January 2022 (UTC)[reply]
Automated text reader option would be nice, like press a button and the page is converted to audio on the fly. You would need a way to skip sections and return to the ToC. Would be heavy on bandwidth compared to text, but light compared to video. Great for use when driving. · · · Peter (Southwood)(talk): 07:32, 11 January 2022 (UTC)[reply]
Yes, I'm aware. But this project only has 4 languages available and even with a page explaining it, I didn't understand how to download it. (sorry) Maybe if I get more stuff it can be used to read the text automatically. --N4CH77 (talk) 12:11, 11 January 2022 (UTC)[reply]
Browsers have an entire Speech synthesis api these days.. Why are we not using that ? Seems simpler/more durable. Also, I can just select a page in my browser and have the browser read it to me. Been an option for about 8 years now I think. On my phone i can select text and choose "speak". Rebuilding things that the OS or browser can already do is generally a bad idea, we are NOT better at it than Apple or Google. —TheDJ (talk • contribs) 12:44, 11 January 2022 (UTC)[reply]
At least, for me, these browsers don't work the right way (Reading unnecessary parts, wrong pronunciation, reading in a disordered way and in quotes and in images they don't say what it is, it only reads the text below thus harming readers and the visually impaired). I don't know what a new software idea that reads with pre-established rules and correctly has to "bad" and at no time did I say that you are better than Apple or Google (and why this is taken into question ¯\_( ツ)_/¯) --N4CH77 (talk) 15:55, 11 January 2022 (UTC)[reply]
This could probably be written reasonably well for languages like Spanish, where any spelling has precisely one way it could be pronounced. Writing it for languages like English, where there are a lot of exceptions, would be much more difficult, and writing it for languages like Hebrew, where vowels are frequently omitted, is probably impossible. Animal lover 666 (talk) 19:47, 11 January 2022 (UTC)[reply]
It doesn't have to be done all at once (especially since I know it will take time to program these languages) and the pronunciation doesn't have to be THE MOST PERFECT in the world, it just needs to be understandable —N4CH77 (talk) 20:38, 11 January 2022 (UTC)[reply]
I still think that this would be impossible for languages like Hebrew and Arabic (although simple for Yidish, which has a 1:1 correspondence for words which aren't from Hebrew or Aramaic) and very difficult for languages like English and French. Animal lover 666 (talk) 09:23, 12 January 2022 (UTC)[reply]
Text to speech engines do the work. Most of the time they work fine. Just copy any paragraph into Google Translate and click the Play button to listen to how they pronounce it. It is indeed troublesome for languages like Japanese where a single words have multiple possible and distinct pronunciation depending on context, but most modern text to speech engine have reasonable accuracy rate at guessing which pronunciation to use, according to my understanding. And they would work much better than anything developing from new by the community tech team. C933103 (talk) 00:24, 16 January 2022 (UTC)[reply]
The reading incorrect parts thing and the wrong order thing can probably be improved by improving accessibility of Wikipedia's website, allowing the website to properly tell the browser which parts should they read. And I think it would also be much easier to done and have much higher chance to accomplish than creating an entirely new software just to read Wikipedia. C933103 (talk) 00:30, 16 January 2022 (UTC)[reply]
Hello and thanks for taking the time to write this proposal. The needed support of voice media to include and disseminate more knowledge makes complete sense. However, we reviewed this proposal as a team and have determined that this is out of scope for our team due to the nature of its technical complexity but an idea that's valid nonetheless. I am therefore moving it to the Larger Suggestions Category. There, it will still allow folks to show support and help the Community Tech team communicate how the community perceives this need to the leadership at WMF. Thanks again. Regards, NRodriguez (WMF) (talk) 15:28, 28 January 2022 (UTC)[reply]
Support I think it would be really interesting to have an easy way to speak the pages, regardless of operating systems or browser support, so work in that area looks useful.
If we look at https://en.wikipedia.org/wiki/Canada, there is a spoken version, but https://en.wikipedia.org/wiki/Wikipedia has no spoken version nor alternatives (like a generated spoken version). And even with the Canada article you have to already know that it can be spoken and click on a tiny icon, so there is room for improvement. Having that feature work for both people with and without visual impairment is important as the later could help promoting that feature and also enable more people to use Wikipedia in general (you could for instance listen to Wikipedia while doing other things, or some people might not find it great to read an article on the tiny screen of a smartphone, or might have issues with screens, etc). GNUtoo (talk) 21:41, 1 February 2022 (UTC)[reply]
Oppose crucially the proposal doesn’t say who would benefit. Is the proposal assuming a need that doesn’t exist? For example do the visually impaired already have screen readers that do this for them? Siri certainly makes a good attempt at reading anything you point it at. Unless the need is clarified with would probably be better placed in making content more accessible to third party screen reading technology. Lineslarge (talk) 17:27, 2 February 2022 (UTC)[reply]
OpposeScreen reader software already exists and is routinely used by blind people. It would be pointless to try to replicate that just for use on Wikipedia. However, if there is no semantic markup on Wikipedia that allows people using screen readers to easily navigate, that should be added. Silver hr (talk) 20:57, 3 February 2022 (UTC)[reply]
Support Probably mostly useless for blind people, which AFAIK already have their preferred software for such things, but quite useful for everyone that would like to know about a subject without using the eyes - while traveling, at the beach, while relaxing, whatever. - DarwinAhoy!14:02, 5 February 2022 (UTC)[reply]
I was just discussing a similar thing the other way around here. (Check mostly the last comments in that conversation, especially the links provided in them. The rabbit hole goes a bit deep.) I'd be happy in seeing this getting done. - Klein Muçi (talk) 00:11, 26 January 2022 (UTC)[reply]
Hello USI2020! First off, as you obviously know, this proposal is of great interest to Community Tech, who use preload tmeplates here in the survey! So we a vested interest to improve this :) However I worry we're asking for too many things here. Discussion Tools is under active development, so bugs like phab:T285358 and phab:T269310 should be handled by them in the near-term. Meanwhile, there are workarounds for phab:T299544 (we use them here in the survey). I think what you want, and what we want, is basically a "preload TemplateWizard", where you are prompted with a visual form to fill out the values for a template. The template itself will be translatable (like Template:Community Wishlist Survey/Proposal, so you end up with localized labels. Would that work for you? If so would you mind rewording your proposal to focus on that, or I can do it for you? Otherwise, if you don't mind, please select one of the issues you mention, or we can offer to move this to our Larger suggestions category. I'm sorry we're asking this so late... we have until 18:00 UTC! Thanks, MusikAnimal (WMF) (talk) 02:35, 28 January 2022 (UTC)[reply]
This proposal is a Larger suggestion. There is no guarantee this proposal will be implemented. Supporting the idea helps communicate its urgency.
Support * Mustafdesam * very useful 19:08, 8 February 2022 (UTC)
Oppose On principle, it is a really bad idea to hard-code funding allocations. Creates laziness and bureaucracy, and once you have created interests hanging from (what now would be a 1%), these become nigh impossible to revert, even after there is no longer need for whatever was mandated in the very first place. Opposed on principle. XavierItzm (talk) 20:19, 1 February 2022 (UTC)
Weak oppose Having just voted to support the 1% proposal above I think this would actually undermine anything that might accomplish. The 50 most popular might not necessarily be the highest and best fixes we need to do ... there might be small, obscure fixes that if made could make it much easier to fix others, or obviate entirely, the need for many more popular fixes. Or a popular proposal might require so much work as to make all the others go by the boards. Daniel Case (talk) 19:26, 7 February 2022 (UTC)
04:25, 31 January 2022 (UTC)
Comment Please invest more than 1 minute in writing a good proposal. The world is watching this conversation. --Valerio Bozzolan (talk) 16:40, 11 February 2022 (UTC)
Strong oppose - While the content may be there (for English), I do not see enough editors willing to contribute (as editors). In addition, the idea of 'customizable-content-selection' is non-trivial to implement, and I currently do not see the manpower available. As noted above: In my opinion, 'content-selection'/'censorship' needs to be implemented off-wiki (that is: in the app).-Eptalon (talk) 21:04, 30 January 2022 (UTC)
Strong support will be very useful to be able to have instant chats. Someone has suggested they can be used to have lessons for wikiversity courses. I agree with this compelling argument, it will be possible to set a scheduled 90 min chat as a lesson, and it’s content will be archived for people in the future willing to learn that lesson. In Israel, there are groups in WhatsApp with scheduled lessons and a teacher for high school students and it’s useful and works, so there’s no reason such an idea won’t. Also the creator of the course will be able to verify his identity easily because it will be using the same account system. There’s no reason modding this will be different from modding talk pages, actually it will be easier because users won’t be able to vandalise other comments, and their comments will be signed automatically. -Gifnk dlm 2020 From Middle English Wikipedia 📜📖💻 (talk) 18:17, 28 January 2022 (UTC)
Neutral Wikipedia is not a web host, social media. However Wikipedia has some IRC discussion channels, and we have Convenient Discussions by Jack who built the house: c:User:JWBTH/CD Thingofme (talk) 13:22, 5 February 2022 (UTC)
