Bilingual products rarely break in the translation. They break in the details.

Most teams budget for copy translation and call the product bilingual. Then the first real user arrives and the cracks show: a date picker that assumes Gregorian flow, tables that collapse under RTL, labels that feel translated rather than native, and typography that looks technically correct but emotionally wrong.

What breaks is not language support in the abstract. What breaks is the product's underlying assumptions about layout, pacing, and how information should feel in context.

If Arabic or Persian is important to the business, those languages need to shape the component system, the spacing logic, the reporting format, and the text rhythm from the start.

That means calendars, numeral systems, truncation behavior, mixed-direction strings, PDF output, and visual hierarchy all need explicit thought before the product reaches production.

Prototype the hard surfaces first: data tables, exports, forms with long labels, and the reporting paths that executives actually read.

Do not wait until late-stage QA to discover that the bilingual experience only works on marketing pages and not inside the operational core.