Steps to replicate the issue (include links if applicable):
What happens?:
You receive a plain text e-mail based on a system message where the URL is immediately followed by a period, causing the link not to work.
What should have happened instead?:
The link should work. The e-mail has other sentences that contain URL's at the end that don't end with a period.
Other information (browser name/version, screenshots, etc.):
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Watchlist: Fix non-functioning URLs in ENOTIFs by wrapping in <>s | mediawiki/core | master | +1 -1 |
Change 971556 had a related patch set uploaded (by Sjoerddebruin; author: Sjoerddebruin):
[mediawiki/core@master] Watchlist: Fix non-functioning URL
In some cases that's even desirable, see T257966: URL shall be terminated by %2E or _ if page name ends with dot
But maybe not here. So the URL should be wrapped in angel brackets.
Just a reminder that the problem is still present. An e-mail sent out from "Wiktionary" <[email protected]> yesterday:
The Wiktionary page айморт has been deleted on 2024-01-18 by Mx. Granger, see https://en.wiktionary.org/wiki/%D0%B0%D0%B9%D0%BC%D0%BE%D1%80%D1%82.
links to a wrong URL with the period added.
I checked my e-mail client and confirrmed that if the URL is bracketed before a period, it will work correctly without such errors.
Thank you for reminding me. I was thinking around that period about what the cleanest/best solution would be. I'll rather apply the same treatment with angle brackets to all mails as there might be some edge cases, but there might be a less dirty way to do that and I don't know how.
We had a small discussion at the Hackathon today and based on further browsing in the code we'll apply angle brackets to all the links in the code itself, also removing the need to update all translations.
Change #971556 merged by jenkins-bot:
[mediawiki/core@master] Watchlist: Fix non-functioning URLs in ENOTIFs by wrapping in <>s
