https://bugs.documentfoundation.org/show_bug.cgi?id=164492

--- Comment #13 from Jonathan Clark <[email protected]> ---
(In reply to Eyal Rozenberg from comment #0)
> 1. Set the paragraph direction to LTR
> 2.  Type the text "abضcd" (i.e. type a, then b, then Arabic Dad ض, then c,
> then d)
> 3. Move back two characters, so that I am past the ض but before the c; the
> caret is now  to the left of the ض, and shows a direction indicator.
> 4. Switch the keyboard layout back and forth between an LTR layout and an
> RTL layout (e.g. English and Arabic)
> 
> Expected results:
> The caret direction indicator switches back and forth from pointing left to
> pointing right (or from pointing left to not appearing, with the caret being
> straight and symmetric).

Suppose I put the cursor in the middle of an Arabic word and toggle between
English and Arabic layouts. What directions should the caret point? Currently,
the caret reflects the direction of the word at that position. By the above,
though, I should expect the direction of the caret to change, since I've
demonstrated intent to insert English text inside of the Arabic word.

What if I'm in an English layout and use the arrow keys to advance through an
Arabic document? I could insert an English character at any time. Should the
direction follow the text, or the predicted most-likely direction of my input
device?

Should we worry about U+202E RIGHT-TO-LEFT OVERRIDE, etc.?

The current direction indicator may not say exactly what users would want it to
say, but it's predictable and very easy to explain. I see the vision, but it
seems like it would be difficult to design this ER in a way that doesn't cause
more head scratching.

(In reply to Mike Kaganski from comment #11)
> fine with that (and I don't know how e.g. Asian users do their input, and so
> I think that this needs some wider discussion outside of Western audience
> (which is unaffected), but including many maybe-affected communities).

I'm not sure how much it matters for this discussion, but the lowest common
denominator is using a US-layout keyboard with an IME framework that doesn't
announce/associate languages with input methods. On these platforms, we may
have no way of knowing a user is even able to type Han characters until it's
already happened, and even then we still have no reliable way of knowing which
language it's supposed to be.

We should treat requests that require us to know the input language with care.

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to