
Безперервна локалізація без TMS
Ваш код розгортається безперервно. Переклади мають оновлюватися так само. Дізнайтеся, як автоматизувати локалізацію у Вашому процесі розробки.
Що таке безперервна локалізація?
Безперервна локалізація — це підхід, за якого нові рядки автоматично перекладаються в межах процесу розробки, а не накопичуються для періодичних випусків перекладу. Коли розробник додає нову функцію з рядками інтерфейсу, ці рядки перекладаються до її випуску.
Традиційний підхід
Більшість команд накопичує рядки для пакетного перекладу: збирає нові рядки, експортує їх до TMS, очікує на перекладачів, імпортує результати й лише тоді випускає оновлення. Це створює вузьке місце в локалізації, через яке міжнародні випуски затримуються на кілька днів або тижнів.
Розробник додає нові рядки до файлу вихідної локалі
Рядки експортують і завантажують на платформу TMS
Перекладачі отримують сповіщення й починають роботу
Переклади перевіряють і затверджують
Перекладені файли завантажують і знову об’єднують із проєктом
Функцію випускають із перекладами (через кілька днів або тижнів)
Підхід із перекладом безпосередньо в IDE
Завдяки перекладу безпосередньо в IDE розробник перекладає рядки в межах звичного процесу написання коду. Жодного експорту, завантаження чи очікування: переклад виконується в тому самому сеансі, що й розробка.
Розробник додає нові рядки до файлу вихідної локалі
Розробник просить свого ШІ-асистента перекласти файл
Перекладені файли записуються безпосередньо до проєкту
Функцію випускають із перекладами в тому самому commit
Традиційний підхід
6 steps
Multiple tools and platforms
Days to weeks per cycle
Підхід із перекладом безпосередньо в IDE
4 steps
Inside your editor
Same commit
Налаштувати конвеєр перекладу
Команди, яким потрібна автоматизація перекладу поза межами IDE, можуть додати етап CI/CD, що перекладатиме нові або змінені рядки під час кожного push до main. Це працює з GitHub Actions, GitLab CI та будь-якою іншою системою CI/CD.
Для невеликих команд почніть із перекладу безпосередньо в IDE. Додайте автоматизацію CI/CD, коли Ваша команда виросте з 3-4 розробників або коли потрібно гарантувати наявність перекладів під час кожного merge до 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 pushДодати перевірку якості перекладу до CI
Автоматизовані перевірки у Вашому конвеєрі CI виявляють відсутні переклади, пошкоджені заповнювачі й недійсні формати повідомлень ICU до того, як вони потраплять у виробниче середовище. Це прості сценарії, які порівнюють файл вихідної локалі з усіма цільовими локалями.
#!/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Перевіряти переклади в CI
Виявляти й усувати розбіжності в перекладах
Розбіжність у перекладах виникає, коли вихідні рядки змінюються, а переклади не оновлюються. В англійському тексті вже написано «Зберегти зміни», а в німецькому досі залишається старий текст. Для виявлення розбіжностей порівнюють часові позначки файлів вихідного тексту й перекладу або хеші їхнього вмісту.
#!/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"Вибрати підхід до перекладу
Не весь вміст потребує однакового підходу до перекладу. ШІ добре перекладає рядки й мітки інтерфейсу. Для маркетингових текстів корисне поєднання ШІ та перевірки людиною. Юридичні тексти й матеріали з питань дотримання вимог завжди мають перекладати професійні перекладачі.
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 | PremiumПроцес роботи з перекладами в Git
Перекладайте у своїй робочій гілці до об’єднання, а не після нього. Так кожне об’єднання з main міститиме повні переклади. Додайте перевірку перед об’єднанням, яка підтверджуватиме повноту перекладів для всіх підтримуваних локалей.
Великі файли локалей JSON часто спричиняють конфлікти об’єднання, коли кілька гілок змінюють їх одночасно. Сортуйте ключі за абеткою та записуйте кожен ключ в окремому рядку, щоб зменшити обсяг змін і полегшити розв’язання конфліктів.
# .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');
\""Поширені помилки
Ставлення до локалізації як до етапу після розробки
Відсутність перевірки перекладів на рівні CI
Надмірне ускладнення за допомогою TMS
Відсутність відстеження актуальності перекладів
Спробуйте i18n Agent зараз
Перетягніть сюди файл для перекладу
JSON, YAML, PO, XML, CSV, Markdown, Properties
або натисніть, щоб вибрати
Цільові мови