5.5 بین الاقوامیت اور مقامی کاری

جائزہ اور محرکات

بین الاقوامیت (i18n) سافٹ ویئر اس طرح بنانے کا انجینئرنگ کا کام ہے کہ اسے کوڈ بدلے بغیر کسی بھی زبان، خطے، اور ثقافت کے مطابق ڈھالا جا سکے۔ مقامی کاری (l10n) وہ کام ہے جو اس کے بعد آتا ہے: متن کا ترجمہ کر کے، تاریخوں اور اعداد کی شکل بدل کر، ترتیب ایڈجسٹ کر کے، اور ثقافتی توقعات کا لحاظ رکھ کر پروڈکٹ کو کسی مخصوص locale کے مطابق ڈھالنا۔ دونوں الگ ہیں۔ بین الاقوامیت ایک بار فن تعمیر میں کی جاتی ہے۔ مقامی کاری بار بار مواد میں کی جاتی ہے۔ فن تعمیر شروع میں درست کر لیں تو ہر مقامی کاری سستی ہے۔ غلط ہو تو ہر ایک تکلیف دہ، غلطیوں سے بھری دوبارہ لگائی کاوش بن جاتی ہے۔

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

انٹرپرائز اور حکومت کی مطابقت براہ راست ہے۔ کثیر قومی انٹرپرائزز کو ملکوں، زبانوں، اور ضابطوں کے نظاموں میں گاہکوں اور ملازمین کی خدمت کرنی ہے۔ حکومتوں کو لسانی طور پر متنوع آبادیوں کی خدمت کرنی ہے۔ بہت سے ملک سرکاری طور پر کثیر لسانی ہیں، اور بہت سوں پر قانونی تقاضا ہے کہ خدمات کئی زبانوں میں دیں، بشمول دائیں سے بائیں رسم الخط اور مقامی یا اقلیتی زبانیں۔ عوامی خدمات کے لیے زبان تک رسائی انصاف اور قانون کا معاملہ ہے: وہ شہری جو واحد دستیاب زبان نہ پڑھ سکے اسے عملاً سروس سے محروم کر دیا گیا۔

بنیادی اصول

فن تعمیر کی بین الاقوامیت ایک بار کریں؛ مواد کی مقامی کاری بار بار۔
صارف کی طرف کا متن کبھی ہارڈ کوڈ نہ کریں؛ تمام سٹرنگز منظم وسائل میں باہر رکھیں۔
ہر جگہ Unicode (UTF-8) استعمال کریں؛ فرض کریں کہ متن کسی بھی رسم الخط میں ہو سکتا ہے۔
ترجمہ شدہ ٹکڑے کبھی نہ جوڑیں؛ قواعد اور الفاظ کی ترتیب زبانوں میں مختلف ہے۔
متن کے پھیلاؤ، دائیں سے بائیں رسم الخط، اور پیچیدہ جمع اور جنس کے قواعد کی منصوبہ بندی کریں۔
تاریخیں، اعداد، کرنسیاں، اور نام locale کے مطابق فارمیٹ کریں، کوڈ کے مطابق نہیں۔
قابل ترجمہ مواد کو کوڈ سے الگ رکھیں تاکہ مترجم سورس کو کبھی نہ چھوئیں۔
مقامی کاری ثقافتی ہے، صرف لسانی نہیں: رنگ، تصاویر، اور مثالیں اہم ہیں۔

سفارشات

مضبوط بین الاقوامیت کا فن تعمیر بنائیں

تمام متن Unicode (UTF-8) کے طور پر سرے سے سرے تک ذخیرہ اور پروسیس کریں (ڈیٹا بیس، APIs، اور UI) تاکہ کوئی بھی رسم الخط ظاہر ہو سکے۔ ہر صارف کی طرف کی سٹرنگ کو شناخت کنندہ سے چابی شدہ وسائل کی فائلوں یا پیغام کیٹلاگ میں باہر رکھیں، کبھی کوڈ یا مارک اپ میں شامل نہ کریں۔ Locale کو زبان جمع خطے (اور جہاں ضرورت ہو رسم الخط) کے طور پر ظاہر کریں تاکہ آپ، مثلاً، ایک زبان کے ملکوں میں مختلف روپ ممتاز کر سکیں۔ فارمیٹنگ کی منطق کو تاریخ، عدد، اور کرنسی کی فارمیٹنگ ہاتھ سے بنانے کی بجائے اچھی طرح ٹیسٹ شدہ بین الاقوامیت کی لائبریری میں رکھیں۔ ڈیٹا غیر جانبدار، غیر مبہم شکلوں میں رکھیں (UTC ٹائم اسٹیمپس، ISO ملک اور کرنسی کے کوڈ، بنیادی اکائیاں) اور صرف پیشکش کی تہہ میں فارمیٹ کریں۔

زبان کی پیچیدگی درست سنبھالیں

متن کی لمبائی فرض نہ کریں؛ فراخ جگہ دیں کیونکہ ترجمے عموماً انگریزی سے کہیں لمبے ہوتے ہیں، اور ایسی ترتیب ڈیزائن کریں جو کاٹنے یا اوور لیپ کی بجائے دوبارہ بہے۔ دو طرفہ (دائیں سے بائیں) رسم الخط کی معاونت جسمانی کی بجائے منطقی ترتیب کی خصوصیات استعمال کر کے اور جہاں مناسب ہو انٹرفیس کو آئینہ کر کے کریں۔ سادہ واحد/جمع منطق کی بجائے اپنی i18n لائبریری کے ذریعے locale کے جمع کے قواعد استعمال کریں (زبانوں میں جمع کی ایک سے چھ شکلیں ہوتی ہیں)۔ جہاں زبان تقاضا کرے وہاں جنس اور قواعدی مطابقت سنبھالیں۔ جملے کبھی جوڑ کر نہ بنائیں؛ مکمل، پیرامیٹر شدہ پیغام کے سانچے استعمال کریں تاکہ مترجم الفاظ کی ترتیب کو کنٹرول کریں۔

مقامی کاری کا ورک فلو اور ترجمے کا انتظام قائم کریں

مقامی کاری کو لانچ سے پہلے کے بیچ کی بجائے مسلسل پائپ لائن سمجھیں۔ سٹرنگز خودکار طور پر نکالیں، انہیں ترجمے کے انتظام کے نظام میں بھیجیں، اور مکمل ترجمے واپس کھینچیں، مثالی طور پر CI کے ساتھ مربوط تاکہ نئی سٹرنگز نشان زد ہوں اور مقامی ورژن ہم آہنگ رہیں۔ مترجمین کو سیاق دیں: اسکرین شاٹس، تفصیلات، حروف کی حدیں، اور ہر زبان کی لغت اور اسٹائل گائیڈ تاکہ اصطلاحات اور لہجہ مستقل رہیں۔ پچھلا کام دوبارہ استعمال کرنے اور لاگت کاٹنے کے لیے translation memory استعمال کریں۔ دانستہ طے کریں کہ مشینی ترجمہ کہاں قابل قبول ہے (کم خطرے، زیادہ حجم کا مواد) اور کہاں انسانی ترجمہ اور ریویو ضروری ہے (قانونی، طبی، حفاظتی، برانڈ کے لیے اہم)۔ Pseudo-localise جلد کریں، سٹرنگز کو لمبے، لہجہ دار placeholders سے بدل کر، تاکہ حقیقی ترجمہ شروع ہونے سے پہلے ہارڈ کوڈ سٹرنگز، کٹاؤ، اور encoding کے بگز پکڑے جائیں۔

صرف الفاظ نہیں، فارمیٹ، ثقافت، اور مواد کی مقامی کاری کریں

تاریخیں، اوقات، اعداد، کرنسیاں، پتے، فون نمبر، اور نام فی locale فارمیٹ کریں، مقامی کنونشنز کا احترام کرتے ہوئے (تاریخ کی ترتیب، اعشاریہ اور گروپنگ کے علامات، کرنسی کی جگہ، نام کی ترتیب)۔ تصاویر، آئیکنز، رنگ، مثالیں، اور استعارے مقامی ثقافتی معنی کے مطابق ڈھالیں، کیونکہ علامات اور رنگ ثقافتوں میں مختلف مفہوم رکھتے ہیں۔ مقامی قانونی اور ضابطے کے مواد کے فرق کا حساب رکھیں۔ عالمی مستقل مزاجی (برانڈ، بنیادی فعالیت) کو علاقائی موافقت (مواد، مثالیں، تعمیل) سے ممتاز کریں اور واضح طور پر طے کریں کہ کون سے عناصر مقررہ ہیں اور کون سے لچکتے ہیں۔

i18n کو مشترک انفراسٹرکچر کے طور پر منظم کریں

مشترک i18n لائبریری، سٹرنگ کی بیرونی کاری کے lint اصول، اور locale حل کرنے کا معیاری طریقہ فراہم کریں تاکہ ٹیمیں حادثاتی طور پر متن ہارڈ کوڈ نہ کر سکیں۔ مقامی کاری کی پائپ لائن اور لغات کی ملکیت قائم کریں۔ CI میں متعدد locales میں ٹیسٹ کریں، بشمول دائیں سے بائیں locale اور لمبے متن کا pseudo-locale، تاکہ regressions خود بخود پکڑے جائیں۔

سمجھوتے: فوائد اور نقصانات

فیصلہ	فوائد	نقصانات
پہلے دن سے بین الاقوامیت	بعد میں سستا منڈی میں داخلہ، دوبارہ لگانا نہیں	دوسرے locale کی ضرورت سے پہلے بھی پیشگی لاگت
بعد میں i18n دوبارہ لگانا	عالمی ضرورت غیر یقینی ہو تو لاگت موخر	ہارڈ کوڈ مفروضے کھولنا بہت مہنگا اور خطرناک
انسانی ترجمہ	اعلیٰ معیار، ثقافتی طور پر درست	سست اور زیادہ مہنگا
مشینی ترجمہ	تیز، سستا، بہت بڑے حجم تک پیمانہ	معیار اور درستگی کا خطرہ؛ زیادہ داؤ کے مواد کے لیے نامناسب
مسلسل مقامی کاری کی پائپ لائن	locales ہم آہنگ رہتے ہیں، لانچ کا دباؤ نہیں	ٹولنگ اور عمل کی سرمایہ کاری
فی علاقہ گہری ثقافتی موافقت	بہتر مقامی موزونیت اور اعتماد	بنانے اور برقرار رکھنے کو مزید مواد کی variants

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

اپنی ٹیم کے ساتھ بحث کے سوالات

کیا ہم lint اصولوں سے سٹرنگ کی بیرونی کاری نافذ کرتے ہیں، اور کیا pseudo-localisation حقیقی ترجمے سے پہلے CI میں چلتی ہے؟ وہ قرض جو بین الاقوامیت کو مہنگا بناتا ہے (ہارڈ کوڈ انگریزی سٹرنگز، جوڑے ہوئے جملوں کے ٹکڑے، لاطینی رسم الخط کے مفروضے) خاموشی سے جمع ہوتا ہے جب تک ٹولنگ اسے commit کے وقت نہ روکے۔ ہارڈ کوڈ صارف کے متن کو نشان زد کرنے والے lint اصول، جمع CI میں لمبے متن کا لہجہ دار pseudo-locale، کٹاؤ، اوور لیپ، اور encoding کے بگز تب پکڑتے ہیں جب انہیں ٹھیک کرنا سستا ہے۔ یہی درجنوں ٹیموں کو ایک پروڈکٹ کئی زبانوں میں بھیجنے دیتا ہے بغیر اس کے کہ ہر ایک پلمبنگ دوبارہ ایجاد کرے یا بعد میں ڈیڈ لائن پر مفروضے کھولے۔ ہارڈ کوڈ سٹرنگز کی تلاش لائیں اور پوچھیں کیا کوئی ٹیم آج حادثاتی طور پر ایک بھیج سکتی ہے۔ اگر پائپ لائن میں کچھ اسے نہ پکڑے تو وہی پہلا خلا ہے جو بند کرنا ہے۔
ہم بنیادی ڈیٹا کہاں رکھتے ہیں، اور کیا فارمیٹنگ پیشکش کی تہہ تک محدود ہے؟ ٹائم اسٹیمپس UTC میں، ملک اور کرنسیاں ISO کوڈز میں، اور رقوم بنیادی اکائیوں میں رکھنے کا مطلب ہے کہ کوئی بھی locale انہیں کنارے پر درست فارمیٹ کر سکتا ہے، جبکہ ڈیٹا کی تہہ میں پکی فارمیٹنگ کی منطق ایسے بگز پیدا کرتی ہے جنہیں کھولنا تکلیف دہ ہے۔ اتفاق کریں کہ تاریخیں، اعداد، کرنسیاں، پتے، اور نام صرف پیشکش پر فارمیٹ ہوتے ہیں، ہاتھ سے بنے کوڈ کی بجائے اچھی طرح ٹیسٹ شدہ لائبریری کے ذریعے۔ یہ کثیر قومی انٹرپرائزز اور کثیر لسانی حکومتوں کے لیے اہم ہے جہاں شہری کو اپنی روایت میں درست تاریخ کی ترتیب، اعشاریہ کے علامات، اور نام کی ترتیب دکھنی چاہیے۔ ایسی قدر کی مثال لائیں جو آپ کا نظام پہلے سے فارمیٹ شدہ رکھتا ہے اور سراغ لگائیں کہ جب نئے locale کو اسے مختلف طرح چاہیے تو کیا ٹوٹتا ہے۔ اگر ڈیٹا اور پیشکش الجھے ہیں تو locales جوڑنے سے پہلے طے کریں کہ انہیں کیسے سلجھائیں گے۔
مشینی ترجمہ ٹھیک کہاں قابل قبول ہے، اور ہماری مقامی کاری کی پائپ لائن بیچ کی بجائے مسلسل کیسے رکھی جاتی ہے؟ مشینی ترجمہ کم خطرے، زیادہ حجم کے مواد کے لیے تیز اور سستا ہے مگر قانونی، طبی، حفاظتی، یا برانڈ کے لیے اہم متن کے لیے نامناسب ہے جہاں غلط ترجمہ حقیقی نقصان کرتا ہے، اس لیے حد واضح پالیسی ہونی چاہیے، فی ٹیم اندازہ نہیں۔ اسی طرح مقامی کاری کو لانچ سے پہلے کا بیچ سمجھنا ترجمے کے دباؤ کی ضمانت ہے، جبکہ سٹرنگز خودکار نکال کر ترجمے کے انتظام کے نظام سے ہم آہنگ کرنا ہر locale کو تازہ رکھتا ہے۔ طے کریں پائپ لائن، لغات، اور زیادہ داؤ کی سٹرنگز کے انسانی ریویو کے دروازے کا مالک کون ہے۔ حالیہ ریلیز لائیں اور پوچھیں اس کی نئی سٹرنگز ہر زبان میں ظاہر ہونے میں کتنا وقت لگا۔ اگر locales ریلیزز کے بیچ ہم آہنگی سے نکل جاتے ہیں تو آپ کی پائپ لائن بھیس میں بیچ ہے۔
کیا ہم دائیں سے بائیں locale اور لمبے متن کا pseudo-locale خودکار ٹیسٹ کرتے ہیں، یا خاموشی سے لاطینی رسم الخط اور انگریزی کی لمبائی کی ترتیبیں فرض کر رہے ہیں؟ دو طرفہ (دائیں سے بائیں) معاونت اور متن کا پھیلاؤ وہ مفروضے ہیں جو نئی منڈی میں سب سے زیادہ نمایاں ٹوٹتے ہیں: وہ آئینہ دار انٹرفیس جو کبھی آئینہ نہ ہوئے، اور وہ بٹن جو جرمن یا فنش کے انگریزی سے چالیس فیصد لمبا ہونے پر کٹ جاتے ہیں۔ متصادم کشش رفتار ہے، کیونکہ جسمانی کی بجائے منطقی ترتیب کی خصوصیات پر بنانا اور لہجہ دار pseudo-locale کو continuous integration (CI) میں جوڑنا کسی حقیقی گاہک کو ضرورت پڑنے سے پہلے محنت لیتا ہے۔ اپنی مصروف ترین اسکرینوں کا دائیں سے بائیں locale اور لمبے pseudo-locale میں rendered اسکرین شاٹ لائیں، اور اوور لیپس، کٹے لیبلز، اور اٹکے تیر گنیں۔ کثیر قومی انٹرپرائز یا دائیں سے بائیں یا اقلیتی زبان کی خدمت پر قانوناً پابند حکومت کے لیے جو ترتیب آئینہ نہ ہو سکے وہ آرائشی نقص نہیں، یہ ایسی منڈی یا قانونی ذمہ داری ہے جو دوبارہ بنائے بغیر آپ پوری نہیں کر سکتے۔
پروڈکٹ کے کون سے حصے عالمی طور پر مقررہ ہیں اور کون سے علاقے کے لحاظ سے لچکتے ہیں، اور فیصلے کا اختیار کس کے پاس ہے؟ مقامی کاری ثقافتی ہے، محض لسانی نہیں، اس لیے رنگ، تصاویر، مثالیں، آداب کے القاب، اور یہاں تک کہ کون سے فیچر پیش ہوں منڈی کے لحاظ سے مختلف ہو سکتے ہیں، پھر بھی ہر علاقائی variant جس کی آپ اجازت دیں ہمیشہ کے لیے بنانے، ترجمہ کرنے، ریویو کرنے، اور برقرار رکھنے کا ایک اور آرٹیفیکٹ ہے۔ کھنچاؤ مقامی موزونیت، جو اعتماد اور conversion بناتی ہے، اور مستقل مزاجی، جو برانڈ کو مربوط اور دیکھ بھال کا بوجھ محدود رکھتی ہے، کے درمیان ہے۔ ٹھوس فہرست لائیں کہ مجوزہ نیا locale ترجمہ شدہ سٹرنگز سے آگے کیا بدلے گا، اور ہر variant کی صرف پہلی تعمیر نہیں بلکہ جاری دیکھ بھال کی قیمت لگائیں۔ بڑے انٹرپرائز میں اس فیصلے کو نام زد مالک چاہیے تاکہ علاقائی ٹیمیں پروڈکٹ کو فی البدیہہ fork نہ کر سکیں، اور حکومت میں اسے مواد کے قانونی اور رسائی کے ان قواعد کا احترام کرنا ہوگا جو دائرہ اختیار کے لحاظ سے مختلف ہیں اور اختیاری نہیں۔
ہم حقیقت میں کن locales کا عہد کرتے ہیں، ان میں اصطلاحات مستقل کیسے رکھتے ہیں، اور کون سی شہادت اس فہرست کو چلاتی ہے؟ زبان جوڑنے کا وعدہ آسان اور اسے برقرار رکھنا مہنگا ہے، کیونکہ ہر ایک کو لغت، اسٹائل گائیڈ، زیادہ داؤ کی سٹرنگز کا انسانی ریویو، اور جمع اور جنس کی درست ہینڈلنگ چاہیے جسے سادہ واحد-یا-جمع منطق اکثر زبانوں میں غلط کرتی ہے۔ متصادم غور پہنچ بمقابلہ لاگت ہیں: بری طرح خدمت کی گئی منڈی یا آبادی بالکل خدمت نہ ملنے سے بدتر ہو سکتی ہے۔ ہر امیدوار locale کے پیچھے آبادی یا آمدنی، آپ کی لائبریری اس کے لیے جمع کے قواعد اور فارمیٹنگ کی کتنی کوریج دیتی ہے، اور اس کی لغت کا مالک کون ہے لائیں۔ کثیر قومی انٹرپرائز کے لیے محرک قابل رسائی منڈی اور فی زبان معاونت کی لاگت ہے، جبکہ حکومت کے لیے یہ زبان تک رسائی کی قانونی ذمہ داری اور انصاف ہے، اس تعداد سے مقداری جو صرف اس زبان میں لین دین کر سکنے والے رہائشیوں کی ہے۔

شعبہ جاتی نقطۂ نظر

اسٹارٹ اپ۔ پہلے دن سستے فن تعمیر کے انتخاب کریں اور وہیں رک جائیں: سرے سے سرے تک UTF-8، ہر صارف کی طرف کی سٹرنگ پیغام کیٹلاگ میں، اور تاریخیں، اعداد، اور کرنسیاں locale سے باخبر لائیبریری سے فارمیٹ شدہ۔ یہ ایک زبان میں بھیجتے ہوئے تقریباً کچھ لاگت نہیں لیتے اور جب آپ کا پہلا بڑا گاہک دوسری زبان مانگے تو دوبارہ تحریر بچاتے ہیں۔ ابھی ترجمے کی پائپ لائن کھڑی نہ کریں یا ایسے locales کی معاونت نہ کریں جن کی کوئی ادائیگی نہیں کر رہا؛ دروازہ کھلا رکھیں، پورا گھر نہ سجائیں۔

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

بڑا ادارہ۔ مسئلہ بہت سی ٹیموں میں نظم و نسق ہے: مشترک i18n لائبریری، ہارڈ کوڈ سٹرنگز کو مسترد کرنے والے lint اصول، translation memory اور فی زبان لغات کے ساتھ مسلسل مقامی کاری کی پائپ لائن، اور کثیر locale CI جس میں دائیں سے بائیں اور لمبے متن کا pseudo-locale شامل ہو۔ مقامی کاری کو واضح مالک کے ساتھ مشترک انفراسٹرکچر کے طور پر چلائیں تاکہ گروہ پلمبنگ دوبارہ ایجاد کرنا یا ہم آہنگی سے نکلنا چھوڑ دیں۔ زبان کی کوریج، مقامی کاری کا معیار، اور نئے locale کے لانچ کا وقت ناپیں، اور locale کا پورٹ فولیو فی البدیہہ منڈیاں شروع کرنے کی بجائے ان اعداد کے مقابل منظم کریں۔

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

مثالیں

اسٹارٹ اپ۔ صرف انگریزی میں بھیجنے والے چھوٹے اسٹارٹ اپ نے پھر بھی پہلے دن چند سستے فن تعمیر کے انتخاب کیے: ہر جگہ UTF-8، ہر صارف کی طرف کی سٹرنگ ہارڈ کوڈ کی بجائے پیغام کیٹلاگ میں کھینچی ہوئی، اور تاریخیں اور کرنسیاں locale سے باخبر لائبریری سے فارمیٹ شدہ۔ ایک زبان کے ہوتے ہوئے اس کی تقریباً کچھ لاگت نہ آئی۔ ایک سال بعد، جب ان کے سب سے بڑے امکانی گاہک نے فرانسیسی اور جرمن ورژن مانگا، تو وہ locales جوڑنا زیادہ تر ٹھیکیدار کو سونپی گئی ترجمے کی مشق تھی، دوبارہ تحریر نہیں، اور انہوں نے سودا انجینئرنگ کے کام کی سہ ماہی موخر کرنے کی بجائے ہفتوں میں بند کیا۔

بڑا ادارہ۔ عالمی e-commerce کمپنی نے اپنا پلیٹ فارم جلد بین الاقوامی بنایا: ہر جگہ UTF-8، بیرونی سٹرنگز، locale سے باخبر فارمیٹنگ کی لائبریری، اور translation memory اور فی زبان لغات کے ساتھ مسلسل مقامی کاری کی پائپ لائن۔ نئی منڈی میں داخلہ انجینئرنگ کے منصوبے کی بجائے بڑی حد تک مواد کی مشق بن گیا (ترجمہ، ریویو، تصاویر ایڈجسٹ)، جس نے کمپنی کو نئے locales ہفتوں میں لانچ کرنے دیے۔ منطقی ترتیب کی خصوصیات پر بنی دائیں سے بائیں معاونت کا مطلب تھا کہ عربی اور عبرانی منڈیوں کو نئے UI کا کم کام لگا۔

حکومت۔ قومی حکومت جو قانوناً کئی سرکاری زبانوں میں خدمات دینے کی پابند تھی، بشمول دائیں سے بائیں رسم الخط اور اقلیتی زبانیں، نے مشترک i18n کا فریم ورک اور ترجمے کا ورک فلو بنایا جو ایجنسیوں میں استعمال ہوتا ہے۔ CI میں pseudo-localisation نے لانچ سے پہلے ہارڈ کوڈ سٹرنگز اور کٹاؤ پکڑے؛ مشترک لغت نے قانونی اصطلاحات خدمات اور زبانوں میں مستقل رکھیں۔ شہری ٹیکس، صحت، اور فوائد کے لین دین اپنی زبان میں درست تاریخ، عدد، اور نام کی فارمیٹنگ کے ساتھ مکمل کر سکتے ہیں، زبان تک رسائی کا قانون پورا کرتے اور غیر اکثریتی زبان بولنے والوں کے لیے انصاف بہتر بناتے ہوئے۔

کاروباری جواز: محرکات، ROI اور TCO

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

TCO پر، اپنانے کی لاگت بین الاقوامی بنانے کی پیشگی انجینئرنگ، جمع جاری ترجمے اور پائپ لائن کی لاگتیں ہیں۔ نہ اپنانے کی لاگت مہنگی دوبارہ لگائی ہے: پورے کوڈ بیس میں ہارڈ کوڈ سٹرنگز، جوڑنے، encoding کے بگز، اور ترتیب کے مفروضے کھولنا، اکثر منڈی یا قانونی تقاضے کی ڈیڈ لائن پر۔ ناقص مقامی کاری کی چھپی لاگتیں بھی ہیں: بری طرح خدمت کی گئی منڈیوں میں کھوئی فروخت، الجھے فارمیٹس سے معاونت کا بوجھ، اور غلط ترجمہ شدہ زیادہ داؤ کے مواد سے قانونی یا ساکھ کا نقصان۔ مسلسل مقامی کاری لانچ سے پہلے مہنگے ترجمے کے دباؤ سے بچاتی ہے۔

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

ضد نمونے اور خامیاں

ہارڈ کوڈ سٹرنگز: کوڈ میں پکا صارف کا متن، فی locale کوڈ کی تبدیلیاں مجبور کرتا ہوا۔
سٹرنگ جوڑنا: ٹکڑوں سے جملے بنانا، جو قواعد اور الفاظ کی ترتیب توڑتا ہے۔
غیر Unicode مفروضے: encoding کے بگز، mojibake (غیر مطابقت والی حروف کی encodings سے بگڑا ہوا متن)، اور رسم الخط ظاہر کرنے میں ناکامی۔
انگریزی متن کی لمبائی فرض کرنا: ترتیب جو ترجمے پر کٹتی یا اوور لیپ ہوتی ہے۔
دائیں سے بائیں نظر انداز کرنا: جسمانی بائیں/دائیں ترتیب استعمال کرنا جو آئینہ نہیں ہو سکتی۔
سادہ جمع سازی: واحد/جمع کی منطق جو زیادہ تر زبانوں میں غلط ہے۔
locale سے بے خبر فارمیٹنگ: ہارڈ کوڈ تاریخ، عدد، اور کرنسی کے فارمیٹس۔
سیاق کے بغیر ترجمہ: مترجمین کا معنی کا اندازہ لگانا، غلطیاں پیدا کرنا۔
بیچ، آخری لمحے کی مقامی کاری: مسلسل پائپ لائن کی بجائے لانچ سے پہلے کا دباؤ۔
ثقافتی بے حسی: تصاویر، رنگ، یا مثالیں جو مقامی طور پر ناگوار یا الجھانے والی ہوں۔

پختگی کا ماڈل

سطح 1: آغاز۔ ایک زبان، ہارڈ کوڈ سٹرنگز، غیر Unicode مفروضے، اور جوڑ کر بنایا متن۔ بین الاقوامیت ردعملی ہے: ہر نئے locale کا مطلب کوڈ بدلنا ہے، اور encoding اور ترتیب کے بگز پروڈکشن میں حادثاتی طور پر ملتے ہیں۔

سطح 2: ترقی۔ کچھ سٹرنگز باہر رکھی گئی ہیں اور کہیں Unicode استعمال ہوتا ہے، مگر عمل ٹیموں میں غیر مستقل ہے۔ مقامی کاری دستی، بیچ، لانچ سے پہلے کی کوشش ہے، اور فارمیٹنگ، جمع کی ہینڈلنگ، اور دائیں سے بائیں معاونت ایک ٹیم سے دوسری میں مختلف طرح (یا بالکل نہیں) سنبھالی جاتی ہیں۔

سطح 3: معیار بندی۔ مشترک i18n فن تعمیر اور locale سے باخبر فارمیٹنگ کی لائبریری دستاویزی، ادارے بھر میں نافذ معیار ہیں۔ سٹرنگ کی بیرونی کاری lint اصولوں سے جانچی جاتی ہے، لغات اور translation memory کے ساتھ ترجمے کے انتظام کا نظام اور مسلسل پائپ لائن موجود ہے، اور pseudo-localisation جمع کثیر locale ٹیسٹنگ (بشمول دائیں سے بائیں اور لمبے متن کا locale) CI میں چلتی ہے۔

سطح 4: انتظام۔ مقامی کاری کا پروگرام بنیادی خطوط کے مقابل ناپا اور کنٹرول کیا جاتا ہے۔ ٹیمیں زبان کی کوریج، مقامی کاری کا معیار اور نقص کی شرحیں، commit سے ترجمہ شدہ ریلیز تک سٹرنگ کی ہم آہنگی کی تاخیر، فی ریلیز پکڑے گئے کٹاؤ اور دائیں سے بائیں rendering کے نقائص، فی locale ترجمے کی لاگت، اور نئے locale کے لانچ کا وقت ٹریک کرتی ہیں، اور یہ میٹرکس ریلیزز کا دروازہ بنتی اور طے کرتی ہیں کہ انسانی ریویو بمقابلہ مشینی ترجمے میں کہاں سرمایہ لگانا ہے۔

سطح 5: ہم آہنگی۔ بین الاقوامیت اور مقامی کاری ادارے بھر میں مسلسل بہتر اور مربوط ہیں۔ مقامی کاری مسلسل ہے، مشینی اور انسانی ترجمہ مواد کی ہر قسم کے لیے دانستہ چنے جاتے ہیں، اور ثقافتی موافقت منظم ہے۔ ادارہ منڈی اور انصاف کی شہادت کے جواب میں locales جوڑتا، ریٹائر کرتا، اور دوبارہ دائرہ بند کرتا ہے، اور نئے locales دوبارہ لگانے کے بغیر تیزی سے اعلیٰ معیار پر لانچ ہوتے ہیں۔

بحث کے لیے خیالات

اگر بین الاقوامی طلب غیر یقینی ہو تو پروڈکٹ کو کتنی جلد بین الاقوامی بنانا چاہیے؟
مشینی ترجمہ کہاں قابل قبول ہے، اور انسانوں کو کہاں ریویو کرنا چاہیے؟
آپ بہت سی زبانوں اور ٹیموں میں اصطلاحات کو مستقل کیسے رکھتے ہیں؟
variant کی دیکھ بھال کے اضافی بوجھ کے مقابل کتنی علاقائی ثقافتی موافقت قابل قدر ہے؟
دائیں سے بائیں اور اقلیتی زبان کی معاونت کو کیسے ترجیح اور ٹیسٹ کیا جائے؟
آپ پائپ لائن سست کیے بغیر مترجمین کو کافی سیاق کیسے دیتے ہیں؟

اہم نکات

فن تعمیر کی بین الاقوامیت ایک بار کریں؛ مواد کی مقامی کاری بار بار۔
ہر جگہ Unicode استعمال کریں، تمام سٹرنگز باہر رکھیں، اور ترجمے کبھی نہ جوڑیں۔
متن کے پھیلاؤ، دائیں سے بائیں رسم الخط، اور locale کے مخصوص جمع اور فارمیٹنگ کے قواعد کی منصوبہ بندی کریں۔
translation memory، لغات، اور سیاق کے ساتھ مسلسل مقامی کاری کی پائپ لائن چلائیں۔
حقیقی ترجمے سے پہلے i18n کے بگز پکڑنے کو CI میں جلد pseudo-localise کریں۔
مقامی کاری ثقافتی ہے، صرف لسانی نہیں۔
جلد بین الاقوامیت دوبارہ لگانے سے کہیں سستی ہے؛ حکومت کے لیے یہ قانونی انصاف کا تقاضا ہے۔

حوالہ جات اور مزید مطالعہ

The Unicode Consortium, The Unicode Standard and Common Locale Data Repository (CLDR)
W3C Internationalisation (i18n) Activity, techniques and best practices
Richard Ishida, W3C internationalisation articles and tutorials
Bert Esselink, A Practical Guide to Localisation
John Yunker, Beyond Borders: Web Globalisation Strategies
Unicode Technical Standard #35 (locale data markup) and ICU library documentation
IETF BCP 47 language tags
Government multilingual service and language-access guidance
Nielsen Norman Group and W3C articles on RTL, text expansion, and localisation UX