Currently there are some inconsistencies in how RTL languages are handled by the new UI elements we are adding to the Filepage for Structured Data fields.
There are two related issues here:
1. How should the overall UI elements (Captions and Statements panels) look when oriented in RTL languages?
2. Within a given panel, how do we handle situations when both LTR and RTL languages are present?
**Problem #1: Overall panel layout**
Here is what we have currently, using Hebrew as an example.
[] Captions Panel, see T222867:
{F28678099}
[] Statements Panel, see T222283:
{F28678106}
In my mind, the Statements panel's behavior is closer to correct (it is lined up with the right hand side of the content area, while the Captions panel is not), but there are still some text collisions happening in the input box.
**Problem #2: What happens *within* a panel when differently-oriented languages are present?**
Regardless of the overall orientation of the page, both panel elements can contain items in both RTL and LTR languages, stacked on top of one another. Here are some examples, using the Captions panel:
Read mode:
{F28678183}
Edit mode:
{F28678197}
In particular, the editing state looks very wonky. This is because each row is attempting to follow the conventions of its own language, leaving to a broken-looking layout.
My suggestion would be that the UI elements inside panel (buttons, icons, dropdowns, etc) should be positioned according to the rules of the overall language of the page, and that content elements (text elements, inputs, etc. inside a given row) should follow the conventions of the specific language of the row. This would mean that the red "trash" icons would always line up on either the right-hand or left-hand side of the panel, depending on the overall language of the page, as one example.
However I defer to folks with more expertise/knowledge about what users in RTL languages will be expecting.