An Arabic-English design system needs a reliable way to change components and copy, not just a library approved once. If one team changes a message or field size and others adopt it without review, the languages can diverge and the authoritative version becomes unclear. Practical governance answers who proposes, who checks meaning and behavior, who releases and who confirms adoption in products.
This does not require a committee for every word or spacing adjustment. It requires classification by impact and responsibilities that do not disappear between design, engineering and content. Start with the smallest process the team can actually follow. An elaborate process that nobody uses does not protect the system.
Separate source ownership from adoption ownership
The library owner is responsible for the shared source. A product team is responsible for adopting it in its screens. A fix can be published while an application continues using an older version. If the aim is to correct an existing experience, publishing the component is not necessarily completion.
Name a design owner for the rule and presentation, an engineering owner for behavior and implementation, an Arabic-English content reviewer and an adoption owner for each affected product. One person may fill several roles if they have the necessary capability and capacity, but no role should remain anonymous.
Code maintenance and continuing work also require an explicit agreement. Including Design Systems in a project is not an open-ended commitment to operate every future release.
Decide which changes need joint review
Distinguish limited changes that preserve behavior, changes affecting meaning or interaction and changes requiring consumer migration. Classification depends on the product, not the size of the drawing. A single word can imply an unsupported outcome, while a spacing adjustment may remain local.
Review the effects on both languages, content length, alternate states and mixed-direction text. For the web, W3C distinguishes content language from direction; translation approval therefore does not establish directional behavior. W3C text-direction guidance. Native-platform implementation details require their own verification.
Make the approval route proportionate. A limited correction can have a short record and designated reviewer. A behavior change needs the affected owners. The rule should be understandable enough that a delivery team can classify a request without negotiating the process from the beginning each time.
Worked hypothetical: a longer Arabic error message
Suppose “Could not save” is replaced with a more actionable message explaining that changes were not saved and asking the user to review highlighted fields before trying again. The Arabic and English versions should communicate the same reason and next action. This illustrates a proposed change process, not a completed engagement.
The product team submits the observed problem, its location, proposed copy in both languages and why the current message is inadequate. Engineering checks whether invalid input really caused the failure. If the outcome is an unknown connection failure, the suggested wording is rejected because it directs the person toward the wrong remedy. Content review checks terminology and clarity.
Design discovers that the Arabic text exceeds the component’s fixed height on a narrow screen. The proposed fix allows expansion, then examines consumers. If the component sits in a constrained dialog, the review checks the effect on actions and access to surrounding content. The change now affects a component, not merely a string.
Once approved, the release record links the design version, implementation version and executed checks. Suppose two products consume it. One confirms adoption; the other needs a legacy-layout adjustment. The latter remains an owned outstanding update. The organisation does not announce that both products are fixed merely because the library was published.
If a regression appears, the record should reveal which version changed, which products adopted it and who can approve a rollback or targeted correction. This is more useful than a release announcement with no consumer trail.
Keep the change record small but sufficient
A useful record contains:
- The evidenced problem and affected user or task.
- Arabic and English copy, including variable values.
- Affected components and products, with potential update consequences.
- Reviewer decisions and the rationale for any exception.
- Release references, test evidence and consumer adoption status.
- A rollback or corrective path if a defect appears after release.
Content Strategy and Production can support bilingual terminology and approved content within an agreed scope. User Interface Design specifies visible states. Software Quality Assurance can provide release checks within the defined coverage.
The record can live in a tool the team already uses. The important requirement is that people can find the decision and connect it to the current artifact. A privately approved message buried in a chat is difficult for a later team to distinguish from an abandoned proposal.
Allow exceptions without losing control
A product may need a pattern that is not useful elsewhere. Require a rationale, consumer, owner and review trigger rather than banning it or immediately adding it to the shared library. If the need recurs, reconsider whether it belongs in the common system. A temporary exception caused by a legacy constraint needs an exit condition, not simply “review later”.
Assess governance through operational evidence. Can teams find the approved version? Do consequential changes have known consumers? Are old exceptions still justified? Release volume and component count alone are not maturity measures; high numbers may indicate rework or unnecessary fragmentation.
Avoid reviewing Arabic only after English is irrevocably approved, leaving decisions in private messages or updating design without an implementation reference. Do not describe a component as universally accessible because it passed a previous check. Changed content and context can require targeted re-evaluation.
Frequently asked questions
Do we need a dedicated design-system manager?
That depends on usage and change volume. What matters is explicit responsibility, allocated capacity and cover when the owner is unavailable, not a particular job title.
Does every copy change require a release?
It needs a traceable record and a way to reach consumers. Release classification and numbering depend on the team’s agreement and the change’s effect rather than one universal rule.
Who resolves a difference between languages?
Product and content owners settle the intended meaning, with qualified review of expression in each language. Do not shorten Arabic to fit a fixed box if the required action becomes unclear.
When is a change request closed?
When its agreed conditions are met: the source is approved and checked, and adoption is established or remaining work is explicitly owned. Publishing a file may be only one stage.
Start with one shared component and a real pending change. Taking it through the full process reveals practical governance needs more effectively than writing a lengthy policy that delivery teams never test.
Source
- W3C: Structural markup and right-to-left text in HTML, reviewed 26 October 2026.
