I'm a recent addition to this list. I joined after the Apr 9 outage,
thinking that as a longtime Internet engineer I'd be able to help on
operational issues. Sadly, that doesn't seem to be a focus here.
Never-the-less, these parser functions have been requested for a long
time and been a source of considerable acrimony. I'm very happy they
have been implemented, and as the trial proceeds, it's possible that
improvements will be made.
However, the RTL issue doesn't seem to have anything to do with these
functions in particular. It may be an issue with parsing all templates.
We covered these issues in great detail in the IETF over a decade ago.
There was a lot of acrimonious argument then, too, but Hank (and others)
did a great job drafting a technical solution that solved the
transmission and editing problems.
(1) A canonical form for storage and transmission. In SMTP, all storage
and transmission is LTR. I don't see why that couldn't apply here, too.
Sure, it makes Hebrew appear backward in storage, but we usually don't
look at the stored version.
(2) Display and edit as RTL. In practice, this turned out to be fairly
simple by thinking about such things as opening and closing parentheses,
rather than left and right. They simply are reversed on display.
(3) This allows all email to be parsed consistently, without change to
the existing mail transmission programs, while specialized mail user
agents (MUA) handle display of the text body.
In this case, I don't see why the templates cannot be parsed in the
standard canonical order, but displayed RTL as an option. Then, there's
no need for line continuation escaping and such ugliness, that would
just interfere with RTL editing.
Just reverse the template syntax on display, along with everything else;
* without localization (BiDi):
{{else|then|test:if#}}
* assuming localization of the words:
{{esle|neht|tset:fi#}}
That would seem to correlate with my memory of the recommendations of
W3C, too, but I'm no expert there.