
Continuous Localization nang Walang TMS
Tuloy-tuloy ang pag-deploy ng inyong code. Dapat ganoon din ang inyong mga pagsasalin. Narito kung paano i-automate ang localization sa inyong development workflow.
Ano ang Continuous Localization?
Ang continuous localization ay ang praktis ng awtomatikong pagsasalin ng mga bagong string bilang bahagi ng inyong development workflow, sa halip na i-batch ang mga pagsasalin sa pana-panahong release. Kapag nagdagdag ang developer ng bagong feature na may mga UI string, naisasa-translate ang mga iyon bago ma-ship ang feature.
Ang Tradisyonal na Paraan
Karamihan sa mga team ay nagba-batch ng pagsasalin: kinokolekta ang mga bagong string, ine-export sa TMS, naghihintay ng mga translator, ini-import ang mga resulta, saka nagshi-ship. Lumilikha ito ng localization bottleneck na nagpapaliban sa mga international release nang ilang araw o linggo.
Nagdaragdag ang developer ng mga bagong string sa source locale file
Ini-export ang mga string at ina-upload sa isang TMS platform
Inaabisuhan ang mga translator at nagsisimula ang trabaho
Nire-review at inaaprubahan ang mga pagsasalin
Dina-download ang mga isinaling file at sini-merge pabalik
Nai-ship ang feature kasama ang mga pagsasalin (makalipas ang ilang araw hanggang linggo)
Ang IDE-Native na Paraan
Sa IDE-native translation, isinasalin ng developer ang mga string bilang bahagi ng normal nilang coding workflow. Walang export, walang upload, walang paghihintay — nangyayari ang pagsasalin sa parehong session ng development.
Nagdaragdag ang developer ng mga bagong string sa source locale file
Hinihiling ng developer sa kanilang AI assistant na isalin ang file
Direktang isinusulat sa project ang mga isinaling file
Nai-ship ang feature kasama ang mga pagsasalin sa parehong commit
Ang Tradisyonal na Paraan
6 steps
Multiple tools and platforms
Days to weeks per cycle
Ang IDE-Native na Paraan
4 steps
Inside your editor
Same commit
I-set up ang Inyong Translation Pipeline
Para sa mga team na gusto ng automated translation lampas sa IDE, magdagdag ng CI/CD step na nagsasalin ng mga bago o binagong string sa bawat push sa main. Gumagana ito sa GitHub Actions, GitLab CI, o anumang CI/CD system.
Magsimula sa IDE-native translation para sa maliliit na team. Magdagdag ng CI/CD automation kapag lumampas na sa 3-4 developer ang inyong team o kapag kailangan ninyong matiyak na may pagsasalin sa bawat merge sa 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 pushMagdagdag ng Translation QA sa CI
Nakakahuli ang mga awtomatikong check sa inyong CI pipeline ng nawawalang pagsasalin, sirang placeholder, at invalid na ICU message format bago pa umabot sa production. Mga simpleng script ito na naghahambing sa inyong source locale file laban sa lahat ng target locale.
#!/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
doneI-validate ang mga Pagsasalin sa CI
I-detect at I-handle ang Translation Drift
Nagaganap ang translation drift kapag nagbago ang mga source string pero hindi na-update ang mga pagsasalin. Sinasabi ng English na "Save changes" pero ang German ay luma pa rin. Inihahambing ng drift detection ang mga timestamp o content hash ng source at translation file.
#!/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"Piliin ang Inyong Paraan ng Pagsasalin
Hindi lahat ng content ay nangangailangan ng iisang paraan ng pagsasalin. Mahusay sa AI translation ang mga UI string at label. Mas nakikinabang sa AI + human review ang marketing copy. Dapat laging ipagawa sa mga propesyonal na human translator ang legal at compliance na teksto.
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 Workflow para sa mga Pagsasalin
Isalin sa inyong feature branch bago mag-merge, hindi pagkatapos. Tinitiyak nito na bawat merge sa main ay may kumpletong pagsasalin. Magdagdag ng pre-merge check na nagve-verify ng pagiging kumpleto ng pagsasalin para sa lahat ng sinusuportahang locale.
Nagiging sanhi ang malalaking JSON locale file ng madalas na merge conflict kapag sabay-sabay itong binabago ng maraming branch. I-sort ang mga key nang alpabetiko at gumamit ng isang key bawat linya para lumiit ang diff size at mas madaling ma-resolve ang mga conflict.
# .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');
\""Mga Karaniwang Pitfalls
Pagturing sa Localization bilang Post-Development
Walang CI-Level Translation Validation
Over-Engineering gamit ang TMS
Hindi Pagsubaybay sa Translation Freshness
Subukan ang i18n Agent Ngayon
I-drop dito ang inyong translation file
JSON, YAML, PO, XML, CSV, Markdown, Properties
o i-click para mag-browse
Mga target language