Make WordPress Core

Opened 6 years ago

Last modified 4 days ago

#46229 new defect (bug)

Email Direction

Reported by: rahimvaziri's profile rahimvaziri Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Mail Keywords: has-screenshots dev-feedback close
Focuses: Cc:

Description (last modified by desrosj)

Hello WordPress,
Thank you so much for changing the world.

I am using the RTL layout of WordPress and all emails that I receive from WordPress, like changing password, reviewing a comment are in LTR direction.

Hope you fix this in the next update or let me know that how can I fix it.

Regards,
Rahim

Attachments (1)

rtl-emails-in-ltr.png (56.9 KB) - added by desrosj 6 years ago.

Download all attachments as: .zip

Change History (4)

#1 @desrosj
6 years ago

  • Description modified (diff)
  • Keywords has-screenshots dev-feedback added
  • Milestone changed from Awaiting Review to Future Release
  • Version 5.0.3 deleted

Hi @rahimvaziri,

Welcome to Trac! Thanks for opening this ticket.

I did some testing and confirmed that emails, by default, do not display using RTL when sent in an RTL language.

An easy solution for this would be to add dir="rtl" to the <html> tag. But, WordPress uses text/plain for all its emails by default, so this won't work unless a plugin filters emails to make them text/html. I did some searching, but I could not find an obvious solution.

#2 follow-up: @callumbw95
7 weeks ago

  • Keywords needs-patch added

Hi all,

I have taken a look into this, as I was thinking there must be a solution for the plain text emails similar to @desrosj's solution for the html emails. I did some digging and came across the following unicode symbol Left-to-Right Mark (U+200F) that instructs that the following string is to be viewed ltr instead of the default (rtl).

In regards to implementing this into our email body content before send, this might be something that we can request the maintainers of the PHPMailer's package to implement, or we can work around this with a patch to implement this unicode hidden character prior to sending it to the mailer.

#3 in reply to: ↑ 2 @SirLouen
4 days ago

  • Keywords close added; needs-patch removed

Directionality in plain text emails is completely unpredictable. The RFC 1556 was the one to treat this and its only an informative RFC meaning, that not all email clients are supporting this by default (not mandatory)

Replying to callumbw95:

I have taken a look into this, as I was thinking there must be a solution for the plain text emails similar to @desrosj's solution for the html emails. I did some digging and came across the following unicode symbol Left-to-Right Mark (U+200F) that instructs that the following string is to be viewed ltr instead of the default (rtl).

This won't make sure that RTL is shown properly. According to RFC 1556, the idea was support this natively when charset was set to any of the ISO-8859-* versions.

As @desrosj suggested some years ago, the only real and consistent solution for this is transitioning emails into their HTML counterparts (or at least generating a HTML multipart). Theoretically we could be transforming plain text emails with nl2br, from there adding dir="rtl" is pretty straightforward. To avoid issues with BC, a filter could be implemented to enable HTML/RTL emails, but if I'm sincere, this is a little botched job.

Following #51717 I truly think that this could only come with a major revamp of the email templating system (which may include all full support for multipart #15448).

I would tentatively add a maybelater to this or just leave it open with a view to further development in the other tickets mentioned, that should sort this transitively.

Note: See TracTickets for help on using tickets.