[wp-trac] [WordPress Trac] #46229: Email Direction

WordPress Trac noreply at wordpress.org
Tue Aug 5 12:56:44 UTC 2025


#46229: Email Direction
------------------------------------------------+--------------------------
 Reporter:  rahimvaziri                         |       Owner:  (none)
     Type:  defect (bug)                        |      Status:  new
 Priority:  normal                              |   Milestone:  Future
                                                |  Release
Component:  Mail                                |     Version:
 Severity:  normal                              |  Resolution:
 Keywords:  has-screenshots dev-feedback close  |     Focuses:
------------------------------------------------+--------------------------
Changes (by SirLouen):

 * keywords:  has-screenshots dev-feedback needs-patch => has-screenshots
     dev-feedback close


Comment:

 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 [comment:2 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 [https://www.compart.com/en/unicode/U+200F| 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
 [https://www.php.net/manual/en/function.nl2br.php 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.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/46229#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list