Page MenuHomePhabricator

Links to watchlist items in email notifications which include a dot / full stop are not clickable in Gmail
Closed, DuplicatePublic

Description

When I get an email for a changed page on my watchlist, if the page title contains certain characters (e.g. a full stop/period <.>), then Gmail renders the link only up until the full stop.

For example:

  1. Someone edits this en.Wikisource page:
  2. I get an email notifying me that it's changed, in plaintext, including this url:
    • https://en.wikisource.org/wiki/Page:Lancashire_Legends,_Traditions,_Pageants,_Sports,_Etc.,_with_an_Appendix_Containing_a_Rare_Tract.djvu/258
  3. Gmail renders this plaintext url into html, with the following link, followed by unlinked text:

This seems to be because of the way that Gmail tries to make sense of plaintext urls (assuming it's the end of a sentence), rather than a bug in the email notification system (Extension:Email notification?), but it means that all of our users who use Gmail (probably a not insignificant number), and I guess many other email systems which try to parse these plaintext urls will be inconvenienced where page titles have these characters in them (it makes these emails very irritating!)

I couldn't find any bug reports or feature requests on MediaWiki or here about this, and there could also be all sorts of other circumstances when this extension sends out emails with urls that contain characters that major email clients don't render correctly that we're not aware of.

How much work would it be to provide an option to send these email notifications out in html instead of plaintext? And how many new users do you think would be negatively affected if this became the default at sign-up?

Event Timeline

Mjgilson created this task.Aug 21 2018, 7:39 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 21 2018, 7:39 PM
Reedy renamed this task from Some Extension:Email notification links not working in Gmail to Email notification links not working in Gmail.Aug 21 2018, 7:40 PM
Reedy added a project: MediaWiki-Email.
Mjgilson updated the task description. (Show Details)Aug 21 2018, 7:43 PM

P.S. For what it's worth, the email notifications I'm getting from Phabricator about this are in html, and this site includes html (default) and plain text email format options. Would it be possible to use this codebase, rather than re-inventing the wheel?

Aklapper renamed this task from Email notification links not working in Gmail to Links to watchlist items in email notifications which include a dot / full stop are not clickable in Gmail.Aug 22 2018, 9:20 AM

Changed the task summary because links generally work. It's just links with specific characters that do not work in Gmail.

This seems to be because of the way that Gmail tries to make sense of plaintext urls (assuming it's the end of a sentence), rather than a bug in the email notification system

Correct. Or making those links less readable for humans by URL encoding such characters.

How much work would it be to provide an option to send these email notifications out in html instead of plaintext?

See T15303

Would it be possible to use this codebase, rather than re-inventing the wheel?

Not possible because one of the systems is not a wheel.

I'm not sure what is asked for in this task. I'm going to boldly merge this task into T15303: Implement HTML e-mail support in MediaWiki as it would solve the problem, and close this task as a duplicate.

I don't think this is a duplicate, since users may prefer to receive plain text emails.

I've seen similar problems on social sites when sharing links, or even on IRC. Dots and commas are usually not URLEncoded, but the links seem to break consistently in several clients that try to parse a plaintext URL into a clickable link:

  • Punctuation at the end of the URL (like dots, commas, or exclamation/question marks). A single punctuation character in the middle of the URL doesn't cause issues, generally
  • Two or more consecutive punctuation characters (a dot and a coma, several dots...)

Another option may be to use links using the curid parameter instead of a the title, which also would make the link valid even if the page is renamed.