Page MenuHomePhabricator

Implement HTML e-mail support in MediaWiki
Open, MediumPublicFeature

Description

Author: dunc_harris

Description

There should be an option to receive emails in either plain text or html format (note that Echo already has HTML email, this is for other emails).

Receiving emails in html format would allow the sender to use wiki markup to help convey his message across.

The standard core emails, i.e.

  • email confirmation and password reset,
  • enotiftalk,
  • enotifwatchlist

would benefit from being available in HTML format as well.

An initial implementation

  • keep the very same content
  • and ideally reuse translations (split in multiple messages?);
  • put links in a tags;
  • ensure choice, between plain text and HTML, either a) client-side (when the plain text+HTML message is delivered), and/or b) server-side (configuration setting to decide default/only option), and/or c) user-side (preference somewhere).

Subsequent steps

  • change defaults;
  • add styling;
  • augment content;
  • allow other pieces of core and extensions to reuse standard parts for their own emails or to alter existing ones (this should preferably take into account that Echo has HTML email and figure out a way to reduce/avoid redundancy);
  • deprecate overlapping features in other areas of the code.

Advantages

  • [high] links which don't break, even in stupid clients unable to handle punctuation and even with long percent-encoded titles,
  • [mid] choice and customisations,
  • [minor] compactness,
  • [debatable] prettyness.

Disadvantages (in case of inadequate implementation)

  • preferences clutter,
  • lack of support in clients,
  • degradation of i18n for years until translations are re-added in all languages.

Current todos

  1. Finding a way to not have separate messages for plain-text and HTML, which is something I mentioned in one of the patches.
  2. There still needs to be a way to make templates for the emails, i.e., some sort of wrapper that the email content will be injected into.
  3. Then, of course, the actual graphic design of the templates themselves, including approval of the design by whoever would be relevant in WMF.
  4. Working on improving the content of other emails other than just page change notifications.

Implementation tips

Creating HTML emails that look good in common clients (which cripple the HTML in various ways) is a bit of a black art; you probably want to grab some sort of boilerplate (e.g. Zurb has some nice ones).

Some interesting stuff you can do with HTML email: T106651: Enrich Wikimedia email with Schema.org metadata

Internship project details

  • Primary mentor: @Parent5446
  • Co-mentor: @01tonythomas
  • Other mentors: (optional, Phabricator username)
  • Skills: (Phabricator tags are welcome)
  • Estimated project time for a senior contributor: (must be 2-3 weeks)
  • Microtasks: T48109, T31856, T62434

Related Objects

StatusSubtypeAssignedTask
InvalidWikinaut
OpenNone
OpenFeatureNone
Declinedrosalieper
DeclinedDevirk
InvalidPreetika09
InvalidNone
DeclinedGalorefitz
ResolvedParent5446
ResolvedGalorefitz
ResolvedGalorefitz
DeclinedNone
InvalidGalorefitz
Resolved01tonythomas
ResolvedGalorefitz
DeclinedNone
DeclinedAyahsoufan
DuplicateNone
OpenNone

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

As a quick note for both this task in general and for @rosalieper and @Galorefitz, we spoke with @siebrand yesterday, and asked him about the two approaches for this task, i.e.:

  1. Have a single i18n message in plain text and then convert the message to HTML when needed. (This is the method @Galorefitz describes in T130490).
  2. Have two i18n messages, one in plain text and one in HTML, and then choosing between the two. (This is the method used in https://gerrit.wikimedia.org/r/249155.)

@siebrand said that the latter approach is preferred, as the former single-message approach will lead to incorrect i18n when linkifying information or doing other HTML-specific formatting that sometimes comes out differently depending on the translation. Therefore for this bug we should stick with the approach used in the already open patches and keep two separate messages for each email.

keep two separate messages for each email

This is ok as long as whatever method actually has a translation (i.e. plain text, initially) is always preferred to the method which would force English onto the user.

  1. Have a single i18n message in plain text and then convert the message to HTML when needed. (This is the method @Galorefitz describes in T130490).

@Parent5446 I actually proposed the second method in my proposal, not the first, i.e.,

  1. Have two i18n messages, one in plain text and one in HTML, and then choosing between the two. (This is the method used in https://gerrit.wikimedia.org/r/249155.)

in this part :

  • When generating a key to be passed to wfMessage(), it will be assumed that if the key does not end with -html, the text is wikitext/plaintext. If the caller of the function wishes to include html in the text, the key must be appended by -html.
    • When the key sent ends with -html, we can run wfMessage($key)->exists() on it, and if it does not exist, we can use the key without the ending -html, assuming that version exists. This will be done so that even if an html version of the text exists and the caller wants to use the plaintext version, they have an option to do so. This will require discussion with the i18n team. Allowing arbitrary HTML in the messages will have security concerns that will need to be looked into and taken care of.

And as @Nemo_bis pointed out,

keep two separate messages for each email

This is ok as long as whatever method actually has a translation (i.e. plain text, initially) is always preferred to the method which would force English onto the user.

I have already accounted for that in my proposal (quoted above). Incase the html version of key (say hello-html) does not exist in a particular language, the method should automatically fallback to the plaintext version of the message (in this case, message with key hello), assuming it exists.

  1. Have a single i18n message in plain text and then convert the message to HTML when needed. (This is the method @Galorefitz describes in T130490).

@Parent5446 I actually proposed the second method in my proposal, not the first, i.e.,

I was referring to the transformContentToHtml function mentioned in Phase 1. I'm saying we should probably skip that and directly use Phase 3's concept, which does as you said. Sorry for the confusion.

This is not the best microtask yet, but definitely got something to do with i18n, and is for the MediaWiki-extensions-Newsletter :D. Candidates, T132155 needs your love!

Is a location/time during the Hackathon already known?

Is a location/time during the Hackathon already known?

I'm removing the Wikimania-Hackathon-2016 tag as this is an ongoing Google-Summer-of-Code (2016) project. Thank you for your interest @Osnard. You can comment your views on the selected proposal T130490, which tracks the progress.

@Parent5446 has agreed to mentor the same again for the upcoming Outreachy round 13 :) Adding this as a featured project now!

Hi

I was searching for Outreachy projects and stumbled upon this. I was reading these comments and quite frankly, I am much too confused. I saw the dashboard and there is an email feature in the notif's "preferences" which clearly asks for rich text and plain mails. I can't seem to know what this task requires for I think it is there already, correct me if I am wrong. I am fairly new here!

Please guide me in it. I would be really happy! Thanks a lot in advance! @Parent5446

I was searching for Outreachy projects and stumbled upon this. I was reading these comments and quite frankly, I am much too confused. I saw the dashboard and there is an email feature in the notif's "preferences" which clearly asks for rich text and plain mails. I can't seem to know what this task requires for I think it is there already, correct me if I am wrong. I am fairly new here!

That setting (Notification tab in preferences) only applies to Echo notifications.

This task is for other emails, including:

  • email confirmation
  • password reset,
  • enotiftalk
  • enotifwatchlist
  • And apparently user-to-user email ("allow the sender to use wiki markup to help convey his message across")

This task should probably be coordinated with the shepherd of T128351: Notifications should be in core.

Would @Parent5446 or some of the other subscribers on this thread be interested in mentoring this task for the Rails Girls Summer of Code: http://railsgirlssummerofcode.org? For the very first time, we are considering to submit Wikimedia's application for this program. It is like Outreachy, and has the same goal of fostering diversity in Open Source. Though it sounds from the name that the projects submitted should be in ROR/ Rails but that's not true. Projects could be any programming language. It will run between July-September 2017? In case you are interested, a faster reply would be much appreciated, as we are pretty close to the deadline to apply as an organization (January 31st, less than 6 days remaining!) :) Thank you!

Would anyone be willing to mentor this project for Google Summer of Code 2017 or Outreachy Round 14? Remember, each outreach project requires a minimum of one primary mentor and co-mentor.

Would there be any interest in mentoring this project for Outreachy Round 15? Application period opens in two days. See a few other ideas for projects that we are promoting for the upcoming round https://www.mediawiki.org/wiki/Outreachy/Round_15

Hello, @srishakatux , @Parent5446 , @01tonythomas, I wish to work on this for the upcoming GSOC round. Adding some few microtasks will help. I hope its not too early . I prefer to maximize my chances :).

Would there be any interest in mentoring this project for GSoC'18 or Outreachy'16?

@rosalieper We are currently compiling a list of project ideas for the next round. In the meanwhile, you can try to fix some bugs here > https://www.mediawiki.org/wiki/Annoying_little_bugs. That way you will be better prepared :)

Is there anyone available to mentor this project for GSoC 2018?

Tacsipacsi changed the subtype of this task from "Task" to "Feature Request".
Tacsipacsi added a subscriber: Tacsipacsi.

For the records, there are patches linked in T135484 that could be reworked (which still won't solve the problem of lack of code review though)

Due to a lack of interest in mentoring this project, I am removing the OPP tag for now.

What's going on?
There seems to be a block because someone wants that email would be encoded as plain text and HTML at the same time. It's not necessary. Please implement HTML-only, discard plain text. Plain text is no more used, it's year 2024.

I mean, look at an example of an email I receive every time someone edits the page on my watchlist.

As for mean, it doesn't look good.

I can't even understand which page it's about.

Can we consider it a bug and not a feature?

Email example:

Здравствуйте, Nikolay Komarov!

27 января 2024 участником Leokand была изменена страница проекта «Википедия» с именем «Википедия:Критерии значимости персоналий», см. текущую версию по
ссылке:
https://ru.wikipedia.org/wiki/%D0%92%D0%B8%D0%BA%D0%B8%D0%BF%D0%B5%D0%B4%D0%B8%D1%8F:%D0%9A%D1%80%D0%B8%D1%82%D0%B5%D1%80%D0%B8%D0%B8_%D0%B7%D0%BD%D0%B0%D1%87%D0%B8%D0%BC%D0%BE%D1%81%D1%82%D0%B8_%D0%BF%D0%B5%D1%80%D1%81%D0%BE%D0%BD%D0%B0%D0%BB%D0%B8%D0%B9

См.
https://ru.wikipedia.org/w/index.php?title=%D0%92%D0%B8%D0%BA%D0%B8%D0%BF%D0%B5%D0%B4%D0%B8%D1%8F:%D0%9A%D1%80%D0%B8%D1%82%D0%B5%D1%80%D0%B8%D0%B8_%D0%B7%D0%BD%D0%B0%D1%87%D0%B8%D0%BC%D0%BE%D1%81%D1%82%D0%B8_%D0%BF%D0%B5%D1%80%D1%81%D0%BE%D0%BD%D0%B0%D0%BB%D0%B8%D0%B9&diff=next&oldid=133804277
для ознакомления с изменением

См.
https://ru.wikipedia.org/w/index.php?title=%D0%92%D0%B8%D0%BA%D0%B8%D0%BF%D0%B5%D0%B4%D0%B8%D1%8F:%D0%9A%D1%80%D0%B8%D1%82%D0%B5%D1%80%D0%B8%D0%B8_%D0%B7%D0%BD%D0%B0%D1%87%D0%B8%D0%BC%D0%BE%D1%81%D1%82%D0%B8_%D0%BF%D0%B5%D1%80%D1%81%D0%BE%D0%BD%D0%B0%D0%BB%D0%B8%D0%B9&diff=0&oldid=133804277
для просмотра всех изменений,
произошедших с вашего последнего
посещения

Краткое описание изменения: /* Другие */ оформление

Обратиться к изменившему:
эл. почта:
https://ru.wikipedia.org/wiki/%D0%A1%D0%BB%D1%83%D0%B6%D0%B5%D0%B1%D0%BD%D0%B0%D1%8F:%D0%9F%D0%B8%D1%81%D1%8C%D0%BC%D0%BE_%D1%83%D1%87%D0%B0%D1%81%D1%82%D0%BD%D0%B8%D0%BA%D1%83/Leokand
вики:
https://ru.wikipedia.org/wiki/%D0%A3%D1%87%D0%B0%D1%81%D1%82%D0%BD%D0%B8%D0%BA:Leokand

Если вы не зайдёте на эту страницу под
своей учётной записью, в случае её
дальнейших изменений уведомлений
больше не будет. Вы можете также
отключить опцию уведомления для всех
страниц в вашем списке наблюдения.

Система оповещения Википедии

Изменение настройки уведомлений
https://ru.wikipedia.org/wiki/%D0%A1%D0%BB%D1%83%D0%B6%D0%B5%D0%B1%D0%BD%D0%B0%D1%8F:%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B8

Изменение настройки вашего списка
наблюдения
https://ru.wikipedia.org/wiki/%D0%A1%D0%BB%D1%83%D0%B6%D0%B5%D0%B1%D0%BD%D0%B0%D1%8F:%D0%9F%D1%80%D0%B0%D0%B2%D0%B8%D1%82%D1%8C_%D1%81%D0%BF%D0%B8%D1%81%D0%BE%D0%BA_%D0%BD%D0%B0%D0%B1%D0%BB%D1%8E%D0%B4%D0%B5%D0%BD%D0%B8%D1%8F

Удалить страницы из вашего списка
наблюдения
https://ru.wikipedia.org/w/index.php?title=%D0%92%D0%B8%D0%BA%D0%B8%D0%BF%D0%B5%D0%B4%D0%B8%D1%8F:%D0%9A%D1%80%D0%B8%D1%82%D0%B5%D1%80%D0%B8%D0%B8_%D0%B7%D0%BD%D0%B0%D1%87%D0%B8%D0%BC%D0%BE%D1%81%D1%82%D0%B8_%D0%BF%D0%B5%D1%80%D1%81%D0%BE%D0%BD%D0%B0%D0%BB%D0%B8%D0%B9&action=unwatch

Обратная связь и помощь
https://ru.wikipedia.org/wiki/%D0%92%D0%B8%D0%BA%D0%B8%D0%BF%D0%B5%D0%B4%D0%B8%D1%8F:%D0%A1%D0%BF%D1%80%D0%B0%D0%B2%D0%BA%D0%B0

Dear Andre @Aklapper, please help me bring someone's attention to put in into a sprint or escalate priority. These ugly URL-encoded strings should not be parts of Wikipedia.

Dear Andre @Aklapper, please help me bring someone's attention to put in into a sprint or escalate priority. These ugly URL-encoded strings should not be parts of Wikipedia.

See also https://www.mediawiki.org/wiki/Bug_management/Development_prioritization

It is very unlikely that this will be worked on by WMF any time soon. It's a low value feature request (compared to the 50 000 other feature requests and bugs). Unless WMF happens to have to fix something very critical in this same code area, it's not likely they will allocate resources to this within the next few years. As such it will require a volunteer to work on this. No volunteer has offered to work on this recently.

I can't even understand which page it's about.

That would be T72245 and/or T58063 instead (please do not add "me too" comments - thanks).
This ticket is about "Implement HTML e-mail support in MediaWiki" only and not a forum.