
Localizzazione continua senza TMS
Il codice viene distribuito continuamente. Lo stesso dovrebbe valere per le traduzioni. Ecco come automatizzare la localizzazione nel flusso di sviluppo.
Che cos'è la localizzazione continua?
La localizzazione continua consiste nel tradurre automaticamente le nuove stringhe nell'ambito del flusso di sviluppo, anziché raggruppare le traduzioni in rilasci periodici. Quando uno sviluppatore aggiunge una nuova funzionalità con stringhe dell'interfaccia, queste vengono tradotte prima del rilascio.
L'approccio tradizionale
La maggior parte dei team raggruppa le traduzioni: raccoglie le nuove stringhe, le esporta in un TMS, attende i traduttori, importa i risultati e infine esegue il rilascio. Si crea così un collo di bottiglia nella localizzazione, che ritarda i rilasci internazionali di giorni o settimane.
Lo sviluppatore aggiunge nuove stringhe al file della lingua di origine
Le stringhe vengono esportate e inviate a una piattaforma TMS
I traduttori ricevono una notifica e iniziano il lavoro
Le traduzioni vengono revisionate e approvate
I file tradotti vengono scaricati e reintegrati
La funzionalità viene rilasciata con le traduzioni, dopo giorni o settimane
L'approccio integrato nell'IDE
Con la traduzione integrata nell'IDE, lo sviluppatore traduce le stringhe durante il normale flusso di programmazione. Senza esportare, inviare file o attendere: le traduzioni vengono completate nella stessa sessione di sviluppo.
Lo sviluppatore aggiunge nuove stringhe al file della lingua di origine
Lo sviluppatore chiede al proprio assistente IA di tradurre il file
I file tradotti vengono scritti direttamente nel progetto
La funzionalità viene rilasciata con le traduzioni nello stesso commit
L'approccio tradizionale
6 steps
Multiple tools and platforms
Days to weeks per cycle
L'approccio integrato nell'IDE
4 steps
Inside your editor
Same commit
Configurare la pipeline di traduzione
Per i team che desiderano automatizzare la traduzione oltre l'IDE, aggiunga un passaggio CI/CD che traduca le stringhe nuove o modificate a ogni push su main. Funziona con GitHub Actions, GitLab CI o qualsiasi sistema CI/CD.
Per i piccoli team, inizi con la traduzione integrata nell'IDE. Aggiunga l'automazione CI/CD quando il team supera i 3-4 sviluppatori o quando è necessario garantire le traduzioni a ogni merge in main.
# .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 pushAggiungere il controllo qualità delle traduzioni alla CI
I controlli automatici nella pipeline CI rilevano traduzioni mancanti, segnaposto non validi e formati dei messaggi ICU errati prima che raggiungano la produzione. Si tratta di semplici script che confrontano il file della lingua di origine con tutte le lingue di destinazione.
#!/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
doneConvalidare le traduzioni nella CI
Rilevare e gestire il disallineamento delle traduzioni
Il disallineamento si verifica quando le stringhe di origine cambiano, ma le traduzioni non vengono aggiornate. Il testo inglese dice "Save changes", mentre quello tedesco contiene ancora il testo precedente. Il rilevamento confronta le date di modifica o gli hash del contenuto dei file di origine e di traduzione.
#!/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"Scegliere l'approccio di traduzione
Non tutti i contenuti richiedono lo stesso approccio di traduzione. Le stringhe e le etichette dell'interfaccia si prestano molto bene alla traduzione con l'IA. I testi di marketing traggono vantaggio dall'IA con revisione umana. I testi legali e di conformità devono essere sempre affidati a traduttori professionisti.
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 | PremiumFlusso Git per le traduzioni
Traduca nel branch della funzionalità prima del merge, non dopo. In questo modo, ogni merge in main include traduzioni complete. Aggiunga un controllo precedente al merge che verifichi la completezza delle traduzioni per tutte le lingue supportate.
I file JSON di lingua di grandi dimensioni causano frequenti conflitti di merge quando più branch li modificano contemporaneamente. Ordini le chiavi alfabeticamente e usi una chiave per riga, per ridurre al minimo le dimensioni del diff e semplificare la risoluzione dei conflitti.
# .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');
\""Problemi comuni
Trattare la localizzazione come un'attività successiva allo sviluppo
Nessuna convalida delle traduzioni a livello di CI
Complessità eccessiva con un TMS
Mancato monitoraggio dello stato di aggiornamento delle traduzioni
Provi subito i18n Agent
Trascinare qui il file di traduzione
JSON, YAML, PO, XML, CSV, Markdown, Properties
oppure fare clic per selezionarlo
Lingue di destinazione