> > > "text first" vs. "link first", so, say that.
> > >
> > > As far as I understand it, RTL languages like Arabic typically write
-> > > text files "in logical order" (first letter is first in the bytestream)
-> > > and only apply RTL rendering on display, and IkiWiki will parse files
+> > > text files "in logical order" (i.e. reading/writing order - first
+> > > letter is first in the bytestream) and only apply RTL rendering on
+> > > display. IkiWiki is UTF-8-only, and Unicode specifies that all
+> > > Unicode text should be in logical order. The opposite of logical
+> > > order is is "display order", which is how you would have to mangle
+> > > the file for it to appear correctly on a naive terminal that expects
+> > > LTR; that can only work correctly for hard-wrapped text, I think.
+> > >
+> > > IkiWiki will parse files
> > > in logical order too; so if a link's text and destination are both
-> > > written in Arabic, in your proposed order (text before link), an
+> > > written in Arabic, in text-before-link order in the source code, an
> > > Arabic reader starting from the right would still see the text
-> > > before the link. So I don't think it would make sense to suggest that
+> > > before the link. Similarly, in your proposed link-before-text
+> > > order, an Arabic reader would still see the link before the text
+> > > (which in their case means further to the right). So I don't think
+> > > it would make sense to suggest that
> > > one order was more appropriate for RTL languages than the other: if
-> > > it's "right" (for whatever opinion of "right") in English, then it's
-> > > "right" in Arabic too.
+> > > it's "more correct" (for whatever opinion of "correct") in English, then
+> > > it's "more correct" in Arabic too.
> > >
> > > (If the destination is written in Latin then it gets
> > > more complicated, because the destination will be rendered LTR within an