A translated source package is not the end of the publication job. Publication leads still need an accepted PDF or interactive electronic technical publication (IETP) in each contracted language. Engineering and PLM leads need a clear path from source change to released output. We scope that path around a real sample, an agreed revision and the environment in which the publication will be used.
The job ends at the receiving platform
We define the delivery boundary before conversion or translation begins. The scope identifies who prepares the source, who owns terminology and who accepts the result. It also separates language review from checks on structure and output behavior. Passing a structural check is not our proposed acceptance test for translation quality.
Translation belongs in the publication workflow rather than outside it. Sonovision describes translation alongside authoring, conversion and other integrated product support services. That is useful context for scoping the whole handoff, not evidence of a particular delivery rate. Sonovision service scope
Our proposed sequence is to agree the source-to-output mapping, publish a representative sample and demonstrate a revision. Production follows acceptance of that sequence. We record exceptions rather than allowing them to become undocumented publishing steps.
The contracted issue sets the starting point
Identify the applicable specification and program rules before choosing checks. For Army work, the ASSIST record describes MIL-STD-3031 Revision B Change Notice 1 as applying S1000D Issue 4.2 business rules to new acquisition technical publications, including page-oriented and IETP outputs. This is a specific program context, not a rule to apply to every multilingual publication. ASSIST MIL-STD-3031 record
For qualification, we ask for the publication requirement and the receiving authority's acceptance criteria. We distinguish contractual obligations from proposed project checks. Open decisions about the issue, language coverage or receiving platform belong in the scope before the sample is treated as a production baseline.
A useful sample includes a change
The source package should expose the difficult publishing cases rather than only clean prose. We propose selecting material with tables, illustration callouts and cross-references. Where the language set calls for it, the sample also includes text shaping and mixed-direction cases.
- Publication requirements, selected languages and expected outputs.
- Representative source content with its illustrations and referenced modules.
- A revision example with an identifiable source baseline.
- Terminology decisions and the people authorized to approve them.
- The receiving platform and access to its acceptance environment.
- Permitted working environments and content-handling restrictions.
We use these inputs to agree content readiness and review responsibilities. If technical review is outside our scope, the delivery plan identifies its owner and the point at which that review blocks release.
The package includes output and evidence
The proposed delivery package makes acceptance decisions traceable to the source baseline. It contains more than a folder of rendered files.
- A representative publication with recorded language and layout decisions.
- A production scope covering responsibilities, dependencies and exception handling.
- Delivered batches linked to their source and language baselines.
- Validation results and tracked review decisions for the agreed checks.
- An operations runbook describing the publishing process and release handoff.
- An agreed process for changes and support after handover.
The runbook records the settings used for the accepted output. It also identifies manual interventions so that the receiving team can distinguish a repeatable process from a sample that needed unrecorded repair.
Acceptance covers language and output behavior
We scope work in the customer's selected common source database, authoring tools and output environment. The acceptance matrix names the test environment and reviewer for each case. Proposed checks include:
- Structural validation against the agreed rules.
- References and applicability in the delivered publication.
- Font coverage and text shaping in each selected script.
- Mixed text direction in prose and tables where relevant.
- Search using agreed terms in the receiving IETP.
- Language review and layout inspection in each output.
After baseline review, we propose publishing the agreed revision through the same process. Acceptance then examines the changed text and its affected references. Search cases are repeated in the receiving viewer. An accepted baseline alone does not demonstrate that the next translated release will remain aligned.
The representative run defines production readiness
Content quality and publication variants affect the work to be scoped. So do language coverage, illustration changes and reviewer availability. We use the representative run to expose dependencies before agreeing the production queue and delivery cadence.
Dakota is listed among Oxygen XML consulting partners under training and consulting. That listing supports our stated partner role; it is not a claim that a particular multilingual publication or viewer has been accepted. Oxygen consulting partners Delivery acceptance rests on the agreed sample and its evidence.
Bring a real source sample, the required output and the person who accepts delivery to the scoping workshop.
Sources
- Integrated Product Support Services — Sonovision Group, publication date not stated
- MIL-STD-3031 Army Business Rules for S1000D — US Defense Logistics Agency / ASSIST, 2025-07-31
- Oxygen XML Partners — Syncro Soft / Oxygen, publication date not stated