Bilingual UX · June 2, 2026
Enterprise forms should treat Arabic as an operating mode
A bilingual form is not finished when every label has been translated. Arabic changes direction, scanning rhythm, validation tone, and the way users expect a workflow to acknowledge them.
In enterprise software, forms are often the front door to an operating process: service requests, approvals, incident reports, onboarding, and mandate intake. If that front door feels foreign in one language, trust drops before the backend gets a chance to prove itself.
The controls that matter
- Use `dir="rtl"` and `dir="ltr"` intentionally instead of forcing one layout to fit both languages.
- Localize validation messages, not only field labels.
- Keep labels visible and associated with inputs for accessibility and operational clarity.
- Use honeypot and rate-limit checks server-side so the public form does not become an intake liability.
- Return predictable success and error states that can be logged by the team operating the workflow.
What we released
bilingual-enterprise-form-kit is a small starter for Arabic and English enterprise forms, with validation examples and a Cloudflare Worker-style handler.
npm test # runs schema validation checks for English and Arabic examples
It is intentionally small. Teams can lift the validation shape, copy the worker handling pattern, and replace the fields with their own business workflow.