joona.palaste wrote:

A detail screenshot of the rendered article text illustrating the problem.

Attached:

This can be fixed by surrounding the text with ‏ and ‎ (for example,
‏Rūḥollāh Mūsavī Khomeynī‎). I suppose this could be templated as
{{rtl|Rūḥollāh Mūsavī Khomeynī}}, if that template doesn't already exist.

See the previous bug 8996 about similar behaviour on special pages. I think a
serverside fix would be applicable to all instances of the direction override
problem.

• This bug has been marked as a duplicate of 8996 ***

rotemliss wrote:

Bug 8996 is about a completely different problem, talking about a different kind
of direction marks. It's not a duplicate.

ayg wrote:

It's impossible to get correct directionality information from plain Unicode
text. Consider:

The Hebrew letter "aleph" is א, ב is "bet".

Note that aleph is א, bet is ב, and the logical order (as I typed it and as it
was encoded) has the א before the ב. The comma and space fall between two RTL
characters, so they're treated as RTL embedded in LTR. But semantically, the
comma is part of the LTR phrase (delimiting two LTR phrases, which happen to end
or begin with RTL characters) and should be treated as LTR text.

But consider this, which is syntactically identical:

Exodus 1:2 reads, in the original Hebrew: "ראובן, שמעון, לוי, ויהודה".

Here the behavior is correct, because in this context, the commas delimit RTL
phrases (or words), not LTR phrases. But there's no possible way either
MediaWiki or the browser could know that. The Unicode directionality algorithm
tries to do the impossible, and consequently fails. The only way to avoid this
problem is to add semantic information on how you want the directionality to go,
using Unicode directionality marks:

The Hebrew letter "aleph" is א‎, ב is "bet".