Building a Multilingual Documentation Pipeline for EU Machinery Regulation 2023/1230

Regulation (EU) 2023/1230 kicks in on 20 January 2027 and replaces the old Machinery Directive. If your company builds hardware that ships into the EU, this isn't just a legal department problem. Someone has to engineer the actual pipeline that takes a source manual and produces N compliant, synchronized, versioned translations, including documentation for AI-based safety components that didn't exist as a category under the old rules.

The legal background is covered well in this breakdown of the regulation. This post is about the other half of the problem: how do you actually build and maintain a system that keeps dozens of translated documents in sync with a source manual that keeps changing?

Why this is a content engineering problem, not just a translation problem

A single machine's documentation set usually includes:

• User manual
• Safety warnings and labels
• EC declaration of conformity
• Assembly / maintenance instructions
• AI system behavior documentation (new requirement)

Multiply that by every target market language, and you get a matrix where a single engineering change (say, a new emergency stop procedure) has to propagate correctly into every cell. Do this manually with email attachments and shared drives, and you will eventually ship a French manual with an outdated safety procedure. That's not a hypothetical, it's the default failure mode of unmanaged documentation.

The fix is to treat your manuals the way you treat code: version-controlled source content, a defined build pipeline, and automated checks before anything gets published.

Structure source content so it's translatable by design

Before any translation tooling, your source documentation needs to be structured, not a monolithic Word doc or PDF. Options that work well:

• DITA XML — purpose-built for technical documentation with reuse and conditional content
• Markdown + a static site generator (e.g., Docusaurus, which has built-in i18n support)
• Structured FrameMaker or Paligo if you're already in a DTP-heavy workflow

The goal is separating content from layout, and splitting documents into translatable segments that can be tracked individually. If a safety warning is a discrete, identifiable unit, you can diff it, flag it for retranslation, and verify it didn't silently change meaning across 8 language versions.

# Example: segment metadata for a safety warning block
id: safety-warning-estop-001
source_lang: en
criticality: high
last_updated: 2025-03-12
translations:
  es: { status: approved, translator: jsmith, reviewed: true }
  pt: { status: pending_review, translator: mcosta, reviewed: false }
  pl: { status: outdated, reason: source_changed }

This kind of metadata is what lets you build automated gates later.

Translation memory and terminology as infrastructure, not an afterthought

The source article points out that inconsistent terminology across translated machinery manuals ("residual risk" vs "remaining risk", "emergency stop" vs "panic button") is a recurring compliance risk. From an implementation standpoint, this is solved with two artifacts that should live in your repo alongside the content:

• A termbase (TBX format is the standard) with approved terms per language, locked for safety-critical vocabulary
• A translation memory (TM) in TMX format, shared across every translator and vendor touching the project

If you're using CAT tools (memoQ, Trados, or open-source options like OmegaT), both plug into these formats directly. The key engineering decision is: don't let terminology live in a vendor's proprietary silo. Export it, version it, and treat changes to the termbase as pull requests that need review, because a wrong approval here propagates into every future translation.

# Example: validating a translated segment against the termbase
python validate_terms.py \
  --source manual_en.xml \
  --target manual_es.xml \
  --termbase machinery_terms.tbx \
  --lang es

A simple script like this, run in CI, can flag when a translator used "protección genérica" instead of the approved "dispositivo de protección" for "safeguarding." It won't replace human QA, but it catches the cheap, high-frequency errors before they reach a reviewer.

Automating change detection and re-translation triggers

Under 2023/1230, any substantial modification to the machine requires updated documentation, in every translated version. This is a classic cache invalidation problem. You need:

1. A way to detect that source content changed (git diff on structured XML/Markdown is enough)
2. A way to map which translated segments are now stale
3. A workflow that routes stale segments to translators/reviewers automatically, instead of relying on someone remembering to notify the translation vendor

# Pseudocode: flag translations as outdated when source changes
for segment in source_segments:
    if segment.hash != last_known_hash[segment.id]:
        for lang, translation in segment.translations.items():
            translation.status = "outdated"
            notify_translation_queue(segment.id, lang)

This is the same pattern as invalidating a CDN cache after a deploy. The difference is the stakes: a stale safety instruction in Polish isn't a UX bug, it's a liability and compliance exposure.

CI checks before publishing a manual

Borrowing from software release practices, a documentation pipeline for regulated manuals should run automated checks before anything is marked ready for a notified body or market release:

• Completeness check: every required language has a translation for every segment
• Terminology check: approved terms used consistently (script above)
• Placeholder/variable check: if the manual has dynamic fields (model number, voltage rating), verify they weren't mistranslated or dropped
• Layout check: safety icons and warning placement preserved (this is why desktop publishing matters as much as the text itself)
• Sign-off check: high-criticality segments have a recorded second-linguist review, not just machine translation post-editing

A minimal CI config might look like:

# .github/workflows/docs-compliance.yml
name: docs-compliance
on: [pull_request]
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: python check_completeness.py --langs es,pt,pl,de,fr
      - run: python validate_terms.py --termbase machinery_terms.tbx
      - run: python check_critical_signoff.py --criticality high

Failing this pipeline should block publication the same way a failing test suite blocks a merge.

Where to draw the line between automation and human review

Machine translation plus post-editing is fine for descriptive content, parts catalogues, FAQs, general operating notes. It is not fine, on its own, for safety warnings, the declaration of conformity, or AI system behavior documentation, where a second human reviewer is the only thing standing between an ambiguous sentence and a market surveillance finding. Build your pipeline so criticality is a first-class metadata field, not something decided ad hoc per document.

The regulatory deadline is 2027, but the pipeline work, structuring content, building termbases, wiring up CI checks, takes longer to get right than most teams expect. Start building the infrastructure now, even if your first few manuals still go through a mostly manual process.