[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