
TMS के बिना निरंतर लोकलाइज़ेशन
आपका कोड लगातार डिप्लॉय होता है। आपके अनुवाद भी होने चाहिए। यहाँ जानें कि अपने डेवलपमेंट कार्य-प्रवाह में लोकलाइज़ेशन को कैसे ऑटोमेट करें।
निरंतर लोकलाइज़ेशन क्या है?
निरंतर लोकलाइज़ेशन में अनुवादों को समय-समय पर होने वाली रिलीज़ के लिए इकट्ठा करने के बजाय, नई स्ट्रिंग्स का अनुवाद आपके डेवलपमेंट कार्य-प्रवाह के हिस्से के रूप में अपने-आप किया जाता है। जब कोई डेवलपर UI स्ट्रिंग्स वाला नया फ़ीचर जोड़ता है, तो फ़ीचर जारी होने से पहले उन स्ट्रिंग्स का अनुवाद हो जाता है।
पारंपरिक तरीका
अधिकांश टीमें अनुवादों को बैच में संसाधित करती हैं: नई स्ट्रिंग्स इकट्ठा करती हैं, उन्हें TMS में एक्सपोर्ट करती हैं, अनुवादकों की प्रतीक्षा करती हैं, परिणाम इंपोर्ट करती हैं और फिर रिलीज़ करती हैं। इससे लोकलाइज़ेशन में रुकावट पैदा होती है, जो अंतरराष्ट्रीय रिलीज़ में कई दिनों या हफ़्तों की देरी करती है।
डेवलपर सोर्स लोकेल फ़ाइल में नई स्ट्रिंग्स जोड़ता है
स्ट्रिंग्स को एक्सपोर्ट करके TMS प्लेटफ़ॉर्म पर अपलोड किया जाता है
अनुवादकों को सूचना दी जाती है और वे काम शुरू करते हैं
अनुवादों की समीक्षा करके उन्हें स्वीकृत किया जाता है
अनुवादित फ़ाइलों को डाउनलोड करके वापस मर्ज किया जाता है
फ़ीचर अनुवादों के साथ जारी होता है (कई दिनों से लेकर कई हफ़्तों बाद)
IDE-नेटिव तरीका
IDE-नेटिव अनुवाद में डेवलपर अपने सामान्य कोडिंग कार्य-प्रवाह के हिस्से के रूप में स्ट्रिंग्स का अनुवाद करता है। न एक्सपोर्ट करना पड़ता है, न अपलोड और न प्रतीक्षा — अनुवाद डेवलपमेंट वाले उसी सेशन में हो जाते हैं।
डेवलपर सोर्स लोकेल फ़ाइल में नई स्ट्रिंग्स जोड़ता है
डेवलपर अपने AI असिस्टेंट से फ़ाइल का अनुवाद करने के लिए कहता है
अनुवादित फ़ाइलें सीधे प्रोजेक्ट में लिखी जाती हैं
फ़ीचर उसी कमिट में अनुवादों के साथ जारी होता है
पारंपरिक तरीका
6 steps
Multiple tools and platforms
Days to weeks per cycle
IDE-नेटिव तरीका
4 steps
Inside your editor
Same commit
अपनी अनुवाद पाइपलाइन सेट अप करें
जो टीमें IDE से आगे बढ़कर ऑटोमेटेड अनुवाद चाहती हैं, वे एक ऐसा CI/CD चरण जोड़ सकती हैं जो main पर हर पुश के दौरान नई या बदली हुई स्ट्रिंग्स का अनुवाद करे। यह GitHub Actions, GitLab CI या किसी भी CI/CD सिस्टम के साथ काम करता है।
छोटी टीमों के लिए IDE-नेटिव अनुवाद से शुरुआत करें। जब आपकी टीम में 3-4 से अधिक डेवलपर हो जाएँ या आपको main में हर मर्ज पर अनुवाद सुनिश्चित करने हों, तब CI/CD ऑटोमेशन जोड़ें।
# .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 pushCI में अनुवाद QA जोड़ें
आपकी 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
doneCI में अनुवादों की पुष्टि करें
अनुवाद में आए अंतर का पता लगाएँ और उसे सँभालें
जब सोर्स स्ट्रिंग्स बदल जाती हैं, लेकिन अनुवाद अपडेट नहीं होते, तो अनुवाद में अंतर आ जाता है। अंग्रेज़ी में "बदलाव सेव करें" लिखा होता है, लेकिन जर्मन में अब भी पुराना टेक्स्ट दिखाई देता है। अंतर की पहचान करने के लिए सोर्स और अनुवाद फ़ाइलों के टाइमस्टैम्प या कंटेंट हैश की तुलना की जाती है।
#!/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"अपना अनुवाद तरीका चुनें
हर तरह के कंटेंट के लिए एक ही अनुवाद तरीका उपयुक्त नहीं होता। UI स्ट्रिंग्स और लेबल्स का AI से बेहतरीन अनुवाद होता है। मार्केटिंग कॉपी के लिए AI के साथ मानवीय समीक्षा उपयोगी होती है। कानूनी और अनुपालन संबंधी टेक्स्ट के लिए हमेशा पेशेवर मानव अनुवादकों का उपयोग करना चाहिए।
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
या ब्राउज़ करने के लिए क्लिक करें
लक्षित भाषाएँ