Last modified: 2014-03-23 20:10:44 UTC
I got this email: Wikipedia user This, that and the other thanked you for your edit on Thisisatest. View your edit: http://test.wikipedia.org/w/index.php?title=Thisisatest&oldid=169814&diff=prev ----- Nice! But after seeing the link of the edit I also wanted to see who was thanking me (a natural human reaction). A link to the user page would be convenient, but it is not provided in the email, neither in the web based notification. Users had to find manually, and since the result is under the User: namespace the probable result for many will be zero results. Just adding the link to the web notification and this string to the email would be enough: Check $USER's page: http://...
According to the design specs, we should only provide 1 link in each notification. In this case we can choose between the diff and the user. If we don't link to the diff, the recipient has no way to know which edit they are being thanked for. But if we don't link to the user, it's hard to respond to the thanks. Do you think this is a case where we should break the "1 link rule" and provide 2 links to the user?
Personal opinion: When it comes to Thanks, it makes sense to know WHO is thanking you for WHAT. No matter what the generic design specs say.
*** Bug 48943 has been marked as a duplicate of this bug. ***
This is fixed in the flyout and archive versions, but not in the email version yet.
Can we tag this as "easy"?
Quim: I don't think so. This is already linked for me in HTML. However, those users who for some reason haven't changed from the default plain text will not get links like this... I wonder if Echo should send a plain text URL (which the client will hopefully link) for the agent.
Prioritizing this as Lowest, since this seems to be the actual priority for this request that, yes, affects only users willing to receive plain text Echo notifications. Alex, you say that the fix is not easy. Where does the complexity come from? Is the implementation complex or is there something else?
