# Order of words disturbed by using polyglossia with rtl language?

When having \setotherlanguage{hebrew} active, then even in an english environment it reverses the order of words in a \text{} and scrambles the labels for equations. Here is a minimal working example of this behaviour.

\documentclass{minimal}
\usepackage[T1]{fontenc}
\usepackage{amsmath}
\usepackage{polyglossia}
\setotherlanguage{hebrew}
\setdefaultlanguage{english}

\begin{document}
$$$\{ x\,|\,\text{yoda says hi\}$$$
\end{document}


which gives the output:

Is there a way to make the words and the label appear in the usual order?

It's what I think to be a bug in amstext-xetex-bidi.def (part of the bidi bundle) that does

\ProvidesFile{amstext-xetex-bidi.def}[2013/04/04 v0.1 bidi adaptations for amstext package for XeTeX engine]
\def\textdef@#1#2#3{\hbox{{%
\everymath{#1}%
\let\f@size#2\selectfont
\if@Latin\else\beginR\fi#3\if@Latin\else\endR\fi}}}
\endinput


but never sets \if@Latin to true.

I'm not sure where the issue should be dealt with, but a workaround is to add \@Latintrue when a left-to-right language is entered.

Example file:

\documentclass{article}
\usepackage{amsmath}
\usepackage{polyglossia}
\setotherlanguage{hebrew}
\setdefaultlanguage{english}

\begin{document}

$$\{ x\mid\text{one two three} \}$$

\end{document}


\documentclass{article}
\usepackage{amsmath}
\usepackage{polyglossia}
\setotherlanguage{hebrew}
\setdefaultlanguage{english}

\makeatletter
\appto{\blockextras@english}{\@ifundefined{if@Latin}{}{\@Latintrue}}
\appto{\inlineextras@english}{\@ifundefined{if@Latin}{}{\@Latintrue}}
\makeatother

\begin{document}

$$\{ x\mid\text{one two three} \}$$

\end{document}


I get the expected output:

Note that this also fixes the problem with equation numbers; another test:

\documentclass{article}
\usepackage{amsmath}
\usepackage{polyglossia}
\setotherlanguage{hebrew}
\setdefaultlanguage{english}

\makeatletter
\appto{\blockextras@english}{\@ifundefined{if@Latin}{}{\@Latintrue}}
\appto{\inlineextras@english}{\@ifundefined{if@Latin}{}{\@Latintrue}}
\makeatother

\begin{document}

$$\{ x\mid\text{one two three} \}$$
Also the numbers in \texttt{align} are printed right
\begin{align}
a&=b\\
0&<1
\end{align}

\end{document}


That looks like a bug in bidi (egreg thinks) but you can force things back with \beginL

\documentclass{article}
%\usepackage[T1]{fontenc}% don't use fontenc with xetex
\usepackage{amsmath}
\usepackage{polyglossia}
\setotherlanguage{hebrew}
\setdefaultlanguage{english}
\showoutput
\begin{document}
$\{ x\,|\,\text{\beginL one two three\endL}\}$
\end{document}

• thanks, I guess this can then be adressed for all cases by something like \let\oldtext\text \renewcommand{\text}[1]{\oldtext{\beginL #1 \endL}} – Moritz Firsching Nov 5 '15 at 13:24
• yes although might be worth pinging Arthur:-) – David Carlisle Nov 5 '15 at 13:26

This is not bidi package bug; it is polyglossia package bug. The bug was reported to the author of the polyglossia package four years ago with the solution but it has not been fixed to this day.

This question is indeed a duplicate question since it has been asked here before.

\if@Latin is only a conditional that bidi package provides so that packages like polyglossia set it to false for non-RTL languages and set it to true for RTL languages. xepersian makes extensive use of this conditional. Consider the following minimal example where xepersian package is used:

\documentclass{article}
\usepackage{amsmath}
\usepackage{xepersian}
\settextfont{Times New Roman}
\begin{document}
$$1+2=3\qquad\text{این یک فرمول است.}$$

\begin{latin}
$$1+2=3\qquad\text{This is an equation.}$$
\end{latin}
\end{document}


As you can see both equation numbers and the parantheses arund them is typeset correctly; the contents of the first \text is typeset RTL and the contents of the second \text is typeset LTR as one would expect.

Conclusion: This is polyglossia package bug; it has not been fixed for four years so do not hope that it will be fixed any time soon.

• Please avoid personal rants in answers. Also, if you think this post is a duplicate, then flag it for moderator attention and mention it as such, pointing to the duplicate, rather than providing a duplicate answer (plus rant). Once you've established enough reputation on this site, you can start casting your own vote-to-close - it's a privilege. – Werner Nov 11 '15 at 0:08
• @Werner: I edited my answer. – user91727 Nov 11 '15 at 0:11
• You're wrong: it's bidi that changes the definitions of commands, so it's this package that should take care this redefinition is working in the first place. – egreg Nov 11 '15 at 0:12
• @egreg: No, you are wrong because this redefinition works in the first place. – user91727 Nov 11 '15 at 0:14
• It's obvious it doesn't work in the OP's example. – egreg Nov 11 '15 at 0:41