Could I confirm that this change is here to stay (I’m fully unfamiliar with the subtleties of RTL languages here, but this got flagged by @ZornHadNoChoice and feel it warrants another look).
PS: Would be awesome if someone could link me an ELI5 on the topic of mixed RTL content. I don’t know what I don’t know here.
I know I said it turned out badly, but I don’t have a preference here. I don’t need to mix English and Arabic, and if I wanted to, I know how to edit the HTML to make it work for me.
Both the old way and the new “auto” direction can result in unexpected and unwanted results. In the comparison below, the fields have the text entered in the correct sequence of characters.
The auto direction is better in being independent from the interface language.
The issue is that the direction is determined by the first character that appears which makes it fail for language cards that have a simple word on the front and sentences with punctuations on the back (in a language with the opposite direction).
Mixing RTL and LTR text on the same line in a text editor is a nightmare. It’s something that should just be avoided by users.
Having RTL and LTR on different lines is normal though. The only way I see it being possible in Anki is to wrap every field replacement with a `div` that specifies its direction. Of course, this would cause much bigger problems.
If you inspect any Github comment, you will see that it separates every paragraph into a separate element, and gives every element a separate dir="auto". This is because, unfortunately, automatic direction can not be achieved from CSS, and must be repeated for every single element. Anki can solve most of these complains if front and back are separate elements with two separate dir="auto", but this will change how some cards will render.
Yes, I’ve noticed this. I have just gone through my decks with Arabic or Hebrew and ensured that I stipulate the direction around any text in a Western (or rather non-Semitic language).
I had previously only stipulated RTL for the Semitic languages. Any notes, definitions, etc., in English or French, etc., were previously not placed within their own divisions, which stipulate LTR. Once I did that, it all looks OK.
Those changes I made will merely be redundant, if the previous behaviour is returned. However, the card itself should not take direction from a division contained within it. It sounds like there is an issue here.
I understand the complaints (bidirectional text can be confusing), but I think the new behavior is more correct - it makes more sense to infer direction from the card text rather than the UI language. Both behaviors can generate complaints, of course, admittedly the new behavior more so because it’s rare to switch UI language and RTL users are probably used to having issues with text direction.
Here’s a little demo I wrote years ago to demonstrate directionality classes:
Try “hello مرحبا 23”.
In short, text is separated into sequences where each sequence takes its direction from the first neighbouring “strong” character.
