Supporting two languages is usually treated as a content problem. Translate the strings, mirror the layout, ship it.
It is a systems problem.
A bilingual product has to hold its shape in two reading directions at once. The same component renders right-to-left on one page and left-to-right on the next. Specification tables, breadcrumbs, filters, sort controls, price formatting, icon direction - each one needs a rule that works in both, not two separate designs maintained in parallel.
One component, two directions. The rule has to hold in both.
The layout is the easy part
Mirroring is mechanical. What breaks is everything that carries direction implicitly.
Arrows that mean next. Progress indicators. Anything with a beginning and an end. A back button that points left is correct in English and wrong in Arabic, and no amount of CSS flipping tells you which icons carry meaning and which are decorative. That is a judgment made component by component.
Mixed content is harder still. A technical specification sheet holds Arabic labels, English model numbers, and numerals that read left-to-right inside a right-to-left line. There is no global setting for that. You decide, per field, which direction governs.
Two directions, one system
The output of that project was not two designs. It was a set of rules - how direction is inherited, which elements are direction-neutral, how mixed content resolves - that let the same catalogue behave correctly in both languages without anyone maintaining two versions.
That is what makes bilingual work a design systems problem rather than a translation task. The interface is not the deliverable. The rules are.