Case study
The toolchain said no.
A partner needed 400 pages of desktop publishing across 7 languages. Five ran on the standard workflow, one ran on Arabic, and one — Punjabi — hit a toolchain that does not support it.
400 - 7 - 5 languages
400
Pages delivered
7
Languages
5 languages
Standard workflow
Measured outcomes
DTP, Punjabi encoding
Project overview
What landed, and what made it hard.
A partner needed 400 pages of desktop publishing across 7 languages. Five ran on the standard workflow, one ran on Arabic, and one — Punjabi — hit a toolchain that does not support it.
Delivery snapshot
DTP, Punjabi encoding
- Client
- confidential travel technology partner
- Service
- Multilingual desktop publishing
- Volume
- 400 pages
- Languages
- 7, including Arabic (SA) and Punjabi
- Key issue
- Punjabi PDF encoding not natively supported
Why this mattered
Outcome before process.
PDF accessibility tooling does not natively handle Punjabi's encoding. That is a tooling limitation rather than a language problem, and it does not resolve itself by trying harder or waiting for a patch.
The practical consequence is that the reading order — the sequence assistive technology uses to traverse a document — cannot be derived automatically for Punjabi pages.
MoniSa handled the work under ISO 9001:2015 for process control and ISO 27001:2022 for information handling. ISO 17100:2015 is scoped to translation, so it is not claimed for this work.
The delivery question was therefore not linguistic. It was whether one unsupported language would delay a 400-page multi-language delivery, and the answer was no.
The problem to solve
Why the work was difficult, and what MoniSa changed in-flight.
Desktop publishing is where multilingual projects fail after the translation is already correct. The text can be perfect and the document still be unusable.
The challenge
The problem to solve
Encoding support is the least visible version of that failure. It does not surface as a wrong word; it surfaces as a document that renders acceptably to a sighted reader and traverses incorrectly for anyone using assistive technology.
Punjabi specifically is not natively supported by the PDF accessibility toolchain, so the automatic reading-order derivation that works for the other six languages simply does not apply.
That leaves three options, and two of them are bad: drop the language, delay the whole delivery until tooling changes, or solve it manually. Only the third preserves both scope and schedule.
A 7-language batch also has a coupling problem. If one language blocks, a partner usually receives nothing rather than six-sevenths, because delivery is organized as a batch.
Arabic (SA) added right-to-left layout handling alongside everything else, which is well-supported but still a distinct workflow from the Latin-script languages in the same batch.
Operating response
What MoniSa changed
Five languages were delivered on the standard DTP workflow without modification, so the majority of the 400 pages was never at risk from the Punjabi issue.
- Isolate the blocked language Five languages ran the standard workflow untouched, so one unsupported language could not put the other 400-page batch at risk.
- Manual reading-order repair Punjabi reading order was fixed by hand, preserving the assistive-technology traversal the toolchain could not derive.
- RTL as its own workflow Arabic (SA) was handled with right-to-left layout handling rather than pushed through the Latin-script path.
- Decoupled delivery The batch was structured so a blocked language delayed itself, not the other six.
Results
Measured outcomes from this engagement.
400 pages were delivered across 7 languages, with the Punjabi encoding limitation solved rather than escalated.
| Pages delivered | 400 |
|---|---|
| Languages | 7 |
| Standard workflow | 5 languages |
| Manual intervention | Punjabi reading order |
| Schedule impact | None — delivered without delay |
Selection logic
What protected the result.
The selection came down to whether MoniSa could source and review the work at standard, and whether that would hold across the full run.
Why the fit was real
Why the fit was real
The work needed multilingual DTP capacity plus willingness to hand-solve an encoding limitation rather than escalate it back to the partner.
What decided the result
What decided the result
Manual reading-order repair preserved accessibility for the one language the toolchain could not handle, without delaying the other six.
What buyers can reuse
What buyers can reuse
- Ask which languages your DTP and accessibility toolchain natively supports. The unsupported ones are where a multilingual document delivery fails after translation is already correct.
- Reading order is an accessibility property, not a formatting preference. A document can look right and traverse wrongly for assistive technology.
- Structure multi-language batches so one blocked language delays itself, not the delivery. Coupled batches turn one limitation into a total slip.
- Right-to-left languages need their own workflow. Forcing them through a Latin-script path produces layout defects that survive review.
- Ask what a vendor does when tooling does not support a language: drop it, delay it, or solve it manually. The answer tells you what kind of partner they are.
- A useful DTP brief names the languages, the accessibility standard, the toolchain, and the fallback for unsupported encodings.
- Unglamorous manual work is often the deliverable. A partner unwilling to do it will hand the problem back to you.
Continue from this proof
Useful comparisons for the same problem.
Use these links to compare the case with the matching service, buyer guide, and language coverage.
Mapped context
Service and buyer context
Languages named
Examples referenced in the engagement.
- Punjabi
- Arabic (SA)
- PDF accessibility
- Reading order repair
More proof
Related proof
Compare this case with Enterprise localization terminology recovery and Document AI and OCR annotation to judge whether the operating pattern fits your brief.
case evidence
Nearest proof pattern.
These related cases keep the next click close to the same kind of work.
Multimedia servicesEqual scope across five languages, including healthcare QA in a language with ~1M speakers.
Healthcare, 5 languages
The challenge. A five-language brief mixed major European languages with ultra-rare Iu Mien and Fiji Hindi, plus healthcare domain content and voiceover.
What we did. MoniSa sourced domain-capable specialists for the rare pair and held the voiceover requirement across all five languages.
The result. 20 hours voiceover and 35,000 words per language, with no reduced scope for the rare half.
Recognise your own project in one of these?
Send the language list and volumeLocalization servicesMarket-entry material delivered in African French, with live interpretation in the same variety.
African French entry
Problem. A commercial vehicle manufacturer entering francophone North Africa needed African French, where metropolitan French would read as imported.
Action. MoniSa localized video and brochure to the variety with treatment matched to each content type, plus on-site interpretation.
Result. Video, brochure, and interpretation session delivered supporting the market entry.
Translation servicesHealth communications delivered in four under-served African languages with community validation inside a 24–72 hour turnaround.
Health comms, validated
Problem. A government and NGO health programme needed messaging the community would understand and trust, not merely accurate translation.
Action. MoniSa ran community validation as a step separate from linguistic review and carried terminology decisions across staggered batches.
Result. Acholi, Afar, Sindebele and Luo delivered on a public-health tempo without dropping the validation step.
Buyer questions
Answers in writing, before you ask for a call.
The questions buyers send before a scope conversation, answered on the page rather than in a meeting. Take them to your team, then send us the one we did not answer.
What was delivered on this engagement?
Pages delivered: 400. Languages: 7. Standard workflow: 5 languages
What control kept the work stable?
Manual reading-order repair preserved accessibility for the one language the toolchain could not handle, without delaying the other six.
Where should similar work go next?
Use Localization services for the delivery model, Localization QA buyer guide for buyer-side evaluation, and the contact page for a scoped brief.
What happens if you cannot staff one of my language pairs?
You are told before a date is agreed, not after. Coverage is reported pair by pair as staffed today or needing a recruitment window, with the window stated — in writing, while the scope is still being agreed. Nobody new goes onto live work until a pilot batch has been reviewed and signed off. A coverage claim you cannot check before signing is not coverage.
Similar brief
Send the constraint behind the metric.
A useful follow-up to a case study names the language mix, review model, deadline, and what proof your buyer team needs before approval.
Production-ready brief
01Closest matching challenge from this case02Language pair, dialect, and script coverage03Volume, cadence, or hours to deliver04Reviewer model and acceptance criteria05Security or platform constraints06Proof needed for stakeholder approval