Arabic Changes More Than Strings
Arabic content needs review in its real right-to-left interface, not only in a translation table.
Direction changes the interface
Arabic changes the direction people scan in, and that is the smallest part of it. Containers begin on the right, navigation order reverses, and inside an Arabic sentence the numbers, the product names and the account identifiers stay left to right. Those mixed runs are where a translated screen actually breaks, and no amount of right-aligning a text field will find them.
Right-align is not direction. It is text-align.
Icons need a decision each, not a global transform. A back arrow follows the interface direction. A telephone handset, a download glyph and your own logo do not, and neither does a chart whose horizontal axis means time. Mirror all of them together and the screen looks correct while communicating the wrong sequence.
Arabic also changes how much room a label needs. Letter forms and font metrics move both the height and the width of a line, so a fixed-height button that looked balanced in English can clip a mark or crowd a diacritic. Long regulatory sentences expose that in a morning. Short placeholder words of uniform length never will.
A translation can be correct in a table and wrong once the layout mirrors around it.
Same rows, same order, mirrored by the host app. Inside the Arabic sentence the product name, the invoice number, the percentage and the amounts all stay left to right, and the Arabic is set in an Arabic face rather than in whatever the operating system substitutes. Those are the three things a translated screen usually gets wrong, and none of them show up in a translation table.
The table hides the interface
ContentFlow holds each string against a key. home.card.title has an English value, "Your card renewal is due", and an Arabic one, "تجديد بطاقتك مستحق". The Localization workspace sets them side by side, which is also the view that hides the problem: nothing in that row says what sits above the string, how wide the container is, or what happens after the tap.
A translation table is a list of values. An interface is a set of relationships.
Rendered review finds what the table cannot. Whether a heading wraps over an icon. Whether punctuation lands on the wrong side of a number. Whether the validation message is beside the field it belongs to. Most of those originate in component code, so sending them back to the translator costs a round trip and leaves the defect exactly where it was.
Test content should be picked to break things: long names, account identifiers, negative amounts, dates, and one sentence with an English product term embedded in it. Then check the narrow width and the enlarged text size, and check the empty, loading and error states. Those get less localisation attention than the happy path, which is why an untranslated string survives longest in them.
The host owns rendering
ContentFlow delivers Arabic and English through the REST API and marks the Arabic locale with a right-to-left flag. It does not draw anything. The host chooses the font, applies the direction, places the components and decides what a locale change does to a request, and no amount of correct stored text repairs a component tree built on left and right.
The two screens above are the test, and this page has to pass it too. They are drawn here, from the same rows in the same order. The Arabic one loads an Arabic face rather than falling through to whatever the operating system offers, and it keeps 12%, the invoice number and the credit as left-to-right runs inside a right-to-left sentence. Get either of those wrong and the screen still renders, which is the whole problem with reviewing Arabic anywhere except in the interface.
Apply direction at a container that means something, then override it only where the content has a justified directional requirement. Setting it per label produces nesting nobody can predict. Use logical properties, start and end rather than left and right, wherever the framework has them. Existing components usually need refactoring before any of this behaves, and that work is application engineering, not a translation task.
Fallback deserves a written rule, and it belongs next to the block definition rather than in a component somebody will refactor. Silently showing English when the Arabic is missing is fine on a marketing card and not fine on a consent notice, and that difference is a product decision rather than a null check.
Two approvals, not one
ContentFlow will not publish an unapproved translation. A string stays in review until a human approves it, and until then the application receives the English source rather than an unreviewed Arabic draft. That is the right default. It also means a stalled review reaches production as an English string on an Arabic screen, which is a visible failure, and visible failures are the ones to prefer.
Two people have to sign, because they are looking for different things. A language specialist reads the Arabic for terminology, grammar and register. Someone testing the rendered build reads the screen for direction, spacing, wrapping and state. Merge those into one informal sign-off and each of them assumes the other checked the hard part.
Terminology is governed across screens or it is not governed. Financial and insurance terms carry operational meaning, so two synonyms read as two different concepts, and a glossary only helps if it records the prohibited uses next to the approved ones.
Keep the key stable when the wording changes. Analytics and application logic should never depend on a translated string.
The display value belongs to content. The behaviour belongs to the contract.