# Translation

## Definition

Translation considerations must be addressed early in the editorial process, as they impact both the editorial style and the organization of [repositories](https://docs.redaction-technique.org/en/tech-writing-process/repository/).

## Why it matters

There is no one-size-fits-all solution: delivering information in multiple languages requires ongoing oversight. However, addressing translation constraints early in the process and using an appropriate methodology can enhance quality and reduce costs and delivery times for multilingual versions. Translation should be integrated into the document workflow. Additionally, it is essential to ensure effective communication between technical writers, engineers, subject matter experts, designers, and translators.

If documentation is [modular](https://docs.redaction-technique.org/en/formats/modular-documentation/), translation can occur concurrently with writing, thereby reducing delivery times.

> **Diagram: Serial versus parallel writing and translation**
>
> Gantt chart comparing a serial process, where translation only starts after the source document is fully validated and delivered, with a parallel process, where translation of modular content starts as soon as it is written, reducing total time to market.

**Parallelization of Writing and Translation**

## Key principles

### Separate languages at the root

Regarding the organization of source file repositories, is it preferable to position the language directories before or after the document project directories? In other words, should the structure be as follows:

**Language first**

- english
  - product 1
  - product 2
- french
  - product 1
  - product 2

or like this:

**Product first**

- product 1
  - english
  - french
- product 2
  - english
  - french

In most situations, it is advisable to distinguish languages as early as possible. Using software development terminology, creating a translation of a content set is akin to [creating a branch](https://docs.redaction-technique.org/en/tech-writing-process/using-branches/) of that set. It is easier to manage a branch from its root than from its ramifications, making it more practical to handle complete directories, especially when providing them to translators, rather than using a set of subdirectories.

### Track updates: a translation is a fork

Once translation is completed, changes to either the source or translated version cannot be automatically mirrored. Continuing with software terminology, the new branch is a fork: modifications in one cannot be automatically reflected in the other. Therefore, to offer the same information in different languages, it is essential to effectively track updates to the original version.

## Continuous localization

Version control makes this tracking concrete. When sources are text files in Git, the commit history shows exactly which source files changed since the last translation, so translators receive only the changes instead of a full document set, and translation can follow each release rather than lag behind it.

| | Without version control | With Git |
|---|---|---|
| **Finding what changed** | Updates to the original version must be tracked | The commit history shows which source files changed |
| **What translators receive** | A full document set | Only the changes |
| **When translation happens** | Lags behind the release | Follows each release |
 A locale-first repository layout (see the [repository structure example](https://docs.redaction-technique.org/en/toolkit/example-repository-structure/)) keeps each language a complete tree that can be built and checked on its own.

Machine translation and AI-assisted translation can reduce the effort per update, but their output still needs review by someone who knows both the language and the product.

## Related articles

- [Content creation](https://docs.redaction-technique.org/en/tech-writing-process/content-creation/)
- [Git: from file to content](https://docs.redaction-technique.org/en/tech-writing-process/git-from-file-to-content/)
- [Formats and tools](https://docs.redaction-technique.org/en/costs/formats-and-tools/)
- [Case study: NuFirewall documentation](https://docs.redaction-technique.org/en/formats/nufirewall-case-study/): translating conref-based DITA XML content
- [Case studies in using DITA XML](https://docs.redaction-technique.org/en/formats/dita-xml-case-studies/)

## Related reading

- [An AI-based workflow to translate legacy content](https://redaction-technique.org/ai-translation-legacy-technical-docs) — automating translation of legacy technical docs while keeping a human in the loop.

---

Source: https://docs.redaction-technique.org/en/tech-writing-process/translation/