Hebrew - difficulty editing a right to left language

Could you please supply the following information:

• OS used

• Input method used

• Exact Java version, including minor revision ("1.8.0_101" etc.)

> Also moving from segment to segment takes considerably longer than for left-to-right langauges.

By "takes longer" do you mean that the UI hangs or becomes unresponsive?

Here is the requested info from our Hebrew linguist:
OS: Windows 10
Java version: Version 8 update 101 (build 1.8.0_101-b13)
Input from the keyboard: "It's a normal QWERTY layout, but obviously I switch to Hebrew configuration (a default Hebrew one)."

I was able to replicate the issue on my machine:
OS: Windows 10 Pro, version 1511, English
Java version:Version 8 update 91 (build 1.8.0_91-b15)
I was adding English words, from the keyboard, in the middle of Hebrew characters.

When moving from segment to segment the system doe snot get stuck, it just takes longer than expected. Or longer than in other CAT tools. On a single segment it does not matter. On 100 segments this slows things down. As we are trying to capture productivity, it does matter.

I'm afraid I can't reproduce any of the issues:

> trying to insert text will place it in the wrong place (sometimes in the middle of another word!)

Inserting Latin letters into Hebrew characters and vice versa seems to behave correctly according to the rules about how LTR and RTL scripts are supposed to interact. At the very least, Ocelot does not have any special processing in this area (except to set the editing component's orientation to LTR when appropriate for the locale) and its behaviors are consistent with default behavior for Java Swing components.

If the current behavior is not as desired, at the very least I will need specific details:

• What specific input results in incorrect display

• What specifically is the desired display

However there is a good chance that such issues cannot be feasibly fixed without custom-building new Swing text components.

> When moving from segment to segment the system doe snot get stuck, it just takes longer than expected.

I was unable to confirm any particular slowness when working with a file containing hundreds of Hebrew segments (vs a file with hundreds of English segments). Ocelot is not very speedy, but there doesn't seem to be a bug here per se.

> Or longer than in other CAT tools

If you want some work done optimizing UI responsiveness then that should be a separate ticket.