Back to the blog

Workflow

Bilingual Construction Documents Without Duplicate Work

A practical guide to one Arabic-English construction record, covering contractual language fields, RTL-native forms, revision control, and duplicate-log risks.

Bilingual document control does not require two registers. It requires one controlled record with one number, revision, and status, while presenting Arabic and English fields to the people who need them. Creating separate language copies of every MIR, SUB, COR, or NCR turns a manageable language requirement into two competing versions of project truth.

Start with the contract, not a general assumption

There is no universal list of fields that every project must issue in both languages. The document-control team must check the contract, owner specifications, document-control procedure, and approved project templates for correspondence language, the controlling language in a discrepancy, and any fields or attachments requiring translation. If the documents are silent, obtain a written decision from the authorised party before circulation begins.

Separate contractual requirements from operating practice

One contract may require bilingual document titles, descriptions, and consultant responses while permitting some technical attachments in one language; another may set different rules. Those documents govern. As an operating practice, teams often benefit from paired Arabic and English fields for title, subject, organisation, and response comment while leaving drawings or certificates in the required language. That practice improves retrieval and handover, but does not replace the contract.

A translated interface or an RTL-native form?

Translating the Submit button does not make a form Arabic-native. An RTL-native form starts with field order and reading flow, handles Arabic names beside Latin document numbers, and preserves symbol and attachment placement in PDF output. Test Arabic-name search, register sorting, and long-text wrapping as well: failures there send users to a side spreadsheet even when the interface labels look translated.

One canonical record for both audiences

A canonical record has one identifier, one revision, one action owner, and one status. Arabic and English are paired values on that record, not separate transactions. When the contractor updates an MIR description or the consultant adds a response comment, both language values stay within the same revision and the owner sees the same history, including who entered each value and when.

How review proceeds without a second copy

The record follows the project-defined contractor → consultant → owner route. Each user sees the appropriate language fields, but the A/B/C/D response, comment, and timestamp belong to the same transaction. When revised content needs translation, assign its owner and due date inside that review cycle; do not create a new document number merely because the second language is still being completed.

Where duplicate registers begin

  • An Arabic spreadsheet and an English spreadsheet, with status updated in one while the other becomes stale.
  • Two numbers for one transaction, making it appear as two open documents in the CPR or handover count.
  • A translation copied from an earlier revision while the current attachment contains a later technical change.
  • A consultant response in email in one language and an A/B/C/D code in the system in another, with no link proving they are the same response.
  • A closeout report that combines both registers and double-counts records, or drops one copy without a defined rule.

Controls to set before the project starts

Approve a language matrix identifying required fields and attachments by language, the controlling language, and translation and review ownership. Then test MIR, SUB, COR, and NCR from creation to closure, including export, search, and the audit trail. Review exceptions periodically; repeated manual copying is evidence that the procedure or form needs correction.

Handover starts with the first record

At handover, each document should export once with its number, revision, status, and language history as the project requires, rather than forcing the team to reconcile two registers in the final week. Start with the construction document management guide, read why Mutamad was built for Arabic, or book a working demo against your project register.