The usual translation workflow for tech sites is still painfully manual:

  1. finish the English draft
  2. paste it into a third-party tool
  3. clean the output in a hurry
  4. hope the structure survived

That works just well enough to become habit, which is exactly why it deserves to be replaced. Draft translation is an editorial systems problem, not a clipboard ritual.

Why technical drafts are harder to translate than marketing pages

Technical content has all the things that translation pipelines like to break:

  • code blocks
  • product names
  • shell commands
  • mixed English and Arabic terminology
  • MDX components
  • frontmatter metadata

If the workflow is sloppy, translation becomes the fastest way to introduce structural bugs into a publishing system. That is why the best translation stack starts with preserving shape before it optimizes prose.

Preserve the document shape first

The system should protect these elements before any model ever sees the prose:

  • frontmatter keys
  • translationKey
  • tags and category slugs
  • code fences
  • MDX components such as Callout, ProsCons, and HFRepoCard

That means the translation step should operate on extracted prose blocks, not on the raw file as a single string.

Code snippet

ts 

    import { pipeline } from "@huggingface/transformers";

const translator = await pipeline(
  "translation",
  "Xenova/nllb-200-distilled-600M"
);

const result = await translator("Secure the workspace before you trust it.", {
  src_lang: "eng_Latn",
  tgt_lang: "arb_Arab",
});

That one snippet is not the whole system, but it captures the right direction: translation should be a pipeline stage, not a side conversation in a browser tab.

Where local-first translation wins

This pattern is especially strong when:

  • the content is unpublished
  • the site is bilingual by design
  • the editorial team needs structural consistency
  • the organization cares about privacy, source confidentiality, or embargoed drafts

It also improves velocity. Once translation becomes a deterministic script, the team stops rebuilding the same manual workflow for every new article.

What still needs human review

No serious editorial team should auto-publish technical translation without a human pass. The review stage still needs to correct:

  • terminology choices
  • tone and rhythm
  • product naming
  • region-specific phrasing
  • context where a literal translation would sound awkward

The goal is not to eliminate editors. The goal is to stop wasting editor time on mechanical reassembly.

The workflow I would deploy

For a serious bilingual publication, I would ship translation in this order:

  1. generate a clean source draft
  2. run structural parsing on frontmatter, MDX blocks, and code fences
  3. translate only the prose segments
  4. reassemble the document with the original structure intact
  5. send the localized draft to editorial review

This makes the translation pipeline boring in the best way. It becomes repeatable, auditable, and much harder to break by accident.

Final view

In 2026, bilingual publishing should not depend on copy-paste rituals and goodwill. It should depend on a controlled pipeline that respects unpublished content, preserves document structure, and lets editors focus on what machines still do poorly: judgment, nuance, and precision.

That is why local-first draft translation is not just a neat developer trick. It is an editorial quality upgrade.