How should text align when English and Arabic appear together on one screen?

The short answer

When English and Arabic share a screen, align by who wrote the text. Text the product wrote (labels, buttons, headings) follows the direction of the interface. Text a user typed follows its own first letters. And inside one list, every row keeps the same alignment.

That is the whole answer, and it is a context answer, not a language answer. The only answer on the public UX question that asks this says so in its first lines: it depends on context.

01 · Text the product wrote

If an English interface shows an Arabic label as is, the surrounding screen stays left to right and the label sits inside it. The same holds in reverse for an Arabic-first interface that shows one English term. The screen has one direction. The odd word is a guest inside it. Flipping the whole row because one word changed script is the mistake that makes a screen look broken.

02 · Text the user typed

User-written content is different, because nobody designed it. A comment, a name or a note can start in either script. The answer I read gives two methods from real projects. One is to look at the first letter, which it describes as how Facebook behaved when the author worked on it, with the caveat that this may have changed. The other, from a project the author worked on, was to count the letters and treat the text as right to left when Arabic had more of them, otherwise left to right. Both are one person's account, not a standard.

Either way the decision is made per piece of content, and it is stored, not guessed on every render, so a message does not flip when someone edits one character.

03 · One list, one alignment

The same answer is blunt about lists: they must all share the same alignment. A column of customer names where some rows hug the left edge and others hug the right reads as a bug, even when every row is technically correct. Pick the alignment that follows the interface, and let the individual text direction affect only how the characters inside the row are shaped.

What goes wrong in practice

The usual failure is not a wrong rule, it is no rule. A team translates the labels, ships, and then discovers that names, addresses and free-text notes arrive in both scripts. Each screen then gets patched on its own, and the same record looks different in the list, the detail view and the receipt. Writing the three rules down once, and applying them in one shared component, is cheaper than patching each screen.

A short check you can run on your own screen

1. Put one Arabic name and one English name in the same list and look at the edges.
2. Type a sentence that begins in English and ends in Arabic, then the reverse, and see where the punctuation lands.
3. Press the back and forward controls and confirm they point the way the screen reads. My own essay on Arabic-first software lists this as a question to ask about forward and back controls, because it is a direction decision that gets missed when text is translated and the flow is not.

Why this belongs in the workflow, not the translation

The question was asked in 2019 and still gets asked, because translated labels do not settle direction. It is a design decision about the task, which is why I treat it as part of the workflow, not as a string file.

If you want a second pair of eyes on a mixed-language screen before it ships, the audit page is the place to start.