One Profile, Two Scripts

For a contact profile the stakes are unusually personal, because the data in question is somebody's name. A system that mangles a product description is annoying; a system that renders an employee's name as question marks, or reverses it, or silently drops the Arabic version, is telling that employee something about how the company sees them.

Here are the six places it actually breaks, in the order the data moves through a system.

1. Entry: two fields, not one field translated

A name is not translatable, and it is not reliably transliterable either. There is no single correct Latin spelling of an Arabic name — the same name is written several ways by people who hold it, and the spelling on someone's passport is the one that matters to them. A system that generates the Latin form automatically will be wrong for a meaningful share of your staff and will keep being wrong.

So both forms are input, entered by the person whose name it is. That is the whole design decision, and everything downstream is easier once it is made. The same applies to job titles, where an automatic translation produces something plausible and slightly wrong in a way that is worse than obviously wrong.

2. Storage: the field has to survive the round trip

Arabic text arriving as question marks, boxes or mojibake is a character-encoding failure somewhere in the chain — a form, a database column, an export, an email template. It is entirely solved technically and still happens constantly, because it only takes one link in the chain to be wrong and the failure appears far from its cause.

The test is a round trip: type an Arabic name into the form, save it, reload, export it, open the export, and print it on whatever the system generates. If it survives all five it is fine. Most bugs of this class show up at step four or five, in the artefact nobody checked.

3. Display: mirror the layout, do not just switch the text

Arabic runs right to left, and so should the interface around it: field order, alignment, icons that imply direction, and the side a label sits on. Swapping the words while leaving the layout left-aligned produces a page that is technically in Arabic and reads as a translation.

The common technical cause is physical CSS — properties that name left and right rather than start and end — which cannot mirror because the direction is baked in. It is worth knowing that this defect is widespread even in mature front-end toolkits, and that the fix is mechanical once you look for it.

4. Mixed content inside one line

Real professional details are mixed: an Arabic name with a Latin company name, a job title containing an English acronym, an Arabic sentence ending in a phone number or an email address. Each of those is a direction change inside a single line, and getting it wrong scrambles the order of characters visibly — most often a phone number that renders backwards, or a bracket that jumps to the wrong end.

This is a text-handling problem rather than a language one, and it needs the embedded run isolated so its own direction applies locally. Testing it requires deliberately awkward data: an Arabic name at an English-named company with a title containing an acronym and a phone number in the same field.

5. The saved contact, which is the actual output

Everything above is preparation for one moment: the recipient saves the contact and it lands in their phone. That is where a bilingual profile usually loses. Contact formats have separate given-name and family-name fields, one display name, and no notion of two scripts — so something has to decide which version goes into the name field.

The defensible answer is to match the recipient: someone who opened the Arabic profile saves the Arabic name, someone on the English one saves the Latin. The other version belongs in a field that survives rather than being discarded, so a colleague searching either way finds the person. Confirm this by actually saving a contact and looking at it in the phone's own address book, which is a five-minute test that vendors rarely run.

6. Search, sorting and the directory

Internally, a bilingual staff directory has to find one person by either spelling. That means both forms are indexed, and ideally that search tolerates the variation — an Arabic name has several plausible Latin spellings, and a colleague will type the one they remember.

Sorting is the quieter issue. Sorting Arabic names by the Latin transliteration produces an order that makes no sense to an Arabic reader, and sorting by Arabic makes no sense to the English one. There is no single right answer; there is a decision, and having made it deliberately is better than discovering the default.