---
title: "Ohne maschinelle Übersetzung arbeiten"
description: "Schalte die Maschinenübersetzung in verbatra per Richtlinie ab: Kein String erreicht einen Übersetzungsdienst, und jede Übersetzung kommt von einem Menschen."
type: "how-to"
---
# Ohne maschinelle Übersetzung arbeiten

Schalte die Maschinenübersetzung in verbatra per Richtlinie ab: Kein String erreicht einen Übersetzungsdienst, und jede Übersetzung kommt von einem Menschen.

<AvailableFrom version="0.12.0" />

Das brauchst du, wenn eine Geheimhaltungsvereinbarung, ein Kundenvertrag oder eine Firmenregel verbietet, Strings an einen KI- oder Übersetzungsdienst zu schicken. Steht der Provider auf `none`, arbeitet jeder Befehl, der etwas ausgeben oder senden könnte, nur mit lokalen Daten oder verweigert den Dienst. Alles, was keinen Provider braucht (Diffing, die Lock-Datei, der Übersetzungsspeicher, Export und Import, Prüfungen, Typen, Pseudolokalisierung, Extraktion), funktioniert wie gewohnt.

Du brauchst ein verbatra-Projekt oder einen Ordner, in dem du gleich `verbatra init` ausführst.

## Einrichten [#einrichten]

```bash
verbatra init --provider none
```

Das schreibt eine Config, deren Provider-Block nur so aussieht, und keine `.env.example`, weil nie ein API-Key gelesen wird:

```ts title="verbatra.config.ts"
provider: { id: "none" }
```

In einem bestehenden Projekt ersetzt du den `provider`-Block durch `{ id: "none" }`. [`verbatra doctor`](https://verbatra.kreitz-webdev.de/de/docs/cli/doctor.md) meldet dann "machine translation disabled by policy" und besteht seine Provider- und API-Key-Prüfungen, ohne nach einem Key zu suchen.

## Was jeder Befehl macht [#was-jeder-befehl-macht]

| Befehl | Mit `provider: { id: "none" }` |
| --- | --- |
| `translate`, `watch` | füllen einen Key nur aus einem exakten Treffer im [Übersetzungsspeicher](https://verbatra.kreitz-webdev.de/de/docs/the-cache.md), nie aus einem unscharfen; jeder andere fehlende oder geänderte Key wird als `unfilled` gelistet, nicht angefasst und beim nächsten Lauf wieder angeboten. `translate` endet mit `3`, solange ein Key übrig ist |
| `export`, `import`, `tmx` | unverändert: Über die Übergabe und den Übersetzungsspeicher kommen menschliche Übersetzungen herein |
| `check`, `diff`, `doctor`, `pseudo`, `types`, `extract` | unverändert; keiner von ihnen ruft einen Provider auf |
| `studio`, `mcp` | lokales Lesen und Bearbeiten funktioniert; die kostenpflichtigen Provider-Aktionen werden nie angeboten, auch nicht mit `--allow-spend` |
| SDK [`retranslateEntry`](https://verbatra.kreitz-webdev.de/de/docs/sdk/review.md#retranslateentry) | scheitert mit [`MACHINE_TRANSLATION_DISABLED`](https://verbatra.kreitz-webdev.de/de/docs/error-codes.md#machine_translation_disabled), bevor es etwas liest oder sperrt |

Auf keinem dieser Wege wird ein Provider erzeugt, egal was in der Umgebung steht, und es gibt keine Netzwerkanfrage.

## Umstieg von einem Maschinen-Provider [#umstieg-von-einem-maschinen-provider]

Der Übersetzungsspeicher hält rein menschliche Arbeit in einem eigenen Bereich, getrennt von allem, was ein Maschinen-Provider erzeugt hat. Der Umstieg auf `none` beginnt also mit einem leeren Speicher. Eine Änderung an `tone` oder am Glossar berührt diesen Bereich nie.

Willst du frühere Übersetzungen mitnehmen, übertrag sie ausdrücklich, und sei dir bewusst, dass du damit maschinelle Ausgaben in einen sonst rein menschlichen Speicher importierst. Exportiere vor dem Umstieg: Direkt danach schreibt `tmx export` den rein menschlichen Bereich, der noch leer ist.

```bash
# 1. Still on the old provider: export its memory
verbatra tmx export

# 2. Switch the config to provider: { id: "none" }

# 3. Import it into the human-only bucket
verbatra tmx import verbatra-memory.tmx
```

Dateiname und Flags stehen unter [`verbatra tmx`](https://verbatra.kreitz-webdev.de/de/docs/cli/tmx.md).

## Der tägliche Ablauf [#der-tägliche-ablauf]

```bash
# 1. After source strings change, see what needs a human
verbatra translate          # exits 3 and lists the unfilled keys

# 2. Hand them to your translators
verbatra export

# 3. Bring the filled workbook back
verbatra import verbatra-translations.xlsx

# 4. Gate CI on it
verbatra check
```

Schritt 1 ist optional, denn `verbatra diff` und `verbatra check` zeigen dieselben offenen Keys. Er lohnt sich trotzdem: Er füllt jeden Key, den der Übersetzungsspeicher schon abdeckt, sodass deine Übersetzerinnen nur wirklich Neues sehen. Für die Übergabe selbst siehe [Mit Excel oder CSV übergeben](https://verbatra.kreitz-webdev.de/de/docs/manual-translation.md) oder [An eine Agentur übergeben](https://verbatra.kreitz-webdev.de/de/docs/translation-agency.md).

## In CI [#in-ci]

`translate` endet mit `3`, wenn Keys auf einen Menschen warten ([Exit-Codes](https://verbatra.kreitz-webdev.de/de/docs/cli/output.md#exit-codes)), sodass eine Pipeline den Build scheitern lassen, eine Übersetzungsanfrage anlegen oder nur berichten kann. Die [GitHub Action](https://verbatra.kreitz-webdev.de/de/docs/github-action.md#rein-menschlicher-modus) lässt den Schritt bei Exit `3` bestehen und setzt ihre Ausgabe `needs-human` auf `"true"`, damit ein späterer Schritt darauf reagieren kann.

## Siehe auch [#siehe-auch]

- [Exit-Codes](https://verbatra.kreitz-webdev.de/de/docs/cli/output.md#exit-codes): der vollständige Exit-Code-Vertrag.
- [Der Übersetzungs-Cache](https://verbatra.kreitz-webdev.de/de/docs/the-cache.md): der Speicher, aus dem `translate` füllt.
- [Provider](https://verbatra.kreitz-webdev.de/de/docs/providers.md): `none` neben den Übersetzungs-Providern.
- [Datenverarbeitung und Datenschutz](https://verbatra.kreitz-webdev.de/de/docs/data-handling.md): was mit jedem Provider die Maschine verlässt.