Page MenuHomePhabricator

Long article URLs in watchlist notification email body due to encoding for non-ASCII scripts
Open, LowPublic

Description

Hi,
We receive emails for every change of a article listed in watch list. Here the problem is the article URLs are written in Percent-encoding. So it is not possible to read that and it looks bad in the email body. Sometimes it requires 4/5 lines to show the name of the article.

Along with this there are some formatting issue which exists from the beginning and not resolved for a long time (https://bugzilla.wikimedia.org/show_bug.cgi?id=56063). The emails i receive form the 'MediaWiki message delivery' system are properly formatted. I am not sure which application is used to format this emails but the default Mediawiki emails have some issues. You can check the screenshot here to get an idea about the problem, https://nimbus.everhelper.me/client/notes/share/74770/w8BbZLSEFp9gVhZZ1GAdrcfL6aG7AvVf/ .

Nasir Khan


Version: 1.24rc
Severity: enhancement
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=63577

Details

Reference
bz70245

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 3:41 AM
bzimport added projects: MediaWiki-Email, I18n.
bzimport set Reference to bz70245.
bzimport added a subscriber: Unknown Object (MLST).
Nasirkhan created this task.Sep 1 2014, 8:47 AM

Does this refer to emails in plain text, or emails in HTML format?
For plain text, I don't see any way to solve that issue.
If you have one in mind, please elaborate.

Hi Andre Klapper,

thanks for your response and query.

I am facing this problem in the Mediawiki default email system. I am not sure if it is plain text or HTML. But if it is in plain text then is it required to be in 'plain text' and make everyone suffer for this?

I would still prefer to "make everyone suffer" to having broken links in email clients which don't interpret bytes correctly.
Now if that is a real issue or just a theoretical one, I don't know.

Hi Andre,
thanks for expressing your thoughts.

I believe you know that Echo (Notifications) sends email in HTML format, which is way more cleaner, user friendlier and easier to understand then the default emails. The important thing is it can send email in every language Wikipedia supports (including ASCII and non-ASCII scripts).

Can you please tell me why they ignored the email clients which don't interpret bytes correctly?

Echo: I checked the source of the last email message that I received from *Echo* on test2: Echo sends an email in both plain and HTML format ("Content-Type: multipart/alternative").

Watchlist notification emails that I receive only say:

Content-type: text/plain; charset=UTF-8

https://www.mediawiki.org/wiki/Special:Preferences#mw-prefsection-echo has a format setting but that seems to only apply to Echo notifications, not to Watchlist notifications. This is confusing.

I guess what it boils down to here is to also use Echo (and its HTML support) for Watchlist notifications.

Is there any update on this issue?

Changing the watchlist behavior is not on the Echo roadmap right now (see T22541: Watchlist, LiquidThreads and Echo notifications need to be unified).

However, this could still be fixed in core.

@Mattflaschen thanks for looking into the issue. Do you have any idea how this can be resolved?

scfc added a subscriber: scfc.Mar 26 2015, 10:58 PM

@Mattflaschen thanks for looking into the issue. Do you have any idea how this can be resolved?

There are a few things that could be looked into:

  • Using non-Latin characters without percent-encoding, but still using plain text (UTF-8?) emails (has anyone tried this recently?)
  • HTML email in core

Most of the time plain text emails can not create links for non-latin ULRs. I think HTML email would be the solution. Is there any pan to do so in future roadmap?

Dalba awarded a token.Dec 26 2015, 1:27 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptDec 26 2015, 1:27 PM
Dalba added a subscriber: Dalba.Dec 26 2015, 1:27 PM
demon set Security to None.
demon removed a subscriber: wikibugs-l-list.