i18n خراب ہے: ترجمے کی keys لکھنا بند کریں

بین الاقوامی کاری (اکثر مختصراً i18n)، لوکلائزیشن (l10n)، اور کثیراللسانی سپورٹ — یہ سب ایک ہی خیال کی وضاحت کرتے ہیں: اپنی پروڈکٹ کو اس طرح ڈھالنا کہ لوگ اسے اپنی زبان میں استعمال کر سکیں۔

i18n اب بھی 2005 والے انداز میں بنی ہوئی ہے

ہر کاروبار آخرکار سمجھ لیتا ہے کہ اسے کئی زبانوں کی سپورٹ دینی ہوگی۔ اُس وقت پروڈکٹ ٹیم کسی مکینک کی طرح پیچھے ہو کر ٹیک لگاتی ہے، دانتوں سے ہوا کھینچتی ہے، اور کہتی ہے، “کتنے صفحات کی بات ہو رہی ہے؟ کم از کم چار اسپرنٹس تو لگیں گے۔”

i18n نافذ کرنے کا بنیادی طریقہ پچھلے 20 سال سے نہیں بدلا۔ i18n کی زیادہ تر “بہترین عملی طریقے” جدید ویب آرکیٹیکچرز سے بہت پہلے بنے تھے، اور اس کے بعد سے سب کچھ بس انہی پر تہہ در تہہ چڑھایا گیا ہے۔

i18n جدید ویب ڈویلپمنٹ کا وہ واحد حصہ ہے جس میں اب بھی فائلیں برآمد کرنا اور کسی کو بھیجنا شامل ہے۔ اگر انہیں ای میل کرنے کے بجائے آپ API کے ذریعے اپ لوڈ کر دیں، تو اسے جدید سیٹ اپ سمجھا جاتا ہے۔

ایسے دور میں جہاں CI پائپ لائنز اور ڈیپلائز دنوں کے بجائے منٹوں میں ناپے جاتے ہیں، شاید ہمیں خوش قسمت سمجھنا چاہیے کہ ہمیں کچھ بھی فیکس نہیں کرنا پڑتا۔

i18n کیوں ٹوٹا پھوٹا محسوس ہوتا ہے

جدید ویب ڈویلپمنٹ نے بہت تیزی سے ترقی کی ہے۔

ہمارے پاس ہے:

• سرور-رینڈرڈ کمپوننٹس
• streaming UI
• edge runtimes
• مسلسل deployment
• AI-مقامی ٹولنگ

پھر بھی بین الاقوامی سازی کے ورک فلو اب بھی ایسے محسوس ہوتے ہیں جیسے وہ کسی اور دور سے تعلق رکھتے ہوں۔

حتیٰ کہ نسبتاً چھوٹی ایپلیکیشنز بھی جلد ہی ان چیزوں کو سنبھالتے سنبھالتے الجھ جاتی ہیں:

• ترجمہ کی keys
• JSON ترجمہ فائلیں
• دستی ترجمہ pipelines
• الگ تھلگ فرنٹ اینڈ بمقابلہ بیک اینڈ لوکلائزیشن لاجک
• translation management tools

ڈویلپرز یہ سوچ کر ایسے نظام نہیں بناتے۔ وہ آہستہ آہستہ اس میں جا پڑتے ہیں، کیونکہ زبان سے متعلق عام i18n رکاوٹیں ان ڈویلپرز کو الجھا دیتی ہیں جو اس بات سے ناواقف ہوتے ہیں کہ مختلف زبانیں جملوں کی ساخت بالکل مختلف رکھتی ہیں… اور 20 سال پہلے طے شدہ موجودہ طریقۂ کار کو بے دلی سے قبول کر لیتے ہیں۔

وقت کے ساتھ، بین الاقوامی سازی اسٹیک کے سب سے پیچیدہ حصوں میں سے ایک بن جاتی ہے۔

جدید UI ترجمے کی سٹرنگز کے اندر فٹ نہیں بیٹھتا

ایک سادہ UI پر غور کریں:

<h1>Hello world!</h1>
<p>
  <a href="#/">Click here</a> to view your <b>{serverResponse.productDescription}</b>
</p>

یہ سمجھنے میں آسان ہے۔ یہ سادہ ہے۔

کسی مرحلے پر ہم اسے بین الاقوامی بنانا فیصلہ کرتے ہیں۔ پھر ہم متن کو نکال کر ترجمہ فائل میں ڈال دیتے ہیں:

{
  "mainPage": {
    "greeting": "Hello world",
    "cta": "<0>Click here</0> to view your <1>{{description}}</1>"
  }
}

اور ہم اپنے code میں اس کا حوالہ دیتے ہیں:

<h1>{t('mainPage.greeting')}</h1>
<p>
  <Trans key="mainPage.cta">
    <a href="#/">Click here</a> to view your <b>{{ description: serverResponse.productDescription }}</b>
  </Trans>
</p>

لیکن، ذرا رُکیے، اب ہمارے پاس کوڈ میں بھی انگریزی متن ہے، اور ہماری ترجمہ فائل میں بھی؟ جی ہاں۔ مختلف i18n لائبریریاں اس پر الگ الگ رنگ چڑھاتی ہیں، لیکن جزوی طور پر فارمیٹ شدہ متن کو نکال کر اسے انسانوں کے پڑھنے کے قابل JSON فائل میں ڈال کر ترجمہ کرنے کی کوشش ایک ہارتی ہوئی جنگ ہے۔

جدید UI منظم ہوتا ہے، مگر ترجمے کے نظام سادہ سٹرنگز کی بنیاد پر بنائے جاتے ہیں۔

جیسے ہی مارک اپ، ویری ایبلز، اور ڈائنامک مواد منظر میں آتے ہیں، ابسٹریکشن میں رِساؤ شروع ہو جاتا ہے۔

متحرک اور صارف سے بنے مواد روایتی i18n کو درہم برہم کر دیتے ہیں

جب مواد جامد نہ ہو تو معاملات اور بھی مشکل ہو جاتے ہیں۔

اس مثال کو دوبارہ لیں:

<b>{serverResponse.productDescription}</b>

وہ سٹرنگ ایک API سے آ رہی ہے۔ ہم اسے ترجمے کی key میں کیسے بدلیں؟

خلاصہ یہ کہ: نہیں۔ اب آپ کے بیک اینڈ کو بھی بین الاقوامی سازی کی سپورٹ دینی ہوگی۔

اب آپ کے بیک اینڈ کو یہ سب سنبھالنا ہوگا:

• اصل معنوی ڈیٹا
• ترجمہ شدہ variants
• فال بیک لاجک
• لوکیل ڈیٹیکشن

ترجمہ کاروں کو اچانک بیک اینڈ سسٹمز تک بھی رسائی درکار ہوتی ہے۔

اور مسئلہ تب اور بڑھ جاتا ہے جب صارف کے بنائے ہوئے مواد کا معاملہ آتا ہے۔

ریویوز۔ تبصرے۔ مارکیٹ پلیس لسٹنگز۔ فورمز۔

روایتی i18n pipelines یہ فرض کرتی ہیں کہ ڈویلپرز تمام متن پر کنٹرول رکھتے ہیں۔ بڑھتی ہوئی حد تک، یہ بات سچ نہیں رہی۔

یہ حقیقت کہ Amazon جیسی کمپنیاں 2026 میں ترجمہ شدہ صارف ریویوز کے ساتھ تجربات شروع کر چکی ہیں، اس بات کے بارے میں بہت کچھ بتاتی ہے کہ i18n ماحولیاتی نظام کتنی سست رفتاری سے ترقی کر پایا ہے۔

Locale Detection اب بھی ایک الجھا ہوا مسئلہ ہے

یہ طے کرنا بھی حیرت انگیز طور پر پیچیدہ ہے کہ صارف کون سی زبان چاہتا ہے۔

Browsers زبان کی ترجیحات Accept-Language ہیڈر کے ذریعے بھیجتے ہیں:

Accept-Language: en-GB,en;q=0.9,fr;q=0.8

یہ سرور کو بتاتا ہے:

1. برطانوی انگریزی کو ترجیح دیں
2. پھر انگریزی کی کوئی بھی شکل
3. پھر کسی بھی قسم کی فرانسیسی

عملی طور پر، اسے درست طریقے سے نافذ کرنے میں یہ شامل ہوتا ہے:

• parsing quality weights
• لوکلز کو نارملائز کرنا (en, en-GB, en-US)
• تعاون یافتہ زبانوں کا میچ ہونا
• fallback logic کو ہینڈل کرنا
• واضح صارف اووررائیڈز کا احترام کرتے ہوئے

بہت سے frameworks اس منطق کا بڑا حصہ developers پر چھوڑ دیتے ہیں۔

بنیادی سطح کی locale detection بھی اکثر کسٹم ایپلیکیشن کوڈ بن جاتی ہے۔

زبان بدلنا بعد کی سوچ ہے

ترجمے کا بنیادی ڈھانچہ مسئلے کا صرف آدھا حصہ ہے۔

صارفین کو اب بھی زبان بدلنے کا کوئی طریقہ درکار ہے۔

زیادہ تر i18n لائبریریاں ترجمے کی تہہ فراہم کرتی ہیں مگر باقی مسئلہ ڈویلپر پر چھوڑ دیتی ہیں:

• زبان بدلنے والے
• locale routing
• کوکی کی مستقلّت
• URL canonicalisation
• SEO کے لیے hreflang ٹیگز

یہ تفصیلات چھوٹی سی لگتی ہیں، مگر جلد ہی ایپلیکیشن کے بہت سے بنیادی جوڑ توڑ کا بڑا حصہ بن جاتی ہیں، خاص طور پر اگر آپ i18n کی باریکیوں سے واقف نہیں۔ زیادہ تر کمپنیاں اور ڈویلپرز واقف نہیں ہوتے۔

شارٹ کٹ: خودکار website translation

اس تمام پیچیدگی کے باوجود، کچھ ٹیمیں خودکار ویب سائٹ ترجمہ ٹولز کی طرف جاتی ہیں۔ یہ پلیٹ فارمز کم سے کم محنت کے ساتھ آپ کی سائٹ خود بخود ترجمہ کرنے کا وعدہ کرتے ہیں۔

کئی کمپنیاں اس خیال کی مزید پیچیدہ اور نفیس شکلیں بنا رہی ہیں۔ بدقسمتی سے اس سے ایک اور طرح کے مسائل پیدا ہو جاتے ہیں:

• ترجمے اکثر client-side ہوتے ہیں
• SEO ٹوٹ جاتا ہے
• متحرک طور پر لوڈ ہونے والے مواد کا ترجمہ درست زبان کی جھلک کے بغیر نہیں کیا جا سکتا
• ڈویلپر کا کنٹرول ختم ہو جاتا ہے

اس کا نتیجہ اکثر ایک ایسی سائٹ ہوتی ہے جو بظاہر کئی زبانوں کو سپورٹ کرتی ہے، مگر تجربہ نمایاں طور پر خراب دیتی ہے، اور ڈویلپرز کے لیے ایک بلیک باکس بن جاتی ہے۔

ہم یہاں تک کیسے پہنچے

ہم نے ایک نہایت سادہ، خوبصورت چیز سے آغاز کیا:

<h1>Hello world!</h1>
<p>
  <a href="#/">Click here</a> to view your <b>{serverResponse.productDescription}</b>
</p>

اور نتیجہ یہ نکلا کہ ترجمہ کی keys، JSON dictionaries، بکھری ہوئی pipelines، الگ الگ بیک اینڈ اور فرنٹ اینڈ localization layers، اور بیرونی ترجمہ ٹولنگ وجود میں آئی۔

جدید ویب ایپس انتہائی پیچیدہ سسٹمز ہیں۔ پھر بھی i18n ٹولنگ ایسے workflows کی توقع کرتی ہے جو کسی اور دور کے لیے بنائے گئے تھے، جیسے فیراری ہو مگر انجن اسٹارٹ کرنے کے لیے ہینڈ کرینک لگی ہو۔

ماڈل پر دوبارہ غور

اگر بین الاقوامی سازی کچھ اس طرح نظر آتی؟

<h1><T>Hello world!</T></h1>
<p>
  <T>
    <a href="#/">Click here</a> to view your <b>{serverResponse.productDescription}</b>
  </T>
</p>

کوئی translation keys نہیں۔

کوئی JSON dictionaries نہیں۔

کوئی دستی pipelines نہیں۔

بس متن۔

ایک مختلف طریقہ

یہ خیال 18ways کی بنیاد ہے۔

18ways ترجمے کو ایک بہتر بنائے گئے runtime مسئلے کے طور پر دیکھتا ہے۔ ترجمہ keys نکالنا اور ترجمہ فائلوں کا نظم کرنا انسانوں کا نہیں، مشینوں کا مسئلہ ہے۔

ڈویلپرز بس وہ متن نشان زد کر دیتے ہیں جس کا ترجمہ وہ چاہتے ہیں۔

پردے کے پیچھے، 18ways:

• strings نکالتا ہے
• AI استعمال کرتے ہوئے ترجمے تیار کرتا ہے
• نتائج cache کرتا ہے
• ترجمہ شدہ HTML براہِ راست سرور سے فراہم کرتا ہے

سب کچھ SSR کے لیے دوستانہ اور SEO کے لیے محفوظ رہتا ہے۔

سیاق و سباق سے آگاہ تراجم

روایتی i18n سسٹمز سیاق و سباق کھو دیتے ہیں۔

ایک مترجم کو کچھ یوں دکھائی دے سکتا ہے:

home

لیکن اس کا مطلب کیا ہے؟

جرمن میں، ان معانی کے لیے بالکل مختلف الفاظ درکار ہوتے ہیں:

• Haus - ایک گھر
• Startseite - ہوم پیج
• Start - ایک navigation label
• zum Anfang - آغاز کی طرف واپس جائیں

اگر آپ کو “home” کا جرمن میں ترجمہ کرنا ہو، تو آپ کیا دیکھنا پسند کریں گے؟ ایک اکیلی سٹرنگ، یا وہ صفحہ جہاں یہ اصل میں ظاہر ہوتی ہے؟

ایسی ترجمہ سسٹمز جو صرف الگ تھلگ strings دیکھتی ہیں، ان باریکیوں میں مشکل محسوس کرتی ہیں۔

18ways ترجموں کا اصل UI کے سیاق و سباق میں تجزیہ کرتا ہے۔

ہمارے بیک اینڈ agents ترجمے اُن کے اصل صفحات پر ظاہر ہوتے ہی review کرتے ہیں اور ان چیزوں کے لیے optimise کرتے ہیں:

• context
• یکسانیت
• لے آؤٹ کی پابندیاں
• ترجمے کا معیار

اور جو کوئی جرمن compound nouns سے واقف ہے، فکر نہ کریں، overflow detection بھی شامل ہے۔

انسانی مترجمین کو بااختیار بنانا

جو کچھ بھی AI کو بہتر ترجمے بنانے میں مدد دیتا ہے، وہ انسانی مترجمین کی بھی مدد کرتا ہے۔

18ways مترجمین کو وہی context-aware ماحول فراہم کرتا ہے جو ہمارے AI agents استعمال کرتے ہیں۔

JSON فائلیں ایڈٹ کرنے کے بجائے، مترجمین متن کا جائزہ براہِ راست اُس UI کے ساتھ لیتے ہیں جہاں وہ ظاہر ہوتا ہے۔

اس سے ترجمے کی درستگی اور ورک فلو کی کارکردگی میں نمایاں بہتری آتی ہے۔

بہتر i18n کیسا نظر آتا ہے

بین الاقوامی کاری کو ترجمے کی keys، string files، اور pipeline glue کی ایک اور تہہ کی ضرورت نہیں ہے۔

جدید ایپس میں پہلے ہی وہ ساخت، سیاق، اور رن ٹائم معلومات موجود ہیں جن کی ہمیں یہ کام بہتر طریقے سے کرنے کے لیے ضرورت ہے۔

i18n کی اگلی نسل server-rendered apps، dynamic content، AI-native workflows، اور ساتھ ساتھ کام کرنے والے انسانی مترجمین کے لیے بننی چاہیے۔

18ways اسی سمت جا رہا ہے۔