| Technical13 | |
| Jun 13 2013, 6:24 PM |
| F36038500: Screen Shot 2023-01-07 at 10.45.14 AM.png | |
| Jan 7 2023, 6:47 PM |
| F36038502: Screen Shot 2023-01-07 at 10.45.22 AM.png | |
| Jan 7 2023, 6:47 PM |
| F3854204: sc2.png | |
| Apr 9 2016, 2:42 PM |
| F3854272: sc3.png | |
| Apr 9 2016, 2:42 PM |
| F3841756: 1.png | |
| Apr 8 2016, 4:14 AM |
| F3841759: 2.png | |
| Apr 8 2016, 4:14 AM |
| F3841761: 4.png | |
| Apr 8 2016, 4:14 AM |
I would personally be more likely to use the thanks feature if there were links for it on [[Special:Watchlist]] and [[Special:Contributions]] instead of having to navigate to &action=history or view a diff which actually causes the effect of having to confirm the thanks twice (3 clicks to "thank").
See Also:
T57648: Remove Thanks from History pages
I'm sorry to be tuning into this ticket only now. Did anyone in Design approve the interface changes on Watchlist and Contributions? If not, can someone please post a screenshot that shows how this will display on typical pages (the examples above are very stripped down)? I'd like @Pginer-WMF to have a pass. Thanks.
OK, so if some user will put some nonsense in the page, but reasonable summary, you are going to thank him just because of the summary without looking at the actual action? That sounds... scary...
@Danny_B I don't see a reason, why an administrator should add nonsense with RFC closed summary into RFC page. Except it would not be an administrator. But then it would be too suspicious to thank and better to check it out...
I didn't write "an administrator", but "some user". Neither I was talking about RFC page.
So how many such actions, where you can blindly believe what has been done according to the summary? A dozen per year?
@Danny_B But I talk about these. According to the summary I usualy thank about once or twice a day. And these steps between seeing, what anybody made and actually thanking him for the change are too pointless
No, they are not pointless at all. They actually guarantee that nobody will thank blindly without actually seeing the action to be thanked.
Correct. Including code bloating which will carry the payload of more data needed to be transferred, higher memory usage due to more complex DOM etc. etc...
Such feature should not be part of the core, but can be easily achieved by on-demand (opt-in) gadget. The amount of thanking people is small, the amount of those who do it periodically is yet smaller. Why annoy others who don't (want to) use it with mandatory pushing it to them in the interface?
Quite often actually, in my experience.
Often I know the main editor(s) to an article, or its current torch-bearers, and have full confidence in their honesty, and like to show appreciation when I see they have made a sizable or difficult edit as evidenced by their edit summary and my prior knowledge of the ongoing discussions on the talk page, or open todo items.
A lot of tools (gadgets, scripts, bot frameworks) indicate what was done using the tool, fairly precisely, and I trusty their edit summary.
An obvious special case of that is when the UI says it is a revert, we believe it is a revert. This is especially helpful for a nonsense edit to a large page, where the revert is a very large diff page, which can be painful to load. We dont need to check the diff to know it was a revert, and it is usually very obvious what was being reverted.
My personal use case is trying to thank the first edit to a page. If I am on the page history, there is a thank link. I use it. I do not always check that the article was perfect on the first edit, because I've seen their contributions to it. I'd also like to access that feature from the Special:Contributions for the new page edit; I am often trawling through peoples very old contributions looking for especially good edits to thank them for.
I suspect that patrollers will have an interest it this appear on Special:Watchlist, but I cant talk about any usages for that, as I am not often patrolling anymore.
However as @He7d3r was pointed out above, once T60485 is done there will be many more use cases for thank links appearing on Special:Watchlist, as finding the relevant log entry on Special:Log can be quite painful.
But if it can be done with a gadget cleanly, that would be OK too, and would be a good proof of concept to see how widely this feature might be used.
@darthbhyrava: This issue has been assigned to you a while ago. Could you please share a status update? Do you plan to work on fixing the patch in Gerrit based on the received feedback?
If you do not plan to work on this issue anymore, please remove yourself as assignee (via Add Action... → Assign / Claim in the dropdown menu) so others could work on it. Thanks a lot!
@darthbhyrava: I am resetting the assignee of this task because there has not been progress lately (please correct me if I am wrong!).
Resetting the assignee avoids the impression that somebody is already working on this task. It also allows others to potentially work towards fixing this task.
Please claim this task again when you plan to work on it (via Add Action... → Assign / Claim in the dropdown menu) - it would be welcome! Thanks for your understanding!
There have been objections that no-one would want to give thanks for an edit they haven't seen. Please note that there are add-ons which allow users to view diffs directly in the Watchlist. Thanks.
It's easy to think of use cases that might have someone asking someone else
to do something with material prepared offline or to execute or resume
executing a known routine. When there is an indication that task execution
has commenced thanks might be warranted. How common such situations might
be I don't know. I have been grateful for someone resuming execution of a
long-dormant bot at Wiktionary.
It has been a while, but I have a working script to add thanks links over at https://github.com/chicocvenancio/wiki_scripts/blob/gh-pages/thankLinksInWatchlist-pt.js It is localized to portuguese and doesn't quite handle genders properly right now, but if there is interest I could clean it up and add i18n for it.
I copied a few of the functions from ext.thanks and added the links manually to the dom.
Hey, is it set for whole wiki or is it just a user script? If there are people, who think its not worth coding, why not to have it as an option. I would love to use it on cs.pw, commons, cs.wv etc.
I have it set in my global.js and it adds the links to every wiki. Since you're demonstrating interest, I'll see if I can add more languages to it, right now it is only in Portuguese.
Change 282616 abandoned by Thiemo Kreuz (WMDE):
[mediawiki/extensions/Thanks@master] Add thank links to Special:Watchlist and Special:Contributions
Reason:
I'm interested in helping with this task (and later T90404_! I'd like to get this code loading on mobile as well as part of the fix.
Change 867732 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):
[mediawiki/core@master] WIP: Generalize History pager tools for use in other contexts
I think the main crux of the problem here is we have no equivalent hook for onHistoryTools and the styling of the rollback link on the contributions layout is inconsistent with history.
I've begun a slightly different approach here to generalize the onHistoryTools hook so it can be used to generate toolboxes on all Pager pagers. I think this adds a useful capability to these pages.
Sharing early for feedback and any red flags with this approach :)
Change 867732 merged by jenkins-bot:
[mediawiki/core@master] Generalize History pager tools for use in other contexts
Change 868480 had a related patch set uploaded (by Catrope; author: Catrope):
[mediawiki/extensions/Thanks@master] Load Thanks JS on more special pages
Change 868480 merged by jenkins-bot:
[mediawiki/extensions/Thanks@master] Load Thanks JS on more special pages
Change 870738 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):
[mediawiki/core@master] Fix history pager tools
Marking this as resolved. I've noted this as a risky change under deployments. I'm also adding User-notice as although obvious it's probably worth reporting this to community given the old bug number and the fact it was on wishlist.
Follow up patches have been logged:
And following tasks:
@Tgr I have a few questions for you on https://gerrit.wikimedia.org/r/c/mediawiki/core/+/867732 if you could please answer so I don't lose them and get those captured in patches or tasks accordingly. Thanks in advance!
Pointing out a bug on dewiki: discussion. Not sure yet if this is something to resolve purely on our side.
@Jdlrobson we are discussing re-opening this task on dewiki. Could you please have a look into this? Thanks!
I'll take a look Monday. In mean time it would be helpful if you could summarize the issue being reported in that thread as German is not my native tongue and I couldn't quite make sense of the problem.
Just a note this is what I see before and the change we intentionally applied.
Before change:
after change:
Sure! There are two problems being discussed there atm, of which the imo more important one is T326399.
With regards to this task, on dewiki we have the problem that we had hidden the rollback link on the watchlist via Common.css. Since this change, the thanks link is visible and because of the missing rollback link, there are empty brackets or useless pipes everywhere. However, there seems to be a consensus on dewiki to revert our customisation, which would resolve the problem. So there is probably no action necessary here for now.
I've also gotten some similar complaints from English Wikipedia editors who wish to hide the rollback link on the watchlist.
For rollback links, there's a preference to require confirmation when clicking on them. This doesn't help if the concern is that they take up too much space, but it might help if they're concerned about accidentally clicking them.
https://en.wikipedia.org/wiki/Special:Preferences#mw-prefsection-rendering-advancedrendering "Show a confirmation prompt when clicking on a rollback link" (it only appears if you have rollback rights)