I do feel like this would be a bit hard to make it scalable globally but I thought it would be worth a discussion anyway.
Please check the idea here: https://en.wikipedia.org/w/index.php?title=Wikipedia:User_scripts/Requests&oldid=1089378556#Script_that_adds_the_possibility_to_give_template-replies_with_1_button
Do you think that could be implemented as a native function?
I'm pretty sure that one of the communities has something similar, built into the toolbar of the 2020 wikitext editor. It's mostly used by vandal fighters and RecentChanges patrollers to leave messages on new editors' talk pages. @Patrik L., is that a cswiki script/gadget?
There is a gadget on huwiki that matches Whatamidoing’s description (maybe you remembered that, I think I’ve talked about it related to the preload support in New Topic Tool), but it’s different from what Klein Muçi is asking: warning.js can only start new topics, while this request is about adding replies to existing topics.
(Actually, warning.js doesn’t even have a notion of “topics”—it just has four modes (prepend—e.g. amboxes—, append—e.g. message templates—, comment out the rest—e.g. copyright violation notice—, and replace); if append mode is used and the content happens to include a topic header, it will result in a new topic.)
Maybe reading the other part of the aforementioned discussion will bring more clarity in what I'd be trying to achieve with the said function: https://en.wikipedia.org/wiki/Wikipedia:User_scripts/Requests#Script_that_adds_the_possibility_to_give_template-replies_with_1_button
If you see my current last answer there, you'll see that I do mention 1 specific list of templates I'd like to be able to use with a function like this. We're talking about templates such as "done", "read", "agree", etc. This is no news with me because ever since the reply tool was first introduced I've asked for the ability to vote and thank with it. (I'd still like it if for the thanking function the native "thank this user" function was used and for voting we had an overall better interface that also allowed for better "vote counting".) This is in the same waters. Generally I do enjoy templated answers and I think they're a great "solution" to "one-liners". This isn't as much related to warnings and vandal fighting as it is to organizing everyday wikiwork. Actually the whole inspiration behind this came because I was thinking of asking for a script that gave me a button on a press of which I could quickly add a reply on the lines of "I've seen this request and I'll answer shortly." because Wikipedia has no "seen/read; online/offline" function. (That's a good thing I believe.) There I saw the {{Read}} template and with it the whole list I mention above. This is when I started thinking that most of them would also be pretty useful in everyday work in many wikis, hence the user script request and this discussion here.
The scalability problem I mention comes because I imagine that if such a tool would be made possible as a native function, it would also force each wiki to first import all those templates, that is, unless we are willing to make those templates also ingrained in the function itself somehow.
Imagine Articles for Deletion at enwiki, except that the page could offer a form for creating the page, pre-set responses, automatically count votes, be tagged by subject area (like you might tag a blog post), be visible on and editable through multiple pages or even multiple wikis (imagine if a Commons deletion discussion could be seen and edited from the talk page of a Wikipedia article that was using the image in question), and put itself in a category or dashboard for admin attention when it was seven days old plus had comments from at least three editors, or relist itself if there weren't enough comments.
There is a joke souvenir in the US. It's a T-shirt that says "My grandparents went to <famous holiday destination>, and all I got was this lousy T-shirt". They designed an awesome communication system, but all we got was the first phase.
Well, if that was the original vision of Flow, it sure looks interesting (and I feel like it would encompass my request of templated answers).
The original vision for Flow was specifically designed around enwiki's AFD process and ArbCom cases. It would have been awesome. We probably won't ever see anything like it.
I think one of the main reason Flow's progress was stopped was because it lacked the ability to switch back and forth between visual and source editing. It's hard to recreate immediately visually all the features you have while source editing which nonetheless can be achieved with optimization through time. But editors are usually impatient and wikis, especially EnWiki, can sometimes be pretty dynamic environments.
Tangent to this subject I can say that sometimes I feel like EnWiki does get a tiny bit more weight than it normally should in many aspects. Don't get me wrong, as the wiki with the largest numbers of editors it should get "the biggest slice", sometimes even that "slice" may not be enough for the large resources it needs to exist. But some other times the discussions start to go in subjectivity territory and EnWiki's opinions get to dictate indirectly the course of progress for many projects. Flow aside, the whole promising progress with WikiData seemed to come to a halt after the so called Infobox Wars in EnWiki and WikiData turned from a "new project that will revolutionize information gathering and displaying" to "a project that offers easy data for robots and search engines", at least in the eyes of "the general public". Content Translation Tool was at one point at the risk of taking such a similar turn as a project when EnWiki deemed it to be too risky for their standards and I do feel like part of the reason why the Review extension eventually became orphaned was because it was one of the extensions that aren't used in EnWiki. Very generally said, EnWiki likes to do things as organically as they can and that's not bad at all per se. They can afford that because of the enormous resources that they have, in technology and in working power. The problem starts when they indirectly start "vetoing" other projects which can be beneficial in other environments. Of course it's not their aim to do so but it happens by the "peer pressure" they project as the biggest community and most successful community. After all, "it's better to invest at something that it's known to work than to spend time and resources for new unreliable projects".
Look in the lower corner for a pencil icon. You can switch back and forth between Flow's visual and wikitext source mode all day long. I think Flow had some significant w:en:FUD problems. There was a point at which editors simply would not believe that Flow supported the things they wanted. At one point, someone was edit warring over the documentation to insist that Flow was replacing wikitext, despite staff telling him that he was wrong. I remember an exchange between a volunteer and a WMF staffer in which the volunteer insisted that it was impossible to talk about math in Flow, and the staffer wrote that he had seen math equations typed into a Flow comment with his own eyes, and was the volunteer calling him a liar? I've certainly answered more than my fair share of the "but Flow is terrible because newbies can't change my comments!" questions.
I think that we've been seeing a shift in enwiki's expectations during the last few years. Years ago, editors wanted to do as much as possible by themselves and certainly to have full control of content. Now there are some complaints that the WMF isn't telling other wikis what they're allowed to post, the WMF hasn't assumed control of volunteer-created scripts and gadgets, etc.
I think Klein Muçi didn’t mean that you can’t use wikitext in Flow at all, but that you can’t do whatever you want (and you’re used to). Talk page header templates and WikiProject boxes? They look awful in the teeny-tiny narrow sidebar, especially when they’re designed to have 10% margin on each side. w:Template:Archive top? Only the way Flow provides it, without possibility to use colors to indicate the outcome, write something at the bottom, and so on. Putting out-of-scope parts of a discussion in a separate collapsible box? Forget it, you can’t do anything in wikitext that affects multiple comments.
And also things that could have been (or even have actually been) improved over the years, but these years were after Flow has already lost: for example that Flow builds on Parsoid, which is to date still not 100% par with the legacy parser people are used to, but was even more buggy back then.
I've only had the chance to use Flow here. Back then when it was discussed on EnWiki I wasn't much active around beside my homewiki, wasn't too versatile on the whole wiki thing and only got the chance to mostly read about it than actually use it. I remember trying it once, loving the idea that things were finally changing from the "ugly black and white editing interface that Wikipedia had" (I didn't even know about syntax highlighting back then) and then being sort of frustrated while using it and switching back to the old way. I also remember leaving with mixed feelings from that episode: Scared that a thing that I didn't know how to use was coming eventually whether I liked it or not and also sort of optimistic that "everything was better than the current editing interface" and that most likely the change would be for the good. (I sort of feel the same about the new Vector skin coming now.) The reply tool felt amazing almost immediately though, it looked like it handled wikitext way more smoothly and acted more intuitively in some aspects (the @=mention feature that got popularized in social media that is still "missing" here). I was optimistic for its future and would have accepted with patience every "visual feature" over the source editing mode but others weren't so patient and FUD is often present in these cases.
As for the enwiki's expectations change... You're right on that aspect. Funny enough, I may be one of the users that are vocative on that matter (https://meta.wikimedia.org/wiki/Wikimedia_Forum/Archives/2022-04#What_Wikipedia_means_in_different_projects - I failed to attract much attention) but I still believe EnWiki inadvertently vetos some projects that can be pretty important to small wikis. This discussion (https://en.wikipedia.org/wiki/Wikipedia_talk:WikiProject_Tree_of_Life/Archive_50#The_automatic_taxonomy_system) + 1 with a similar length at WikiData and 1 at a user's personal talk page happened just because we suggested to utilize WikiData for building a suite of Lua modules capable of handling the taxonomy templates in EnWiki instead of having 97,526 individual wikitext templates that it currently uses. In the end WikiData editors and EnWiki ones refused to collaborate on a solution for the matter and nothing happened. There were a couple of small projects that were hoping for the creation of that module suite, my homewiki included, just so that we could finally have a system similar to EnWiki on our biology articles but alas the only viable solution that was left for us all was to catch up with a decade worth of work and import + localize ~100 000 individual templates if we wanted such a thing. This is not the perfect example because the changes this time involved EnWiki directly but it's the most recent one after those that were mentioned above.
Syntax highlighting didn't really work until a few years ago.
I agree that we have some structural problems, and I suspect that Tacsipacsi, who is one of the primary technical editors at a wiki with 1500 registered editors each month, could empathize with you in every detail. We should not be re-inventing the wheel at every wiki. Common citation templates and basic Wikidata-enabled infoboxes should be centrally managed, available by default at all Wikipedias, and translated into every language. All the Wikipedias should be able to use these "normal" features without needing to get enwiki's agreement or to find and train local technical experts.
Oh, I didn't know that. Maybe it wasn't my ineptitude then.
As a matter of fact, I've tried starting something about the citation templates in the past (https://meta.wikimedia.org/wiki/Wikimedia_Forum/Archives/2020-09#CS1_module_-_Global) which failed to attract any attention whatsoever despite my insistence. It was supposed to be a "crude solution" while global templates were established.
But yes, I'm active on at least 2 small Wikipedias (sq & la) and both technical communities there have been eager for that idea for ages. The JSON solution in Commons I've seen around (https://commons.wikimedia.org/wiki/Data:I18n/Uses_TemplateStyles.tab) looks like a good start (?) for that.
For global templates, you want to make friends with @Amire80. He's been advocating for them for years, so he'll know if anything ever happens. There is an old discussion at Translatable modules and an attempt at Multilingual Templates and Modules that might be worth putting on your watchlist. (My theory is that if anything ever happens, someone might leave a note on one of those pages.)
Yes, I've had the opportunity to talk with Amire80 in regard to global templates/modules. Thank you for showing me the aforementioned pages! :) -
