Skip to main content

TMS के बिना निरंतर लोकलाइज़ेशन

आपका कोड लगातार डिप्लॉय होता है। आपके अनुवाद भी होने चाहिए। यहाँ जानें कि अपने डेवलपमेंट कार्य-प्रवाह में लोकलाइज़ेशन को कैसे ऑटोमेट करें।

निरंतर लोकलाइज़ेशन क्या है?

निरंतर लोकलाइज़ेशन में अनुवादों को समय-समय पर होने वाली रिलीज़ के लिए इकट्ठा करने के बजाय, नई स्ट्रिंग्स का अनुवाद आपके डेवलपमेंट कार्य-प्रवाह के हिस्से के रूप में अपने-आप किया जाता है। जब कोई डेवलपर UI स्ट्रिंग्स वाला नया फ़ीचर जोड़ता है, तो फ़ीचर जारी होने से पहले उन स्ट्रिंग्स का अनुवाद हो जाता है।

पारंपरिक तरीका

अधिकांश टीमें अनुवादों को बैच में संसाधित करती हैं: नई स्ट्रिंग्स इकट्ठा करती हैं, उन्हें TMS में एक्सपोर्ट करती हैं, अनुवादकों की प्रतीक्षा करती हैं, परिणाम इंपोर्ट करती हैं और फिर रिलीज़ करती हैं। इससे लोकलाइज़ेशन में रुकावट पैदा होती है, जो अंतरराष्ट्रीय रिलीज़ में कई दिनों या हफ़्तों की देरी करती है।

1

डेवलपर सोर्स लोकेल फ़ाइल में नई स्ट्रिंग्स जोड़ता है

2

स्ट्रिंग्स को एक्सपोर्ट करके TMS प्लेटफ़ॉर्म पर अपलोड किया जाता है

3

अनुवादकों को सूचना दी जाती है और वे काम शुरू करते हैं

4

अनुवादों की समीक्षा करके उन्हें स्वीकृत किया जाता है

5

अनुवादित फ़ाइलों को डाउनलोड करके वापस मर्ज किया जाता है

6

फ़ीचर अनुवादों के साथ जारी होता है (कई दिनों से लेकर कई हफ़्तों बाद)

Days to weeks

IDE-नेटिव तरीका

IDE-नेटिव अनुवाद में डेवलपर अपने सामान्य कोडिंग कार्य-प्रवाह के हिस्से के रूप में स्ट्रिंग्स का अनुवाद करता है। न एक्सपोर्ट करना पड़ता है, न अपलोड और न प्रतीक्षा — अनुवाद डेवलपमेंट वाले उसी सेशन में हो जाते हैं।

1

डेवलपर सोर्स लोकेल फ़ाइल में नई स्ट्रिंग्स जोड़ता है

2

डेवलपर अपने AI असिस्टेंट से फ़ाइल का अनुवाद करने के लिए कहता है

3

अनुवादित फ़ाइलें सीधे प्रोजेक्ट में लिखी जाती हैं

4

फ़ीचर उसी कमिट में अनुवादों के साथ जारी होता है

Same commit

पारंपरिक तरीका

6 steps

Multiple tools and platforms

Days to weeks per cycle

IDE-नेटिव तरीका

4 steps

Inside your editor

Same commit

3

अपनी अनुवाद पाइपलाइन सेट अप करें

जो टीमें IDE से आगे बढ़कर ऑटोमेटेड अनुवाद चाहती हैं, वे एक ऐसा CI/CD चरण जोड़ सकती हैं जो main पर हर पुश के दौरान नई या बदली हुई स्ट्रिंग्स का अनुवाद करे। यह GitHub Actions, GitLab CI या किसी भी CI/CD सिस्टम के साथ काम करता है।

छोटी टीमों के लिए IDE-नेटिव अनुवाद से शुरुआत करें। जब आपकी टीम में 3-4 से अधिक डेवलपर हो जाएँ या आपको main में हर मर्ज पर अनुवाद सुनिश्चित करने हों, तब CI/CD ऑटोमेशन जोड़ें।

अपनी मौजूदा CI/CD पाइपलाइन में अनुवाद को एक चरण के रूप में जोड़ें। बिल्ड सफल होने के बाद और डिप्लॉयमेंट से पहले अनुवाद चलता है, जिससे हर रिलीज़ में नवीनतम अनुवाद शामिल रहते हैं।
.github/workflows/translate.yml
# .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
# .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
4

CI में अनुवाद QA जोड़ें

आपकी CI पाइपलाइन में ऑटोमेटेड जाँचें अधूरे अनुवादों, खराब प्लेसहोल्डर्स और अमान्य ICU मैसेज फ़ॉर्मैट्स को प्रोडक्शन तक पहुँचने से पहले पकड़ लेती हैं। ये सरल स्क्रिप्ट्स आपकी सोर्स लोकेल फ़ाइल की तुलना सभी टार्गेट लोकेल्स से करती हैं।

CI स्तर पर अनुवाद सत्यापन न होने से अधूरे अनुवाद बिना किसी चेतावनी के प्रोडक्शन तक पहुँच जाते हैं। अनुवादित टेक्स्ट के बजाय यूज़र को "settings.title" जैसी मूल कुंजियाँ या खाली स्ट्रिंग्स दिखाई देती हैं। CI में 5 मिनट की जाँच इसे पूरी तरह रोक देती है।
check-translations.sh
#!/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
check-placeholders.sh
#!/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 में अनुवादों की पुष्टि करें

अधूरी कुंजियाँ, खराब प्लेसहोल्डर्स और बहुवचन संबंधी समस्याएँ अपने-आप पकड़ने के लिए अपनी CI पाइपलाइन में i18n-validate जोड़ें। विज़ुअल रिग्रेशन टेस्टिंग के लिए नकली अनुवाद जनरेट करने हेतु i18n-pseudo का उपयोग करें।
5

अनुवाद में आए अंतर का पता लगाएँ और उसे सँभालें

जब सोर्स स्ट्रिंग्स बदल जाती हैं, लेकिन अनुवाद अपडेट नहीं होते, तो अनुवाद में अंतर आ जाता है। अंग्रेज़ी में "बदलाव सेव करें" लिखा होता है, लेकिन जर्मन में अब भी पुराना टेक्स्ट दिखाई देता है। अंतर की पहचान करने के लिए सोर्स और अनुवाद फ़ाइलों के टाइमस्टैम्प या कंटेंट हैश की तुलना की जाती है।

पुराने अनुवाद, अधूरे अनुवादों से भी बदतर होते हैं। अधूरा अनुवाद साफ़ तौर पर गलत दिखता है — यूज़र को कोई कुंजी या फ़ॉलबैक भाषा दिखाई देती है। पुराना अनुवाद भरोसे के साथ गलत बात कहता है, जिससे यूज़र भ्रमित हो सकते हैं या सहायता संबंधी समस्याएँ पैदा हो सकती हैं।
detect-drift.sh
#!/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"
6

अपना अनुवाद तरीका चुनें

हर तरह के कंटेंट के लिए एक ही अनुवाद तरीका उपयुक्त नहीं होता। UI स्ट्रिंग्स और लेबल्स का AI से बेहतरीन अनुवाद होता है। मार्केटिंग कॉपी के लिए AI के साथ मानवीय समीक्षा उपयोगी होती है। कानूनी और अनुपालन संबंधी टेक्स्ट के लिए हमेशा पेशेवर मानव अनुवादकों का उपयोग करना चाहिए।

AI अनुवाद सामान्य ऐप स्ट्रिंग्स में से 80%+ को प्रोडक्शन स्तर की गुणवत्ता के साथ सँभाल सकता है। मानव अनुवादकों का उपयोग कानूनी टेक्स्ट, ब्रांड की शैली और सांस्कृतिक रूप से संवेदनशील कंटेंट के लिए करें, जहाँ बारीकियाँ सबसे अधिक मायने रखती हैं।
Cost Comparison
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
7

अनुवादों के लिए Git कार्य-प्रवाह

मर्ज करने के बाद नहीं, उससे पहले अपनी फ़ीचर ब्रांच पर अनुवाद करें। इससे main में होने वाले हर मर्ज में संपूर्ण अनुवाद शामिल रहते हैं। मर्ज से पहले एक ऐसी जाँच जोड़ें जो सभी समर्थित लोकेल्स के लिए अनुवादों की पूर्णता की पुष्टि करे।

जब कई ब्रांच एक साथ बड़ी JSON लोकेल फ़ाइलों में बदलाव करती हैं, तो अक्सर मर्ज कॉन्फ़्लिक्ट होते हैं। डिफ़ का आकार घटाने और कॉन्फ़्लिक्ट को हल करना आसान बनाने के लिए कुंजियों को वर्णानुक्रम में क्रमबद्ध करें और हर पंक्ति में केवल एक कुंजी रखें।

अनुवाद फ़ाइलें आपके कोड के साथ आपकी रिपॉज़िटरी में रहती हैं। उन पर वर्ज़न कंट्रोल लागू होता है, पुल रिक्वेस्ट्स में उनकी समीक्षा की जा सकती है और उन्हें बाकी सभी चीज़ों वाली पाइपलाइन से ही डिप्लॉय किया जाता है।
.gitattributes + package.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 स्तर पर अनुवाद सत्यापन न होना

ऑटोमेटेड जाँचों के बिना अधूरे अनुवाद, खराब प्लेसहोल्डर्स और अमान्य फ़ॉर्मैट्स प्रोडक्शन तक पहुँच जाते हैं। अपनी CI पाइपलाइन में पूर्णता और फ़ॉर्मैट सत्यापन जोड़ें।

TMS के साथ आवश्यकता से अधिक जटिलता

TMS को मानव अनुवादकों के कार्य-प्रवाहों को प्रबंधित करने के लिए बनाया गया था। यदि आप AI अनुवाद का उपयोग करते हैं, तो शायद आपको TMS से जुड़ी अतिरिक्त जटिलता की आवश्यकता न हो। सरल तरीके से शुरुआत करें — IDE या CI/CD में अनुवाद करें — और TMS केवल तभी जोड़ें, जब आपको मानव अनुवादकों का प्रबंधन करना हो।

अनुवादों की नवीनता ट्रैक न करना

नवीनता ट्रैक किए बिना आपको पता नहीं चलता कि कौन-से अनुवाद पुराने हो चुके हैं। सोर्स स्ट्रिंग्स बदल जाती हैं, लेकिन पुराने अनुवाद बने रहते हैं। पुराने कंटेंट को पकड़ने के लिए अपने कार्य-प्रवाह में अंतर की पहचान शामिल करें।

i18n Agent अभी आज़माएँ

अपनी अनुवाद फ़ाइल यहाँ छोड़ें

JSON, YAML, PO, XML, CSV, Markdown, Properties

या ब्राउज़ करने के लिए क्लिक करें

लक्षित भाषाएँ

साइन अप की ज़रूरत नहींतुरंत अनुमान

अक्सर पूछे जाने वाले प्रश्न