Translation Agency में glossary और proofreading flow को Claude Code से कैसे संभालें

शुक्रवार की शाम थी, और एक deliver हो चुके manual translation पर client की शिकायत आ गई: “Product name की spelling, पिछले issue से अलग है।”

Check किया तो सच में अलग थी। पिछली बार “ग्राहक अकाउंट” लिखा था, इस बार “यूज़र अकाउंट”। Glossary में साफ़ “ग्राहक अकाउंट” लिखा था, लेकिन deadline में दबे translator ने वहाँ ध्यान नहीं दिया, और proofreader भी चूक गया। मेरे तीन साल के translation agency के काम में सबसे ज़्यादा rework यही चीज़ लाती है।

यह किसी की गलती की बात नहीं है। Glossary Excel में 200 lines का है। हर project में थोड़ा-थोड़ा बढ़ता है। Translator deadline से लड़ता है, proofreader पूरा text आँखों से पढ़ता है। सिर्फ़ इंसानी ध्यान से हर spelling-mismatch रोक लेना अब practically मुमकिन नहीं रहा।

इसलिए मैंने Claude Code को “term-check का पहला filter” बना कर देखा। Final judgement इंसान के पास ही रहे, और जो mistakes मशीन से पकड़ी जा सकती हैं, उन्हें पहले ही निपटा दें। यह सोच से ज़्यादा असरदार निकला, तो एक translation agency coordinator की नज़र से पूरा तरीका यहाँ रख रहा हूँ।

मुख्य बातें

• Spelling-mismatch और term का unstandardized use ज़्यादातर “मशीन से पकड़ी जाने वाली mistakes” हैं, और Claude Code का पहला check इनका बड़ा हिस्सा पकड़ लेता है।
• Glossary को Excel में ही न रखें — CSV या plain text बना कर “rules की list” की तरह AI को दें, तो accuracy बढ़ती है।
• Drafting और proofreading flow में “AI जो पकड़े / इंसान जो तय करे” का बँटवारा करने से rework घटता है।
• Client के original text और glossary में proper nouns और unpublished जानकारी होती है, इसलिए कौन-सा data बाहर भेजना है, इसका control ज़रूरी है।
• एक project में proofreading की pre-processing में 30–60 मिनट, महीने में 10 projects चलाएँ तो कुछ घंटे से लेकर दस-बारह घंटे तक बच सकते हैं।

Translation agency के ground पर असल में क्या होता है

पहले reader image साफ़ कर लें। यह लेख उस coordinator के लिए है जो translation agency में projects चलाता है — खुद पूरा text translate करने के बजाय translator और proofreader के बीच खड़ा रहता है, glossary manage करता है, और deadline व quality के बीच पिसता है। Programming का अनुभव लगभग शून्य, या ज़्यादा-से-ज़्यादा थोड़ा macro छूने जितना।

Translation agency का common workflow कुछ इस तरह होता है:

1. Client से original text, पुराने translations और glossary मिलते हैं।
2. Translator को draft translation का काम दिया जाता है।
3. Proofreader (checker) translation की जाँच करता है।
4. Coordinator final check करके deliver करता है।

इस flow में rework कहाँ होता है? अनुभव से कहूँ, तो ज़्यादातर step 2 और 3 के बीच।

• Glossary वाला term translator ने इस्तेमाल नहीं किया (spelling-mismatch)।
• Numbers या units original से अलग हो गए (जैसे “3.5kg” बन गया “3.5g”)।
• Translation छूट गई (original का एक वाक्य translation में है ही नहीं)।
• Brackets या formatting project rule से अलग।

ये सब “पढ़ो तो दिख जाएँ” वाली mistakes हैं। लेकिन पूरा text आँखों से पढ़ते समय, project जितना लंबा हो उतना ही चूक होती है। Proofreader जो चूक जाता है वह coordinator तक पहुँचता है, और आख़िर में delivery के बाद की शिकायत बन जाता है। यही “मशीन से पकड़ी जाने वाली mistakes को इंसान खोजता रहता है” वाला समय translation agency की छुपी हुई cost है।

AI को क्या सौंपें और इंसान को क्या ज़रूर तय करना है

यह शुरू में ही साफ़ न करें तो accident होता है। Claude Code समझदार है, लेकिन translation की quality का final judgement उससे मत करवाइए। Line इस तरह खींचिए:

Step	Claude Code को सौंपें	इंसान (proofreader/coordinator) तय करे
Term check	Glossary और translation मिलाकर mismatch की list	वह mismatch गलती है या context का exception
Spelling-mismatch	Formatting, brackets, suffix की variation निकालना	Client की पसंद के मुताबिक final spelling
Numbers/units	Original और translation के numbers का difference पकड़ना	Unit conversion सही है या नहीं, meaning ठीक है या नहीं
Missing translation	Original के वाक्यों और translation के वाक्यों का अंतर बताना	Merge/split जानबूझकर है या नहीं
Translation quality	(मत सौंपें। बस draft की मदद तक)	Naturalness, tone, mistranslation का final judgement

मुख्य बात: AI से “सही answer तय” मत करवाइए। AI का काम बस “यहाँ शक है” वाला sticky note चिपकाना है। उसे हटाना है या रखना, यह इंसान तय करेगा। यह role-split टूटा तो AI का गलत judgement सीधे deliver होने का accident होता है।

सौंपने का दायरा कैसे लिखें, इसमें उलझें तो claude-code-prompt-engineering-advanced का prompt design काम आएगा। Instruction धुंधली रखी तो AI खुद ही “ठीक” करने लगता है, इसलिए output format तक बताना trick है।

Use case 1: Glossary से मिलान

सबसे ज़्यादा असरदार यही है। Glossary और translation दें, और सिर्फ़ mismatch table में लौटाएँ।

पहले glossary को Excel से CSV बना लें। AI को Excel सीधे देने के बजाय “original, translation, note” — तीन columns वाला text दें, तो वह rule की तरह आसानी से पढ़ता है। Pre-processing prompt ऐसा होगा:

आप एक translation agency के proofreading assistant हैं।
नीचे दिए glossary के अनुसार, सिर्फ़ translation के term-mismatch बताइए।

# Rules
- सिर्फ़ वहाँ report करें जहाँ glossary का "translation" इस्तेमाल नहीं हुआ
- context का paraphrase है या नहीं, यह judge मत कीजिए; mechanical mismatch सब बताइए
- ठीक मत कीजिए। सिर्फ़ point out कीजिए
- Output table format में: | line number | original | सही translation | असल translation |

# Glossary (original, translation, note)
customer account, ग्राहक अकाउंट, सभी projects में common
sign in, login, इस client के लिए login spelling
delete, हटाना, "मिटाना" मान्य नहीं

# Translation
(यहाँ translation paste करें)

जो लौटता है वह “fix suggestion” नहीं, बल्कि “mismatch की list” है। Proofreader उस table को ऊपर से नीचे देखता है और बस तय करता है कि ठीक करना है या नहीं। पूरा text दुबारा पढ़ने से यह कई गुना तेज़ है।

पहले proofreader Excel glossary एक अलग window में खोले रखता और translation से आँखों से मिलाता था। अब काम बदल कर “AI ने चिपकाए sticky note को verify करना” बन गया। एक ही “verify” है, लेकिन शून्य से खोजने और candidate देखकर तय करने में load का फर्क ज़मीन-आसमान का है।

Use case 2: Draft translation की pre-processing checklist

Translator को देने से पहले, या draft आते ही, एक बार machine check चला लें। Check items के लिए यही list वैसी-की-वैसी इस्तेमाल कीजिए:

• Glossary की translation हर जगह इस्तेमाल हुई या नहीं
• Original और translation में numbers/units मेल खाते हैं या नहीं
• Missing translation (original में है, translation में नहीं) तो नहीं
• Brackets और formatting project rule के मुताबिक है या नहीं
• Product name, person name, proper nouns की spelling पुराने translation से मिलती है या नहीं
• Forbidden expressions (client को नापसंद phrasing) तो मिल नहीं गए

यह check draft stage पर करें, तो proofreader तक पहुँचने से पहले mistakes घट जाती हैं। Proofreader “machine से पकड़ने वाला हिस्सा हो चुका है” मानकर naturalness और mistranslation जैसे सिर्फ़-इंसान वाले judgement पर focus कर पाता है।

Draft खुद AI से बनवाएँ तब भी, सीधे पूरा text मत सौंपिए — “पुराने translation और glossary को ध्यान में रखकर draft का पहला रूप” तक सीमित रखिए। Final translation इंसान करे। AI से अभी शुरुआत करने वाली team हो, तो पहले claude-code-for-non-engineers पढ़ लें — कितना सौंपना है इसका feel आ जाएगा।

Use case 3: Spelling-mismatch की periodic stock-taking

Project लंबा चले तो glossary खुद पुराना हो जाता है। “पहले हटाना था, अब इस quarter से मिटाना चलेगा” जैसा बदलाव मुँहज़बानी फैलता है और glossary में update नहीं होता, और ground पर confusion बनता है।

इसलिए महीने में एक बार पुराने deliverables इकट्ठे AI को पढ़वाएँ, और “एक ही concept के लिए कई translations लगे हैं” वाली जगहें निकलवाएँ। इससे glossary की maintenance की चूक पकड़ी जाती है। Project के common rules एक file में रखें, तो AI हर बार उसी को reference करता है — claude-md-best-practices वाले तरीके से हर project के rules एक file में रखें तो operation आसान हो जाता है।

Copy-paste वाला prompt template

Proofreading के पहले check में काम आने वाला generic template यहाँ रख रहा हूँ। बस project name और glossary बदलकर इस्तेमाल कीजिए।

# Role
Translation agency के पहले proofreading check के तौर पर, सिर्फ़ mechanically पकड़ी जा सकने वाली mistakes report करना।

# Input
- Glossary (original, translation)
- Original text
- Translation

# करना है (इसी क्रम में)
1. Term-mismatch निकालें
2. Numbers/units का original से difference निकालें
3. Missing translation (original के वाक्य > translation के वाक्य) का शक report करें
4. Brackets/formatting की variation निकालें

# नहीं करना है
- Translation rewrite मत करें
- Translation अच्छी है या बुरी, मत आँकें
- Exception judgement मत करें (judgement इंसान करेगा)

# Output format
## Term-mismatch
| जगह | सही translation | असल |
## Numbers/units
| original | translation | difference |
## Missing translation का शक
- (जगह)
## Spelling variation
- (जगह)
कोई समस्या न हो तो हर section में "कोई point नहीं" लिखें।

चलने वाला check script: numbers का mismatch मशीन से पकड़ें

AI को देने से पहले, जो “numbers का अंतर” पक्के तौर पर मशीन से पकड़ा जा सकता है उसे पहले निपटा दें, तो AI पर निर्भरता घटती है और safety बढ़ती है। Node.js में चलने वाला एक छोटा script बना रखा है। Original और translation text दें, तो जो number सिर्फ़ एक तरफ़ है उसकी list निकाल देता है।

import { readFile } from "node:fs/promises";

// original और translation file के paths command argument से लें
const [srcPath, tgtPath] = process.argv.slice(2);
if (!srcPath || !tgtPath) {
  console.error("उपयोग: node check-numbers.mjs original.txt translation.txt");
  process.exit(1);
}

const src = await readFile(srcPath, "utf8");
const tgt = await readFile(tgtPath, "utf8");

// numbers (decimal/comma समेत) सब उठा लें
const pick = (text) => (text.match(/\d[\d,.]*/g) || []).map((n) => n.replace(/,/g, ""));

const srcNums = pick(src);
const tgtNums = pick(tgt);

// जो number सिर्फ़ एक तरफ़ है उसे difference के तौर पर निकालें
const diff = (a, b) => a.filter((n) => !b.includes(n));

const onlyInSrc = diff(srcNums, tgtNums);
const onlyInTgt = diff(tgtNums, srcNums);

console.log("सिर्फ़ original में numbers:", onlyInSrc.length ? onlyInSrc.join(", ") : "कोई नहीं");
console.log("सिर्फ़ translation में numbers:", onlyInTgt.length ? onlyInTgt.join(", ") : "कोई नहीं");

if (onlyInSrc.length || onlyInTgt.length) {
  console.log("→ numbers का mismatch संभव है। उस जगह को check कीजिए।");
  process.exit(2);
}
console.log("→ numbers मेल खाते हैं।");

Save करके बस run कीजिए।

node check-numbers.mjs source.txt target.txt

यह perfect detection नहीं है। Word order बदले तो false positives भी आएँगे। लेकिन “3.5 translation से गायब है” जैसा fatal mismatch आँखों से तेज़ और पक्के तौर पर मिल जाता है। AI के judgement पर भरोसा करने से पहले ऐसे definite checks आगे रखना trick है। Claude Code पहली बार इस्तेमाल कर रहे हों, तो claude-code-getting-started-guide के steps से environment सेट करके फिर try कीजिए।

Security और personal information की सावधानी

Translation agency के लिए यह जीवन-मरण का मामला है। Original text में unpublished product जानकारी, contracts और person names होते हैं। संभालने में गलती हुई तो efficiency तो दूर, भरोसा ही चला जाता है।

• Client के साथ NDA में, बाहरी AI service को data भेजना allowed है या नहीं — हर बार ज़रूर check कीजिए।
• जहाँ permission नहीं, वहाँ proper nouns और numbers को dummy से बदलकर ही check चलाइए।
• Personal information (नाम, पता, contact) check से पहले mask कीजिए।
• भेजा हुआ data training में इस्तेमाल न हो — ऐसा setting या contract चुनिए।
• हर project के लिए “AI use ठीक/नहीं” एक management sheet में record कीजिए और coordinators के बीच share कीजिए।

उलझन हो तो “मत भेजिए” ही सही answer है। Glossary का मिलान proper nouns छुपाकर भी spelling-rule check की तरह पूरी तरह काम करता है। Data handling को लेकर भारत में Digital Personal Data Protection Act की आधिकारिक जानकारी से अपने practice को मिला कर check कर लें, तो ज़्यादा safe रहेंगे।

ROI का अंदाज़ा

मोटा-मोटी अंदाज़ा है, पर feel share कर रहा हूँ। Medium size के एक manual translation (original लगभग 10,000 अक्षर) की proofreading में, term-मिलान और number-check की pre-processing पर इंसान को अब तक 30–60 मिनट लगते थे।

पहला filter AI और check script को सौंप दें, तो वह pre-processing 10 मिनट के आसपास सिमट जाती है। यानी 20–50 मिनट की बचत। महीने में 10 projects चलाने वाली agency के लिए, महीने में कुछ घंटे से लेकर दस-बारह घंटे बचने का हिसाब है।

बची हुई समय में proofreader mistranslation और tone जैसे सिर्फ़-इंसान वाले judgement पर लग सकता है। यह सिर्फ़ time-saving नहीं — quality की आख़िरी line पर इंसानी हाथ लगा पाना ही बड़ी बात है। और tips के लिए claude-code-productivity-tips देख सकते हैं।

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

Q. AI से translation सीधे ठीक क्यों न करवाएँ? सलाह नहीं दूँगा। Fix तक सौंपें तो AI का गलत judgement सीधे translation में घुस जाता है और proofreading उल्टा बढ़ जाती है। AI सिर्फ़ “point out” करे, fix इंसान करे — यह बँटवारा बनाए रखिए।

Q. Glossary 500 lines से ऊपर है। पूरा दे सकते हैं? Project से जुड़े हिस्से तक सीमित करके देना practical है। पूरा देने पर accuracy गिरती है। Project की genre के हिसाब से glossary बाँट रखें, तो operation आसान रहता है।

Q. Machine translation engine से क्या फर्क है? Role अलग है। Machine translation translation generate करता है; यहाँ बताया गया तरीका generate हुई translation को जाँचने वाला पहला filter है। दोनों को मिलाएँ तो generation और checking — दोनों सिरे cover होते हैं।

Q. क्या proofreader का काम ख़त्म हो जाएगा? उल्टा। Machine से पकड़ने वाली mistakes खोजने से छुटकारा मिलता है, और mistranslation व nuance जैसे सिर्फ़-इंसान वाले judgement पर focus हो पाता है। यह ऊँचे-value वाले step पर समय लगाने की बात है।

Q. Company के तौर पर शुरू करना है, कहाँ से शुरू करें? एक project पर try करना safe है। पहले number-check वाला script लगाइए, आदत हो जाए तो term-मिलान तक बढ़ाइए। पूरी team का operation design चाहिए, तो training/consultation में concrete flow तक साथ बना सकते हैं।

असल में try करने पर क्या हुआ

अपने पास एक नकली project (product manual का एक हिस्सा, original लगभग 3000 अक्षर) पर असल में चलाया। जानबूझकर “ग्राहक अकाउंट” को 3 जगह “यूज़र अकाउंट” किया, और एक number “3.5” को “35” कर दिया।

Number वाले check script ने डाला हुआ “35” एक झटके में “सिर्फ़ translation में number” के तौर पर पकड़ लिया। Term-मिलान वाले prompt ने तीनों spelling-mismatch table में निकाल दिए। वहीं, context की वजह से जानबूझकर बदली एक जगह को भी “mismatch” बता दिया, तो वहाँ इंसान ने “यह exception है” तय करके रहने दिया।

मैं यही देखना चाहता था कि “AI sticky note चिपकाए, इंसान हटाना तय करे” वाला बँटवारा असल काम में चलता है या नहीं। नतीजा: मशीन ने जो candidate पकड़े उन्हें इंसान verify करे — बस इतना बदलने से शून्य से खोजने का mental load बहुत घट जाता है। Perfect automation नहीं, बल्कि इंसान का final judgement बचाते हुए pre-processing उठा लेना। Translation agency के ground के लिए यही दूरी ठीक बैठती है।