sci-translation-skill کے ذریعے سائنسی و تکنیکی مقالوں کے چینی سے انگریزی ترجمے اور نظرِ ثانی کا قابلِ جائزہ ورک فلو

منصوبے کا تعارف

sci-translation-skill ایسے ہدایات کا مجموعہ ہے جسے coding agent میں لوڈ کیا جا سکتا ہے۔ یہ مقالوں کے ترجمے، اصطلاحی نظم و ضبط اور ترجمہ شدہ مسودے کی جانچ کے لیے ہے، اور کمپیوٹر سائنس، طب، انجینئرنگ، مواد اور دیگر سائنسی و تکنیکی شعبوں کے چینی سے انگریزی ترجمے کو ہدف بناتا ہے۔ یہ کوئی نیا ترجمہ ماڈل نہیں، بلکہ ورک فلو کے اصول، کرداروں کے معاہدے، اصطلاحی انتظام اور مقامی deterministic جانچ اسکرپٹس کو یکجا کرتا ہے۔

اس منصوبے کا مقصد محض ایسا انگریزی متن تیار کرنا نہیں جو زیادہ “SCI جیسا” لگے، بلکہ فطری اظہار برقرار رکھتے ہوئے اصطلاحی عدمِ استحکام، تکنیکی مفہوم کی تحریف، شرائط اور تحدیدات کے حذف، اعداد کے غلط تعلق اور فارمیٹنگ کے خراب ہونے کو کم کرنا ہے، تاکہ ترجمہ شدہ مسودہ ایسا submission ورژن بن سکے جسے مصنف ایک ایک نکتے کے ساتھ جانچ سکے۔

روانی درستگی کے برابر نہیں۔ سائنسی ترجمے میں اصل متن کے دعوے کی حد، شواہد کی قوت، علت و معلول کا تعلق، نفی، شرائط، مقداری الفاظ اور تکنیکی حدود کو ترجیحی طور پر محفوظ کیا جانا چاہیے۔

بنیادی ورک فلو

1. ساختی فہرست بنائیں: اصل متن محفوظ رکھیں، مقالے کی قسم، ابواب، ہدف قارئین اور تدوینی دائرہ درج کریں، اور ہر پیراگراف میں دعووں کی حدود واضح کریں۔
2. منصوبے کی اصطلاحات منجمد کریں: اہم تصورات کے لیے concept ID، معیاری ترجمہ، سیاق، ترجیحی لفظی شکل، ممنوع متبادل، شواہد اور زیرِ التوا سوالات درج کریں۔
3. وفادار ابتدائی ترجمہ: پہلے اصل مفہوم درست طور پر منتقل کریں، پھر قارئین کی رہنمائی کے لیے تدوین کریں، مثلاً عمل کے فاعل کو واضح کریں، بھاری جملوں کو تقسیم کریں اور پیراگراف کے اندر ربط بہتر بنائیں، لیکن استدلال میں اضافہ نہ کریں۔
4. دو طرفہ نظرِ ثانی: ماخذ متن، ابتدائی ترجمے اور تدوین شدہ مسودے کا بیک وقت تقابل کریں، اور جانچیں کہ تدوینی عمل نے کوئی نئی تکنیکی غلطی تو پیدا نہیں کی۔
5. issue ID کے مطابق ترمیم: ہر مسئلے، ترمیم اور وجہ کو الگ درج کریں، پھر حتمی اختلافات اور متاثرہ اصطلاحات کا دوبارہ جائزہ لیں۔
6. جائزے کا مواد فراہم کریں: ترجمہ، اصطلاحی فہرست، نظرِ ثانی کا ریکارڈ، مصنف کی تصدیق کے نکات فراہم کریں، اور حقیقی جانچ کے دائرے کی وضاحت کریں۔

نئے مقالے پر کام کرتے وقت README میں مشورہ دیا گیا ہے کہ پہلے طریقۂ کار یا نتائج کے حصے کے 2 سے 3 پیراگراف کا آزمائشی ترجمہ کیا جائے، پھر متن، شکلوں، جدولوں اور ضمیموں تک توسیع کی جائے، اور آخر میں خلاصہ حتمی شکل دی جائے۔ اس طرح دائرہ وسیع کرنے سے پہلے اصطلاحات اور ورک فلو کی توثیق ہو جاتی ہے۔

اہم صلاحیتیں اور اطلاق کی حدود

اصطلاحات اور تکنیکی وفاداری

یہ منصوبہ concept ID، منجمد ورژن اور سیاق کے ریکارڈ کے ذریعے منصوبے کی اصطلاحات کو مستحکم کرتا ہے۔ یہ ہر مقالے سے ایک ہی مقررہ اصطلاحی فہرست استعمال کرنے کا تقاضا نہیں کرتا، بلکہ ہر مقالے کے لیے الگ اصطلاحی معاہدہ تیار کرتا ہے۔ پیراگراف وار جائزے میں نفی، شرائط، مقداری الفاظ، شواہد کی قوت، اعداد، اکائیوں اور اشاریوں کے تعلق پر بھی توجہ دی جاتی ہے۔

قارئین کی رہنمائی پر مبنی تدوین

قارئین کی رہنمائی پر مبنی تدوین اب موجود معلومات کو باب کی ساخت کے مطابق منظم کرتی ہے، فاعل اور حوالوں کو واضح کرتی ہے، جملوں کا بوجھ کم کرتی ہے، اور زیادہ فطری بامعنی افعال اور لفظی ترتیب کے ذریعے بے معنی قالبی جملوں کو کم کرتی ہے۔ اسے ضروری hedging حذف نہیں کرنا چاہیے، اصل متن میں موجود نہ ہونے والا مفہوم شامل نہیں کرنا چاہیے، اور استدلال کو ایک پیراگراف سے دوسرے میں منتقل نہیں کرنا چاہیے۔

متعدد Agent اور دیانت دارانہ تنزّل

جہاں حقیقی tool support موجود ہو، وہاں اصطلاحی تحقیق، ترجمہ اور آزادانہ نظرِ ثانی مختلف task contexts کو سونپی جا سکتی ہے۔ یہاں “متعدد Agent” سے مراد متعدد آزاد task contexts ہیں؛ اس کا خودکار مطلب مختلف models یا انسانی ماہرین کا استعمال نہیں ہے۔ حقیقی tools نہ ہوں تو serial self-review اختیار کیا جائے اور اس کی واضح اطلاع دی جائے۔

run-manifest میں حقیقی کرداروں کے ID اور معلوم models درج کیے جاتے ہیں؛ ایسے team logs نہیں گھڑے جانے چاہییں جو موجود ہی نہ ہوں۔ پیچیدہ فارمیٹس اور طبی مسودوں کے لیے اب بھی انسانی یا rendered verification درکار ہے، جبکہ طبی مواد کا حتمی جائزہ ماہرین کو لینا چاہیے۔

شعبہ جاتی ترجیحات

• کمپیوٹر سائنس، سکیورٹی اور AI: threat model، access control، KEM اور payload decryption، ریاضیاتی علامات اور تکنیکی حدود پر خصوصی توجہ دیں۔
• طب اور حیاتیات: تحقیقی ڈیزائن، تعلق اور علت و معلول، effect size، interval، sample، dose، endpoint اور time point پر خصوصی توجہ دیں۔
• انجینئرنگ اور مواد: تجرباتی شرائط، اکائیوں اور dimensions، measured اور simulated نتائج، خطا اور اطلاق کی حدود پر خصوصی توجہ دیں۔

تنصیب اور رن ٹائم ماحول

SKILL.md پر مشتمل sci-translation-skill ڈائریکٹری کو host کے حقیقی طور پر supported skill directory میں رکھیں اور غیر ضروری nesting سے بچیں۔ آپ agent کو repository address بھی دے سکتے ہیں تاکہ host خود تنصیب سنبھال لے۔

مقامی Codex میں مثال کے طور پر مقام ~/.codex/skills/sci-translation-skill/SKILL.md ہے۔ اگر موجودہ ڈائریکٹری repository root ہو تو درج ذیل command سے تنصیب کی جا سکتی ہے۔ مطلوبہ مقام پر پہلے سے version موجود ہو تو backup لینے کی سفارش کی جاتی ہے۔

mkdir -p ~/.codex/skills/sci-translation-skill
rsync -a --exclude '.git/' --exclude '.DS_Store' --exclude '__pycache__/' ./ ~/.codex/skills/sci-translation-skill/

تنصیب مکمل ہونے کے بعد host میں skill کو refresh کریں یا نیا session کھولیں، اور تصدیق کریں کہ وہ SKILL.md پڑھ سکتا ہے۔ یہ فائل موجودہ host کی اپنی configuration documentation کا متبادل نہیں ہے۔

دوسرے hosts پر منتقلی کے وقت پہلے ان کے skill یا rules loading interface کی تصدیق کریں۔ Claude Code میں موجودہ version کے supported skill directory کے مطابق loading درکار ہے؛ Antigravity، Cursor، Windsurf اور Aider کے لیے rules interface کی تصدیق ضروری ہے؛ Dify، FastGPT، Coze یا خود تیار کردہ Harness میں role nodes، file transfer، dependency management اور run records خود نافذ کرنے ہوں گے۔ صرف knowledge base upload کرنا متعدد Agent کا pipeline قائم کرنے کے برابر نہیں ہے۔

Skill کے لیے Sonnet یا Opus کا مقررہ استعمال لازم نہیں، اور یہ host configuration کو ازخود تبدیل نہیں کرتا۔ جانچ اسکرپٹس کے لیے صرف Python 3 standard library درکار ہے۔

بنیادی استعمال

1. pilot mode میں آزمائشی ترجمہ

پہلی بار استعمال کرتے وقت agent سے پہلے اصطلاحی فہرست بنانے اور پھر مقررہ 2 سے 3 پیراگراف کا آزمائشی ترجمہ کرنے کو کہا جا سکتا ہے۔ Prompt میں شعبہ، ہدف journal اور input format واضح ہونا چاہیے، اور علت و معلول، نفی، تحدیدات اور عددی معلومات محفوظ رکھنے کا تقاضا کرنا چاہیے۔

$sci-translation-skill استعمال کرتے ہوئے pilot mode میں مقالے کا ترجمہ کریں۔
شعبہ: [discipline]؛ ہدف journal: [نام یا غیر متعین]؛ format: [LaTeX/Word/plain text]۔
پہلے متن، فارمولوں کی وضاحت، شکلوں، جدولوں اور ضمیموں سے اصطلاحی فہرست بنائیں، پھر میرے مقرر کردہ 2–3 پیراگراف کا آزمائشی ترجمہ کریں۔
پہلے وفادار ترجمہ کریں، پھر باب اور قارئین کے مطابق پیراگراف کے اندر معلومات منظم کریں؛ عمل کے فاعل اور حوالوں کو واضح کریں، جملے کی لمبائی زبردستی برابر نہ کریں۔
اصل متن کی علت و معلول، نفی، تحدیدات اور عددی معلومات محفوظ رکھیں؛ تجربات، حوالہ جات یا security guarantees شامل نہ کریں۔
آزاد Agent tools موجود ہوں تو تقسیم کر کے review کریں، ورنہ serial self-review کی وضاحت کریں۔
ترجمہ، منجمد اصطلاحات، location کے ساتھ ترمیمی وضاحتیں اور مصنف کی تصدیق کے نکات فراہم کریں۔

آزمائشی ترجمے کے نتیجے میں کم از کم ترجمہ، منجمد اصطلاحات، location کے ساتھ ترمیمی وضاحتیں اور مصنف کی تصدیق طلب امور شامل ہونے چاہییں۔ اصطلاحات اور طریقۂ کار کی تصدیق کے بعد مکمل متن پر کام بڑھائیں۔

2. موجودہ چینی-انگریزی متوازی مسودے کی نظرِ ثانی

اگر چینی اصل متن اور انگریزی ترجمہ پہلے سے موجود ہو تو review mode استعمال کیا جا سکتا ہے۔ نظرِ ثانی میں پہلے تکنیکی مفہوم، اصطلاحات، دعوے کی قوت، اعداد، اکائیوں اور حوالہ جات کی جانچ کریں، پھر زبان کی روانی دیکھیں۔

$sci-translation-skill کے review mode کا استعمال کرتے ہوئے چینی متن کے مقابل انگریزی کا پیراگراف وار جائزہ لیں۔
پہلے تکنیکی مفہوم، اصطلاحات، دعوے کی قوت، اعداد/اکائیوں اور حوالہ جات کو جانچیں، پھر زبان کی روانی دیکھیں۔
صرف شواہد پر مبنی مسائل درست کریں؛ “uses→adopts” جیسی ترجیح کو حقیقی غلطی سے الگ رکھیں۔
جملے تبدیل کرنے سے پہلے reading obstacles جانچیں؛ ابتدائی ترجمے اور تدوین شدہ مسودے کا تقابل کر کے شرائط کے دائرۂ اثر، علت و معلول، اشاریوں اور حوالہ جاتی تعلق کی دوبارہ جانچ کریں۔
ہر نکتے کے لیے اصل متن، موجودہ ترجمہ، ترمیم اور وجہ درج کریں، اور ترمیم کے بعد دوبارہ جانچ کریں۔

یہ mode حقیقی غلطیوں اور لفظی ترجیحات کو الگ رکھتا ہے۔ مثال کے طور پر صرف uses کو adopts میں تبدیل کرنا لازماً تکنیکی مسئلہ نہیں، اس لیے تمام اسلوبی اختلافات کو غلطی کے طور پر درج نہیں کرنا چاہیے۔

3. مکمل ترجمہ اور اصل متن کا تحفظ

مکمل mode اس وقت موزوں ہے جب اصطلاحات اور آزمائشی ترجمے کے نتائج کی تصدیق ہو چکی ہو۔ agent سے کہیں کہ نتیجہ نئی directory میں فراہم کرے اور اصل متن overwrite نہ کرے؛ تمام حصے ایک ہی version کی اصطلاحی فہرست اور تحقیقی context شیئر کریں، اور متن، figure captions، tables، formula explanations، algorithms اور appendices کو شامل کریں۔

$sci-translation-skill استعمال کرتے ہوئے منظور شدہ اصطلاحی فہرست کے مطابق مکمل متن کا ترجمہ کریں۔
نئی directory میں deliver کریں، اصل متن overwrite نہ کریں۔ تمام blocks ایک ہی version کی اصطلاحی فہرست اور تحقیقی context شیئر کریں۔
متن، figure captions، tables، formula explanations، algorithms اور appendices شامل کریں؛ آخر میں abstract کے دعوے کی حد دوبارہ جانچیں۔
انگریزی مسودہ، اصطلاحی فہرست، paragraph alignment، review closure record اور زیرِ تصدیق امور فراہم کریں۔

Deterministic جانچ tools کا استعمال

Repository ترجمے میں قابلِ مشاہدہ اختلافات کی جانچ کے لیے مقامی اسکرپٹس فراہم کرتا ہے۔ پہلے skill integrity test چلائیں:

bash references/test-skill-integrity.sh

اس کے بعد source file اور target file پر translation audit چلایا جا سکتا ہے:

python3 scripts/audit_translation.py source.tex target.tex \
  --glossary terminology-glossary.json \
  --alignment alignment.json \
  --output qa-report.json

یہ audit اعداد، protected fragments، حوالہ جاتی تعداد، بنیادی ساخت، alignment معلومات اور درج شدہ اصطلاحات کی جانچ کر سکتا ہے۔ اصل shell entry point بھی استعمال کیا جا سکتا ہے:

bash references/test-translation-structure.sh source.tex target.tex glossary.json

Exit codes کے معنی یہ ہیں:

• 0：موجودہ checks میں کوئی اختلاف نہیں ملا۔
• 1：مزید جانچ درکار اختلاف ملا۔
• 2：input یا parsing error۔

0 کا exit code اس بات کی علامت نہیں کہ ترجمہ submission کے لیے تیار ہے۔ اگر alignment فراہم نہ کیا گیا ہو تو paragraph-wise coverage یا اصطلاحی compliance مکمل ہونے کا دعویٰ نہیں کیا جا سکتا۔ اعداد کی بعض درست ترتیب یا format کی تبدیلیاں بھی اختلاف پیدا کر سکتی ہیں، جن کے نتیجے کو انسان کو درج اور handle کرنا ہوگا۔

یہ scripts “AI flavor” کی جانچ نہیں کرتیں اور نہ ہی شعبہ جاتی درستگی کی تصدیق کرتی ہیں۔ یہ صرف deterministic ساختی اختلافات دریافت کرنے میں مدد دیتی ہیں، semantic review، انسانی تصدیق یا ماہر کے حتمی جائزے کا متبادل نہیں ہیں۔

اعلیٰ سطحی عملی تجاویز

اصطلاحی فہرست کا version منجمد کریں اور context درج کریں

نمونہ اصطلاحی فہرست کو تمام مقالوں پر براہِ راست لاگو نہ کریں۔ منصوبے کی فراہم کردہ نمونہ اصطلاحی فہرست صرف fields کی وضاحت کے لیے ہے اور بیرونی verification کے بغیر استعمال نہیں کی جانی چاہیے۔ حقیقی منصوبے میں concepts، chapters اور context کے مطابق اپنی اصطلاحی entries بنائیں، اور ترمیم کے بعد متاثرہ اصطلاحات دوبارہ جانچیں۔

وفاداری کی حد اور زبان کے معیار میں فرق کریں

پہلے فیصلہ کریں کہ ترجمے نے سائنسی مفہوم محفوظ رکھا ہے یا نہیں، پھر جملے کی روانی کا جائزہ لیں۔ دریافت شدہ غلطیوں کی تعداد صفر ہونا خودکار طور پر مکمل نمبر کے برابر نہیں، کیونکہ جانچ کا دائرہ محدود ہو سکتا ہے یا کچھ مسائل ابھی شناخت نہ ہوئے ہوں۔ زبان کی تدوین بھی زیادہ پرکشش اظہار کے ذریعے ناکافی شواہد کو چھپا نہیں سکتی۔

فارمیٹ اور حوالہ جاتی تعلق محفوظ رکھیں

ترجمہ شروع کرنے سے پہلے ساختی فہرست بنائیں، اور خاص طور پر فارمولوں، macros، citations، table coordinates، figure captions اور appendices کو درج کریں۔ ترمیم کے بعد صرف یہ نہ دیکھیں کہ اعداد موجود ہیں، بلکہ یہ بھی یقینی بنائیں کہ اعداد اب بھی درست indicator، unit اور condition سے منسلک ہیں؛ فارمولوں کی تعداد برابر ہونا اس بات کی دلیل نہیں کہ variables تبدیل نہیں ہوئے۔

مسئلہ نمبر کے مطابق ترمیم مکمل کریں

ہر مسئلے کے لیے مستقل issue ID رکھیں، اور اصل متن، موجودہ ترجمہ، ترمیم، وجہ اور location درج کریں۔ ترمیم مکمل ہونے کے بعد source text، ابتدائی ترجمے اور edited draft کا دوبارہ تقابل کریں، اور خاص طور پر conditions کے دائرۂ اثر، علت و معلول، indicators، citations اور دعوے کی قوت کو دوبارہ دیکھیں۔

منصوبے کی فائلوں کی رہنمائی

• SKILL.md：skill entry point اور release conditions۔
• اصطلاحی معاہدہ：متحد glossary schema اور alignment format۔
• کرداروں کا معاہدہ：حقیقی tools اور file ownership کے تقاضے۔
• لسانی رہنما：وفادار، مختصر اور فطری اظہار۔
• قارئین کی رہنمائی پر مبنی تدوین：chapter routing، sentence-level load، cohesion اور تدوین کے بعد fidelity review۔
• شعبہ جاتی profiles：مختلف شعبوں کے اہم risks۔
• رویّاتی evaluation：model behavior acceptance plan۔
• ترجمے کی مثال：تعمیر شدہ اختلافی cases، شائع شدہ اثر پذیری کا ثبوت نہیں۔

اختتامیہ

sci-translation-skill کی قدر اس بات میں ہے کہ یہ مقالے کے ترجمے کو یک وقتی polishing سے بدل کر ایسا قابلِ سراغ workflow بناتا ہے جس میں اصطلاحات کو منجمد کرنا، وفادار ابتدائی ترجمہ، آزادانہ نظرِ ثانی، اختلافات کی جانچ اور مصنف کی تصدیق شامل ہے۔ pilot، review، مکمل delivery اور حتمی audit کی ترتیب سے استعمال کرنے پر تکنیکی اور فارمیٹنگ risks پہلے دریافت کیے جا سکتے ہیں۔

لیکن یہ شعبہ جاتی درستگی کی خودکار certification tool نہیں، اور نہ ہی سائنسی نتائج کی مصنف کی تصدیق کا متبادل ہے۔ پیچیدہ فارمیٹس، طبی مسودوں اور submission کے لیے تیار کیے جانے والے کسی بھی ترجمے میں rendered checks، انسانی review اور ماہرین کے حتمی جائزے کو شامل کرنا چاہیے۔