
Kontinuierliche Lokalisierung ohne TMS
Ihr Code wird kontinuierlich bereitgestellt. Für Ihre Übersetzungen sollte dasselbe gelten. So automatisieren Sie die Lokalisierung in Ihrem Entwicklungsablauf.
Was ist kontinuierliche Lokalisierung?
Kontinuierliche Lokalisierung bedeutet, neue Zeichenfolgen automatisch als Teil des Entwicklungsablaufs zu übersetzen, statt Übersetzungen gebündelt in regelmäßigen Veröffentlichungen zu verarbeiten. Fügt jemand eine neue Funktion mit UI-Zeichenfolgen hinzu, werden diese vor der Veröffentlichung der Funktion übersetzt.
Der herkömmliche Ansatz
Die meisten Teams bündeln Übersetzungen: neue Zeichenfolgen sammeln, in ein TMS exportieren, auf die Übersetzung warten, Ergebnisse importieren und anschließend veröffentlichen. Dadurch entsteht ein Lokalisierungsengpass, der internationale Veröffentlichungen um Tage oder Wochen verzögert.
Neue Zeichenfolgen zur Datei der Ausgangs-Locale hinzufügen
Zeichenfolgen exportieren und auf eine TMS-Plattform hochladen
Übersetzerinnen und Übersetzer benachrichtigen und mit der Arbeit beginnen
Übersetzungen prüfen und freigeben
Übersetzte Dateien herunterladen und wieder zusammenführen
Funktion mit Übersetzungen veröffentlichen (Tage bis Wochen später)
Der IDE-native Ansatz
Bei IDE-nativer Übersetzung werden Zeichenfolgen im Rahmen des üblichen Programmierablaufs übersetzt. Kein Export, kein Hochladen, kein Warten – die Übersetzung erfolgt in derselben Sitzung wie die Entwicklung.
Neue Zeichenfolgen zur Datei der Ausgangs-Locale hinzufügen
KI-Assistenten mit der Übersetzung der Datei beauftragen
Übersetzte Dateien direkt in das Projekt schreiben
Funktion und Übersetzungen im selben Commit veröffentlichen
Der herkömmliche Ansatz
6 steps
Multiple tools and platforms
Days to weeks per cycle
Der IDE-native Ansatz
4 steps
Inside your editor
Same commit
Übersetzungspipeline einrichten
Teams, die Übersetzungen über die IDE hinaus automatisieren möchten, können einen CI/CD-Schritt hinzufügen, der bei jedem Push auf main neue oder geänderte Zeichenfolgen übersetzt. Dies funktioniert mit GitHub Actions, GitLab CI und jedem anderen CI/CD-System.
Beginnen Sie in kleinen Teams mit IDE-nativer Übersetzung. Ergänzen Sie CI/CD-Automatisierung, sobald Ihr Team mehr als drei bis vier Personen in der Entwicklung umfasst oder Übersetzungen bei jeder Zusammenführung in main garantiert sein müssen.
# .github/workflows/translate.yml
name: Translate
on:
push:
branches: [main]
paths: ['locales/en/**']
jobs:
translate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Translate changed strings
run: |
npx i18n-agent translate locales/en.json \
--to de,ja,es,fr,ko,zh-Hans \
--api-key ${{ secrets.I18N_AGENT_API_KEY }}
- name: Commit translations
run: |
git config user.name "github-actions"
git config user.email "[email protected]"
git add locales/
git diff --cached --quiet || git commit -m "chore: update translations"
git push# .gitlab-ci.yml
translate:
stage: deploy
only:
changes:
- locales/en/**
script:
- npx i18n-agent translate locales/en.json
--to de,ja,es,fr --api-key $I18N_AGENT_API_KEY
- git add locales/ && git commit -m "chore: translations" && git pushÜbersetzungsqualitätssicherung zu CI hinzufügen
Automatisierte Prüfungen in Ihrer CI-Pipeline erkennen fehlende Übersetzungen, beschädigte Platzhalter und ungültige ICU-Nachrichtenformate, bevor sie die Produktion erreichen. Einfache Skripte vergleichen dazu Ihre Datei der Ausgangs-Locale mit allen Ziel-Locales.
#!/bin/bash
# check-translations.sh — Run in CI to catch missing translations
SOURCE="locales/en.json"
LANGS=("de" "ja" "es" "fr")
EXIT_CODE=0
# Extract all keys from source
SOURCE_KEYS=$(jq -r '[paths(scalars)] | map(join(".")) | .[]' "$SOURCE" | sort)
SOURCE_COUNT=$(echo "$SOURCE_KEYS" | wc -l)
for lang in "${LANGS[@]}"; do
TARGET="locales/$lang.json"
if [ ! -f "$TARGET" ]; then
echo "❌ Missing: $TARGET"
EXIT_CODE=1
continue
fi
TARGET_KEYS=$(jq -r '[paths(scalars)] | map(join(".")) | .[]' "$TARGET" | sort)
MISSING=$(comm -23 <(echo "$SOURCE_KEYS") <(echo "$TARGET_KEYS"))
if [ -n "$MISSING" ]; then
COUNT=$(echo "$MISSING" | wc -l)
echo "❌ $lang: $COUNT missing keys"
echo "$MISSING" | head -5
EXIT_CODE=1
else
echo "✅ $lang: all $SOURCE_COUNT keys present"
fi
done
exit $EXIT_CODE#!/bin/bash
# check-placeholders.sh — Validate placeholder consistency
SOURCE="locales/en.json"
LANGS=("de" "ja" "es")
for lang in "${LANGS[@]}"; do
TARGET="locales/$lang.json"
# Compare placeholders like {{name}}, {count}, %s, %d
jq -r 'paths(scalars) as $p | [($p | join(".")), (getpath($p))]
| @tsv' "$SOURCE" | while IFS=$'\t' read -r key value; do
SOURCE_PH=$(echo "$value" | grep -oE '\{\{[^}]+\}\}|%[sd@]' | sort)
TARGET_VAL=$(jq -r "getpath($(echo $key | jq -R 'split(".")'))" "$TARGET")
TARGET_PH=$(echo "$TARGET_VAL" | grep -oE '\{\{[^}]+\}\}|%[sd@]' | sort)
if [ "$SOURCE_PH" != "$TARGET_PH" ]; then
echo "❌ $lang/$key: placeholder mismatch"
echo " Source: $SOURCE_PH"
echo " Target: $TARGET_PH"
fi
done
doneÜbersetzungen in CI validieren
Übersetzungsabweichungen erkennen und behandeln
Übersetzungsabweichungen entstehen, wenn sich Ausgangszeichenfolgen ändern, Übersetzungen jedoch nicht aktualisiert werden. Im Englischen steht „Save changes“, während die deutsche Übersetzung noch den alten Text enthält. Die Erkennung vergleicht Zeitstempel oder Inhalts-Hashes von Ausgangs- und Übersetzungsdateien.
#!/bin/bash
# detect-drift.sh — Find stale translations
SOURCE="locales/en.json"
SOURCE_HASH=$(md5sum "$SOURCE" | cut -d' ' -f1)
HASH_FILE=".translation-hashes"
# Compare current source hash with stored hash
if [ -f "$HASH_FILE" ]; then
STORED_HASH=$(grep "^en:" "$HASH_FILE" | cut -d: -f2)
if [ "$SOURCE_HASH" != "$STORED_HASH" ]; then
echo "⚠️ Source strings changed since last translation"
echo " Run translations to update all locales"
# Show which keys changed
git diff HEAD~1 "$SOURCE" | grep '^[+-]' | grep -v '^[+-][+-]'
fi
fi
# Update stored hash
echo "en:$SOURCE_HASH" > "$HASH_FILE"Übersetzungsansatz wählen
Nicht alle Inhalte benötigen denselben Übersetzungsansatz. UI-Zeichenfolgen und Bezeichnungen eignen sich hervorragend für KI-Übersetzung. Marketingtexte profitieren von KI und menschlicher Prüfung. Rechts- und Compliance-Texte sollten stets von professionellen Übersetzerinnen und Übersetzern bearbeitet werden.
Translation Approach Comparison:
Content Type | Approach | Cost/word | Quality
─────────────────────┼───────────────────┼────────────┼──────────
UI strings, labels | AI/LLM | $0.001-01 | Production
Tooltips, help text | AI/LLM | $0.001-01 | Production
Marketing copy | AI + human review | $0.05-0.15 | High
Legal / compliance | Human translator | $0.15-0.40 | Certified
Brand voice content | Human translator | $0.20-0.50 | PremiumGit-Arbeitsablauf für Übersetzungen
Übersetzen Sie vor der Zusammenführung auf Ihrem Feature-Branch, nicht danach. So enthält jede Zusammenführung in main vollständige Übersetzungen. Fügen Sie eine Prüfung vor der Zusammenführung hinzu, die die Vollständigkeit der Übersetzungen für alle unterstützten Locales bestätigt.
Große JSON-Locale-Dateien verursachen häufig Zusammenführungskonflikte, wenn mehrere Branches sie gleichzeitig ändern. Sortieren Sie Schlüssel alphabetisch und verwenden Sie einen Schlüssel pro Zeile, um Diffs klein zu halten und Konflikte leichter zu lösen.
# .gitattributes — reduce merge conflicts in locale files
locales/*.json merge=union
# Sort keys alphabetically to minimize diffs:
# package.json script:
"sort-locales": "node -e \"
const fs = require('fs');
const f = process.argv[1];
const d = JSON.parse(fs.readFileSync(f));
const s = (o) => Object.keys(o).sort().reduce((r,k) =>
({...r, [k]: typeof o[k]==='object' ? s(o[k]) : o[k]}), {});
fs.writeFileSync(f, JSON.stringify(s(d), null, 2)+'\\n');
\""Häufige Fallstricke
Lokalisierung erst nach der Entwicklung durchführen
Keine Übersetzungsvalidierung auf CI-Ebene
Überdimensionierte Lösung mit einem TMS
Aktualität von Übersetzungen nicht verfolgen
i18n Agent jetzt testen
Legen Sie Ihre Übersetzungsdatei hier ab
JSON, YAML, PO, XML, CSV, Markdown, Properties
oder zum Auswählen klicken
Zielsprachen