The problem isn't translation, it's version drift

If you work in internal tools, HR tech, or compliance engineering at a company with offices in more than one EU country, Directive 2023/970 is about to land on your backlog. Member states have until June 2026 to transpose it, and companies are already updating pay policies, progression criteria, and the transparency reports the directive mandates for employers with 100+ employees.

The legal and HR side of this is covered well in this piece on translation requirements under the directive. I want to focus on something adjacent: the actual technical problem of keeping multiple language versions of a legally binding document in sync over time, without relying on someone manually re-reading five PDFs every time a clause changes.

This is a version control problem wearing a compliance costume.

Why this breaks normal translation workflows

Most teams handle multilingual content with one of two approaches:

  • Ad hoc: someone exports a Word doc, sends it to a translator or a vendor, gets it back, pastes it into a wiki.
  • CMS-based: content lives in a headless CMS with locale fields, and translations sync through a translation management system (TMS).

Both break down for legal/compliance docs because:

  1. Terminology must be identical across every instance, not just "close enough." A pay policy, an internal FAQ, and a transparency report might all reference "objective and gender-neutral criteria," and if one translator renders it differently in each document, you now have three legally inconsistent definitions of the same concept in the same language.
  2. Changes need audit trails. If a labour inspectorate asks why the Portuguese version of a progression clause differs from the German one, "we don't know, a vendor updated it at some point" is not an acceptable answer.
  3. There's no single source of truth document. The policy, the report, and internal comms are separate files that reference the same underlying definitions, but nothing enforces that programmatically.

A practical fix: treat terminology as a schema, not prose

The fix that scales is borrowed straight from software engineering: stop treating legal terms as free text and start treating them as controlled vocabulary with IDs.

Here's a minimal structure:

{ "term_id": "gpg-001", "en": "gender pay gap", "definition_en": "Difference in average pay between genders", "translations": { "pt": "disparidade salarial de género", "fr": "écart de rémunération entre les sexes", "de": "geschlechtsspezifisches Lohngefälle", "es": "brecha salarial de género" }, "legal_reference": "Directive (EU) 2023/970, Art. 3", "last_reviewed": "2025-01-15", "reviewed_by": "legal-team" }

Every document that references "gender pay gap" pulls from gpg-001, not from a translator's independent judgment each time. You build this once as a glossary database (a spreadsheet works for small orgs, a proper TMS glossary feature works better) and every subsequent document, policy update, or report references term IDs instead of re-translating from scratch.

Where this fits in a document pipeline

If your org already uses a TMS (Phrase, Lokalise, Smartling, etc.), most support glossary enforcement during translation jobs. The workflow looks like:

  1. Source document authored in the HQ language, with key terms tagged (either manually or via a simple regex pass against your glossary).
  2. Glossary check runs before the job goes to translators. Flag any defined term in the source that isn't in the glossary yet, force a legal review before translation starts.
  3. Translation job dispatched with glossary attached as a constraint, not a suggestion. Most TMS platforms will highlight glossary mismatches in the translator's editor.
  4. QA pass compares translated term usage against the glossary programmatically. A basic version of this is just a script: 
import re def check_glossary_consistency(translated_text, glossary, lang): issues = [] for term in glossary: expected = term["translations"].get(lang) if not expected: continue # crude check: does the expected term appear at all  # when the source term context is present  if term["en"].lower() in translated_text.lower(): issues.append(f"Source term '{term['en']}' leaked untranslated") return issues

This won't catch nuanced legal errors (you still need a second linguist for that, which is exactly the review layer the source article describes for high-risk documents), but it catches the dumb, expensive mistakes: untranslated terms, inconsistent capitalization, or a term translated three different ways across three documents.

  1. Legal sign-off recorded against the specific glossary version, not just the document version. This is the audit trail piece. If gpg-001 changes on 2025-06-01, you want to know which documents were generated against the old definition and need re-review.

Handling multi-jurisdiction deadlines

Since national transposition deadlines won't align perfectly across member states, you'll likely need to version documents by jurisdiction and date, not just by language. A simple convention:

/policies/pay-transparency/ es/2026-03-01_v2.docx fr/2026-01-15_v1.docx de/2026-06-01_v1.docx pt/2026-02-01_v3.docx

Pair this with a changelog that references the glossary version used, and you have something an auditor or legal team can actually trace.

The takeaway

Translation quality for compliance documents isn't really a linguistics problem, it's a data consistency problem. If you're building or maintaining the internal tooling for HR, legal, or compliance content at a multi-country company, the highest-leverage thing you can do before June 2026 is set up a controlled glossary with IDs, version history, and automated consistency checks, before the volume of required documents (policies, reports, FAQs, internal comms) makes manual tracking impossible.

The legal review still needs to happen, and for documents with direct litigation exposure you still want a qualified second linguist checking the final text, as outlined in the source article on translation requirements for Directive 2023/970. But the infrastructure around that review is squarely an engineering problem, and it's one most compliance teams haven't built yet.