بین الاقوامیت و مقامیاندازی

سندھ آئی ٹی پورٹل — سہولت ڈیسک (SITP) کو کس طرح تین زبانوں میں (انگریزی مرجع → اردو → سندھی)، دائیں سے بائیں (RTL) اصل نسل کے طور پر، دوہرے کیلنڈر سے آگاہ، اور ہر سطح — عوامی سائٹ، دستاویزات، اطلاعات، سرکاری خطوط، اور AI پیداوار — پر لغت کے مطابق مستقل انداز میں تیار کیا گیا ہے۔

1. دائرۂ کار اور اس دستاویز کو پڑھنے کا طریقہ

یہ دستاویز SITP میں ہر کثیراللسانی شے کے لیے مستند وصیت ہے۔ اس میں درج ذیل شامل ہیں:

• زبان کی حکمتِ عملی — EN بطورِ مرجع، UR اور SD بطورِ متوازی تراجم (§2)۔
• لوکیل کا ذخیرہ و تعین — فی صارف، فی ادارہ، فی نشست (§3)۔
• سٹرنگ کا بیرونی انداز — کہیں بھی کوئی ہارڈکوڈڈ سٹرنگ نہیں (§4)۔
• ترجمہ فائل کا ورک فلو — فی لوکیل JSON/MDX کیٹلاگز (§5)۔
• AI معاون ترجمہ پائپ لائن + انسانی مقامی نظرثانی (§6، ورک فلو خاکہ کے ساتھ)۔
• لغت پر مبنی اصطلاح کی مستقل مزاجی (§7)۔
• RTL ہینڈلنگ — CSS منطقی خصوصیات، سمت کی تبدیلی، آئیکن/لے آؤٹ mirroring (§8)۔
• ٹائپوگرافی و فونٹس — Inter/Poppins, Noto Nastaliq Urdu, Noto Naskh Arabic (§9)۔
• دوہرا گریگورین + ہجری کیلنڈر (§10)۔
• نمبر، تاریخ، کرنسی، اور فون کی فارمیٹنگ (§11)۔
• مواد کا فال بیک — غائب ترجمہ → نظرِ انداز کے بغیر نشان کے ساتھ EN (§12)۔
• SEO: فی لوکیل hreflang + sitemap (§13)۔
• فی لوکیل قابلِ رسائی — EN/UR/SD پر WCAG 2.1 AA (§14)۔
• ترجمہ QA و نظرثانی گیٹس (§15)۔
• سرکاری اصطلاحات کی تمیز — محکمہ بمقابلہ وزارت، اور دیگر مقفل امتیازات (§16)۔
• فعلی تقاضے، NFRs، صارف کہانیاں، ٹیسٹ کیسز (§17–§20)۔

i18n کا اعلیٰ سطحی پلیٹ فارم معاملہ /specs/ur/15-tech-architecture/ §15 میں موجود ہے؛ یہ دستاویز اس حصے کو ایک مکمل، تیارِ تعمیر وصیت میں پھیلاتی ہے۔ _glossary.md میں تین لسانی اصطلاحی لغت منظور شدہ تراجم کا واحد ماخذ ہے — یہ دستاویز اس بات کی تدبیر کرتی ہے کہ ان تراجم کو کس طرح لاگو کیا جائے، نہ کہ یہ کہ وہ کیا ہیں۔

2. زبان کی حکمتِ عملی اور لوکیل ماڈل

2.1 تین لوکیلز

انگریزی تخلیق کا لوکیل ہے۔ ہر UI سٹرنگ، KB مضامین، سرکولر، SOP، اطلاعات کا ٹیمپلیٹ، سرکاری خط کا ٹیمپلیٹ، اور ای میل/SMS/WhatsApp ٹیمپلیٹ پہلے انگریزی میں تحریر کیا جاتا ہے اور پھر اردو اور سندھی میں بطورِ وفادار متوازی ترجمہ تیار کیا جاتا ہے۔ EN مرجع کے بغیر UR یا SD میں کوئی مواد جاری نہیں ہوتا۔ واحد استثناء شہری کا جمع کردہ آزاد متن ہے، جسے جس زبان میں جمع کنندہ نے لکھا ہو اسی میں لفظاً محفوظ کیا جاتا ہے، اور AI Translation صلاحیت کے ذریعے بہ تقاضا ترجمہ کیا جاتا ہے (§6 دیکھیں)۔

یہ دستاویزات کے سیٹ کے ساتھ بھی مطابقت رکھتا ہے: ہر دستاویز فولڈر میں {en,ur,sd}.md شامل ہے، EN مرجع (_conventions.md §2 دیکھیں)۔ اسی نظم و ضبط کا اطلاق مصنوعات کے مواد پر بھی ہوتا ہے۔

2.2 لوکیل شناخت کنندے

اندرونی طور پر، لوکیل کو ISO 639-1 کوڈ (en, ur, sd) کے ذریعے علاقائی ذیلی ٹیگز کے بغیر پیش کیا جاتا ہے، کیونکہ ہر ایک کے لیے منتخب شدہ قسم پاکستان کا صوبائی معیار ہے۔ جہاں کسی تیسرے فریق کی لائبریری علاقائی ذیلی ٹیگ کی متقاضی ہو (مثلاً en-PK, ur-PK, sd-PK)، تو ذیلی ٹیگ PK صرف اسی تعامل کے لیے شامل کیا جاتا ہے؛ مستند محفوظ قدر برقرار برہنہ دو حرفی کوڈ ہی رہتی ہے۔

2.3 رسمِ خط اور سمت کا تعلق

سمت (ltr یا rtl) لوکیل کا فنکشن ہے، کبھی علیحدہ صارف کی ترتیب نہیں۔ ur یا sd کو منتخب کرنا پورے لے آؤٹ کو RTL پر پلٹ دیتا ہے؛ en کو منتخب کرنا اسے دوبارہ LTR پر لے آتا ہے۔ کوئی "RTL میں انگریزی" یا "LTR میں اردو" موڈ نہیں ہے۔ یہ CSS، لے آؤٹ، اور جزو کے منطق کو سادہ اور قابلِ پیشگوئی رکھتا ہے، اور صارف کی توقعات سے مطابقت رکھتا ہے۔

3. لوکیل کا ذخیرہ و تعین

3.1 لوکیل کہاں محفوظ ہوتا ہے

لوکیل تین جگہوں پر، تعین کی ترتیب کے مطابق محفوظ ہوتا ہے:

| # | ذخیرہ | دائرہ | مقرر کنندہ | نوٹس | |---|---|---|---|---|---| | 1 | URL راہ کا سابقہ (/en/, /ur/, /sd/) | فی درخواست / فی صفحہ | صارف کی نیویگیشن، لوکیل سوئیچر | مستند اور قابلِ اشتراک۔ عوامی صفحات پر ہمیشہ موجود۔ | | 2 | usr_user.locale کالم | فی صارف | صارف، رجسٹریشن پر یا پروفائل/ترجیحات کے مرکز کے ذریعے | تصدیق شدہ نشستوں کے لیے طے شدہ جب کوئی URL سابقہ نہ ہو۔ | | 3 | org_organization.default_locale کالم | فی ادارہ (کمپنی یا محکمہ) | ادارہ ایڈمن | فال بیک جب صارف کا کوئی صریح لوکیل نہ ہو (مثلاً نئے مدعو عملے کے لیے)۔ |

گمنام زائرین لوکیل حاصل کرتے ہیں: (a) صریح URL سابقہ، ورنہ (b) Accept-Language ہیڈر جو [en, ur, sd] کے خلاف بحث و توافق ہوتا ہے، ورنہ (c) en (مرجع)۔ تعین شدہ لوکیل کو فرسٹ پارٹی کوکی (sitp_locale) میں محفوظ کیا جاتا ہے تاکہ آنے والی ملاقاتیں ثابت قدم رہیں، لیکن URL سابقہ ہمیشہ فوقیت رکھتا ہے — یہ ڈیپ لنکس کو قابلِ اشتراک اور غیر مبہم رکھتا ہے۔

3.2 لوکیل کیسے پھیلتا ہے

ایک بار کنارے پر تعین ہونے کے بعد، لوکیل ہر ضروری جگہ تک پھیل جاتا ہے، بغیر صارف کو دوبارہ اکسانے کے:

• JWT / OIDC ٹوکن: لوکیل ایک دعویٰ (claim) ہے، اس لیے ہر تصدیق شدہ API کال اسے اپنے ساتھ رکھتا ہے۔
• جاب پے لوڈز: ہر BullMQ جاب (اطلاعات، ایکسپورٹس، AI کالز) میں locale شامل ہوتا ہے، اس لیے اردو لوکیل صارف کے لیے بنائی گئی اطلاع اردو میں بنائی جاتی ہے چاہے جاب کئی منٹ بعد کسی ورکر کے ذریعے پروسیس ہو جس نے اصل درخواست کبھی نہ دیکھی ہو۔
• درخواست کا سیاق و سباق: NestJS کا LocaleInterceptor (/specs/ur/15-tech-architecture/ §4 دیکھیں) لوکیل کو ایسینک درخواست کے سیاق و سباق سے جوڑتا ہے؛ ہر سروس اسے وہیں سے پڑھتی ہے نہ کہ ہر کال میں گزرے پیرامیٹر سے۔
• ٹیمپلیٹس: اطلاعات، خطوط، اور دستاویز کے ٹیمپلیٹس لوکیل وصول کرتے ہیں اور درست متغیر کو رینڈر کرتے ہیں۔
• تلاش: Meilisearch کے استفسارات صارف کا لوکیل اپنے ساتھ رکھتے ہیں تاکہ یکساں زبان کے مطالبات کو اعلیٰ درجہ ملے (/specs/ur/15-tech-architecture/ §8 دیکھیں)۔
• AI کالز: FastAPI سروس کو ہر AI درخواست میں locale + target_locales شامل ہوتے ہیں تاکہ ترجمہ، خلاصہ، اور مسودہ جواب کی پیداوار درست زبان میں اتریں۔

3.3 لوکیل سوئچنگ

ہر صفحہ (عوامی سائٹ، دستاویزات، پورٹل ایپ، موبائل PWA) کے ہیڈر میں ایک مرئی لوکیل سوئیچر موجود ہے۔ لوکیل بدلنے سے:

1. حالیہ URL کو ہدف لوکیل کے سابقہ میں دوبارہ لکھا جاتا ہے۔
2. sitp_locale کوکی اپ ڈیٹ ہوتی ہے۔
3. اگر تصدیق شدہ ہو تو نئے لوکیل کو usr_user.locale میں محفوظ کیا جاتا ہے (تاکہ یہ آلات کے درمیان ثابت قدم رہے)۔
4. صفحہ نئے لوکیل اور سمت میں، جہاں ممکن ہو بغیر مکمل ری لوڈ کے دوبارہ رینڈر ہوتا ہے (Next.js App Router اس کی مقامی طور پر تائید کرتا ہے)۔

سوئیچر کبھی صارف کی جگہ کو ضائع نہیں کرتا: وہی راستہ، وہی ٹکٹ، وہی KB مضمون — محض دوسری زبان میں۔

3.4 عملے کے لیے فی ادارہ طے شدہ

سرکاری عملہ (افسران، سیکشن ہیڈز، ناظرین) عموماً اپنے محکمے کے طے شدہ لوکیل میں کام کرتے ہیں، جو کسی شہری کی ترجیحی لوکیل سے مختلف ہو سکتا ہے۔ جب کوئی افسر کسی اردو لوکیل والی کمپنی کا داخل شدہ ٹکٹ دیکھتا ہے، تو نظام کا chrom (مینوز، بٹن، صورتحالت کے لیبل) افسر کے لوکیل میں رینڈر ہوتا ہے، جبکہ ٹکٹ کا مواد (عنوان، تفصیل، پیغامات) مصنف کے اصل لوکیل میں دکھایا جاتا ہے ساتھ ہی بہ تقاضا "ترجمہ" کی سہولت (§6 دیکھیں)۔ یہ علیحدگی ایک سندھی بولنے والے افسر کو اردو chrom پڑھنے پر مجبور ہونے سے روکتی ہے، اور اسی کا الٹا، جبکہ اصل ریکارڈ کی سالمیت برقرار رکھتی ہے۔

4. سٹرنگ کا بیرونی انداز (کوئی ہارڈکوڈڈ سٹرنگ نہیں)

4.1 قاعدہ

کوئی صارف کو نظر آنے والی سٹرنگ کبھی سورس کوڈ میں ہارڈکوڈ نہیں کی جاتی۔ ہر لیبل، بٹن، ٹول ٹپ، خامی کا پیغام، صورتحالت کا نام، ای میل کا موضوع، SMS کا متن، پلیس ہولڈر، aria-label، ٹوسٹ، خالی حالت، اور توثیق کا پیغام ایک میسج کیٹلاگ میں رہتا ہے جو ایک مستند شناخت کنندے کے ذریعے کلیدی (keyed) ہے۔ اجزاء کلید کا حوالہ دیتے ہیں؛ رن ٹائم کلید کو فعلی لوکیل کی سٹرنگ میں حل کرتا ہے۔

یہ درج ذیل پر لاگو ہوتا ہے:

• Next.js پورٹل (UI سٹرنگز)۔
• Docusaurus دستاویزاتی سائٹ (سائیڈبار لیبلز، نیوبار، فوٹر، تھیم سٹرنگز — Docusaurus کا اپنا i18n)۔
• NestJS API جوابات (توثیق کی خامیاں، صارفین کو رینڈر کی گئی صورتحالت enums، جب نتیجہ پیغامات)۔
• اطلاعات کے ٹیمپلیٹس (ای میل، SMS، WhatsApp، اطلاعِ ان ایپ)۔
• سرکاری دستاویز کے ٹیمپلیٹس (خطوط، سرٹیفکیٹس)۔
• پیدا کردہ PDF/Excel ایکسپورٹس (ہیڈرز، کالم لیبلز، فوٹرز)۔

4.2 نافذکاری

ہارڈکوڈنگ کو درج ذیل کے امتزاج سے روکا جاتا ہے:

• لنٹ قاعدہ (no-hardcoded-strings): ایک ESLint مخصوص قاعدہ جو کسی بھی سٹرنگ literal کو جو JSX چائلڈ، placeholder، aria-label، title، یا alt attribute کو دی گئی ہو، اس وقت پر جھنڈا لگاتا ہے جب تک کہ وہ t() ترجمہ فنکشن میں لپٹی نہ ہو۔ استثنائات صریح طور پر اجازت نامہ فہرست میں ہیں (مثلاً خالص دکھائی دینے والے مستقل جیسے ٹکٹ ID فارمیٹس)۔
• CI گیٹ: لنٹ قاعدہ CI میں چلتا ہے؛ خلاف ورزی بلڈ کو ناکام کرتی ہے۔
• کوڈ نظرثانی چیک لسٹ: نظرثانی کنندگان تصدیق کرتے ہیں کہ نئی سٹرنگز کلیدی ہیں۔
• کلید کا جائزہ: ایک ہفتہ وار جاب ان کیٹلاگ کلیدوں کی رپورٹ دیتا ہے جو کوڈ میں حوالہ دی گئی ہوں مگر ایک یا زیادہ لوکیل فائلز میں غائب ہوں (فال بیک رویے کے لیے §12 اور QA کے لیے §15 دیکھیں)۔

4.3 توسیع و جمع (interpolation) و جمع بندی (pluralization)

سٹرنگز درج ذیل کے لیے ICU MessageFormat کی تائید کرتی ہیں:

• توسیع: Hello, {name} → السلام علیکم، {name}۔
• جمع بندی: {count, plural, =0 {No tickets} one {# ticket} other {# tickets}}۔
• انتخاب (جہاں ضروری ہو صنف/رسمیت): اس مصنوعات میں نایاب؛ سرکاری خطوط میں خطاب کے لیے مخصوص ہے۔

جمع بندی کے قوانین لوکیلز کے درمیان مختلف ہوتے ہیں (انگریزی میں one/other؛ عربی رسمِ خط کے لوکیلز میں zero/one/two/few/many/other)۔ message-format لائبریری اسے سنبھالتی ہے؛ مترجمین فی کلید تمام مطلوبہ جمع شکلیں فراہم کرتے ہیں۔

5. ترجمہ فائل کا ورک فلو

5.1 کیٹلاگ کا ڈھانچہ

UI سٹرنگز فی لوکیل میسج کیٹلاگز میں رہتی ہیں، فیچر سطح کے مطابق منظم تاکہ فائلیں قابلِ نظرثانی رہیں:

locales/
  en/
    common.json
    auth.json
    tickets.json
    notifications.json
    letters.json
    dashboard.json
    errors.json
    ...
  ur/
    common.json
    auth.json
    ...
  sd/
    common.json
    auth.json
    ...

ہر کیٹلاگ ایک ہموار JSON آبجیکٹ ہے جو مستند نقطہ دار شناخت کنندوں سے کلیدی ہے:

{
  "tickets.status.new": "New",
  "tickets.status.resolved": "Resolved",
  "tickets.emptyState.title": "No tickets yet",
  "tickets.emptyState.body": "File your first ticket to get started."
}

کلیدزیں فیچر کے مطابق نام اسپیس میں ہیں (tickets., auth., letters., …) اور ایک دفعہ جاری ہونے کے بعد کبھی نام تبدیل نہیں ہوتے — کسی کلید کا نام بدلنا جاری تراجم کو توڑ دیتا ہے۔ پرانی کلیدز کو متروک قرار دیا جاتا ہے، حذف نہیں، یہاں تک کہ کوئی کوڈ ان کا حوالہ نہ دے اور تینوں لوکیلز انہیں چھوڑ دیں۔

5.2 طویل فارمیٹ مواد (MDX)

طویل فارمیٹ مواد — KB مضامین، سرکولرز، SOPs، دستاویزاتی سائٹ کے صفحات خود — فی لوکیل MDX کے طور پر تحریر کیا جاتا ہے JSON کے بجائے، کیونکہ مواد نثر، اجزاء، اور میڈیا کا ملغوتہ ہے۔ دستاویزاتی سیٹ کی طرح کی فائل و فولڈر روایت لاگو ہوتی ہے: ہر مواد شے ایک فولڈر ہے جس میں en.mdx, ur.mdx, sd.mdx ہیں۔ فرنٹ میٹر میں لوکیل، آخری ترجمہ وقت، جس EN مراجعہ سے ترجمہ کیا گیا، اور نظرثانی کی صورت (§6 دیکھیں) شامل ہوتی ہے۔

5.3 فی لوکیل JSON/MDX ہم آہنگی

ہر فیچر ریلیز کے لیے:

1. EN کیٹلاگز اور MDX اپ ڈیٹ ہوتے ہیں۔
2. ایک ڈِف تیار کیا جاتا ہے: نئی کلیدز، تبدیل شدہ کلیدز، حذف شدہ کلیدز۔
3. UR اور SD کیٹلاگز اپ ڈیٹ ہوتے ہیں (پہلے AI معاون، پھر انسانی نظرثانی — §6 دیکھیں)۔
4. ایک ہم آہنگی چیک CI میں چلتا ہے: en/*.json میں موجود ہر کلید ur/*.json اور sd/*.json میں بھی موجود ہونی چاہیے۔ غائب کلیدز بلڈ کو ناکام کرتی ہیں (ایک صریح فیصلے پر مجبور کرتے ہوئے: ابھی ترجمہ کریں، یا دانستہ طور پر EN فال بیک کے طور پر نشان زد کریں ایک ٹریکڈ قرض شے کے ساتھ)۔

5.4 فی مواد شے صورتحالت کی ٹریکنگ

ہر قابلِ ترجمہ شے (فی فیچر UI کلید سیٹ، KB مضمون، SOP، خط ٹیمپلیٹ) ایک ترجمہ صورتحالت رکھتی ہے:

صورتحالت فی لوکیل فی شے محفوظ ہوتی ہے اور ترجمہ ڈیش بورڈ میں دکھائی دیتی ہے (§15 دیکھیں)۔

6. AI معاون ترجمہ پائپ لائن + انسانی مقامی نظرثانی

6.1 پائپ لائن کا جائزہ

EN میں تحریر کردہ مصنوعات کو UR اور SD میں ہائبرڈ پائپ لائن کے ذریعے ترجمہ کیا جاتا ہے: AI پہلا پاس کرتا ہے (تیز، سستا، مستقل)، ایک مقامی انسانی نظرثانی کنندہ آخری پاس کرتا ہے (درستگی، اندازِ بیان، ثقافتی مطابقت، اصطلاحات)۔ UR یا SD میں کچھ بھی محض AI پیداوار پر جاری نہیں ہوتا۔ یہ وہی AI Translation صلاحیت ہے جو /specs/ur/07-ai-ocr-spec/ اور /specs/ur/15-tech-architecture/ §6.3 #6 میں بیان ہوئی، لغت کے ذریعے محدود۔

6.2 ورک فلو خاکہ

6.3 ورک فلو کی تحریری وضاحت

مصنوعات کا مواد انگریزی میں تحریر کیا جاتا ہے (UI کیٹلاگ اندراج، KB MDX فائل، خط ٹیمپلیٹ، یا اطلاع ٹیمپلیٹ)۔ ایک ڈِفر نئے EN مراجعہ کا موازنہ پہلے ترجمہ شدہ EN مراجعہ سے کرتا ہے اور تین بالٹیں خارج کرتا ہے: نئی سٹرنگز (کبھی ترجمہ نہ ہوئیں)، تبدیلی شدہ سٹرنگز (EN آخری ترجمہ کے بعد ترمیم شدہ — stale کے طور پر نشان زد)، اور حذف شدہ سٹرنگز (لوکیل کیٹلاگ سے ہٹائیں)۔

نئی اور تبدیل شدہ اشیاء کے لیے، لغت کی پابندیاں اصطلاحاتی ڈیٹا بیس سے لوڈ کی جاتی ہیں (جو خود _glossary.md سے ماخوذ ہے — §7 دیکھیں) اور مجبور تراجم اور ممنوع میپنگز کے طور پر AI کال میں داخل کی جاتی ہیں۔ AI ترجمہ پاس فی ہدف لوکیل (ur، پھر sd) پلگ ایبل LLM کے ذریعے چلتا ہے (/specs/ur/15-tech-architecture/ §6.1 دیکھیں)، ایک مسودہ پیدا کرتا ہے جو پہلے ہی منظور شدہ اصطلاحات کا احترام کرتا ہے۔

مسودہ ایک فی لوکیل نظرثانی قطار میں اترتا ہے۔ ایک مقامی انسانی نظرثانی کنندہ (UR کے لیے اردو مادری، SD کے لیے سندھی مادری — کبھی دونوں کے لیے ایک ہی شخص نہیں، کبھی غیر مادری بولنے والا نہیں) مسودہ کو EN مرجع اور لغت کے ساتھ کھولتا ہے، اور چار باتوں کی پڑتال کرتا ہے: (1) درستگی — کیا یہ وہی کہتا ہے جو EN کہتا ہے؛ (2) اندازِ بیان — کیا رسمیت سرکاری رو بہ رو مصنوعات کے لیے درست ہے؛ (3) اصطلاحات — کیا لغت کی اصطلاحات بالکل منظور شدہ کے مطابق استعمال ہوئی ہیں، محکمہ بمقابلہ وزارت کے امتیاز (§16) کے ساتھ برقرار؛ (4) RTL مطابقت — کیا سٹرنگ ہدف فونٹ میں دائیں سے بائیں رینڈر ہونے پر فطری پڑھی جاتی ہے، بغیر ٹوٹے دو طرفہ ملغوتہ کے۔ نظرثانی کنندہ یا تو منظور کرتا ہے یا اِن لائن ترمیم کرتا ہے؛ ترامیم کو AI مسودہ کے خلاف ڈِف کے طور پر ٹریک کیا جاتا ہے۔

منظوری پر، سٹرنگ کو لوکیل کیٹلاگ میں شائع کیا جاتا ہے اور وہ جاری ہو جاتی ہے۔ نظرثانی کنندہ کی اصلاحات کو واپس AI ٹیوننگ سیٹ (EN→UR اور EN→SD جوڑوں کا ایک منتخب کردہ کارپس جس میں نظرثانی کنندہ کی منظور شدہ پیداوار ہو) میں کھلایا جاتا ہے، جو مستقبل میں AI کے پہلے پاس کے معیار کو بہتر بناتا ہے اور وقت کے ساتھ نظرثانی کنندہ کا بوجھ کم کرتا ہے۔ اشیاء جو ابھی ترجمہ نہیں ہوئیں UI میں ایک مرئی نشان کے ساتھ انگریزی پر فال بیک کرتی ہیں (§12 دیکھیں)، اس لیے مصنوعات کبھی ترجمے پر بلاک نہیں ہوتی — مگر یہ فرق ٹریک ہوتا ہے اور اگلے نظرثانی چکر میں بند ہو جاتا ہے۔

6.4 صارف مواد کا بہ تقاضا ترجمہ

یہی پائپ لائن، مگر انسانی گیٹ کے بغیر، صارف کے جمع کردہ آزاد متن — ٹکٹ تفصیلات، چیٹ پیغامات، MoM اپ لوڈز، آنے والے ای میل/SMS/WhatsApp جوابات — کے لیے بہ تقاضا چلتا ہے۔ کوئی افسر جو انگریزی لوکیل نشست میں کسی اردو ٹکٹ کو دیکھ رہا ہے "ترجمہ" کلک کرتا ہے؛ AI اِن لائن ایک EN رینڈرنگ لوٹاتا ہے، واضح طور پر مشین ترجمہ کے طور پر لیبل زد، اصل محفوظ رکھی گئی۔ اصل ریکارڈ ہے؛ ترجمہ ایک سہولت ہے۔ سرکاری دستاویزات (قرارداد سرٹیفکیٹس، خطوط) کے لیے، انسانی نظرثانی شدہ کیٹلاگ تراجم استعمال ہوتے ہیں، کبھی خام AI پیداوار نہیں۔

6.5 نظرثانی کنندگان کی فہرست

نظرثانی کنندگان کو مادری زبان کی ضرورت کے مطابق شامل کیا جاتا ہے: اردو نظرثانی کنندگان اردو مادری ہوتے ہیں (عموماً سندھ میں مقیم، پاکستانی سرکاری اندازِ بیان سے واقف)؛ سندھی نظرثانی کنندگان سندھی مادری ہوتے ہیں۔ نظرثانی کنندگان کو ٹریننگ و سرٹیفکیشن ماڈیول (O) کے تحت جاری دستاویزات سے نمٹنے سے پہلے امتحان سے گزرے "Native Reviewer" سرٹیفکیشن کے ذریعے معتبر کیا جاتا ہے — عملے کی سرٹیفکیشن کے نمونے کی عکاسی۔ حساس مواد (سرکاری خطوط، قانونی/RTI الفاظ) کے لیے فی لوکیل کم از کم دو نظرثانی کنندگان تکثر اور باہمی چیک کے لیے رکھے جاتے ہیں۔

7. لغت پر مبنی اصطلاح کی مستقل مزاجی

7.1 لغت بطورِ معاہدہ

_glossary.md SITP کے لیے مستند تین لسانی اصطلاح لغت ہے۔ ہر سرکاری، قانونی، ٹکٹنگ، کردار، تکنیکی، اور مخفف اصطلاح کا ایک منظور شدہ EN/UR/SD رینڈرنگ ہے۔ مترجمین، نظرثانی کنندگان، اور AI ترجمہ پائپ لائن کو ان رینڈرنگز کا بالکل استعمال کرنا چاہیے؛ انحراف ایک عیب ہے جو QA میں پکڑا جاتا ہے (§15 دیکھیں)۔

7.2 مارک ڈاؤن سے استفسار کے قابل اصطلاحاتی DB تک

مارک ڈاؤن لغت انسان کے پڑھنے کے قابل ماخذ ہے۔ ایک بلڈ مرحلہ اسے ایک اصطلاحاتی ڈیٹا بیس (انگریزی اصطلاح سے کلیدی JSON نقشہ، ur, sd, definition, اور notes فیلڈز کے ساتھ) میں مرتب کرتا ہے جو:

• AI ترجمہ پائپ لائن پابندیوں کے طور پر لوڈ کرتا ہے (جانچی ہوئی اصطلاحات کے لیے مجبور تراجم؛ عام غلطیوں کے لیے ممنوع میپنگز)۔
• QA لنٹر مکمل شدہ تراجم کا موازنہ کرتا ہے (ہر جگہ جھنڈا لگاتا ہے جہاں "Department" کو وزارت رینڈر کیا گیا — §16 دیکھیں)۔
• نظرثانی کنندہ ورک بینچ اِن لائن دکھاتا ہے تاکہ نظرثانی کنندہ منظور شدہ اصطلاح مسودہ کے ساتھ دیکھے۔
• دستاویز بلڈ UR/SD دستاویز تراجم کی میچنگ تصدیق کے لیے استعمال کرتا ہے۔

7.3 لغت کی نمو

جب کوئی دستاویز یا ترجمہ ایسی اصطلاح متعارف کرے جو لغت میں نہ ہو، تو روایت (_conventions.md §2 دیکھیں) یہ ہے کہ پہلے اسے لغت میں شامل کریں، پھر منظور شدہ ترجمہ ہر جگہ استعمال کریں۔ لغت اس لیے ایک زندہ شے ہے؛ اس میں تبدیلیاں ورژنڈ اور تمام فعال نظرثانی کنندگان کو نشر کی جاتی ہیں تاکہ وہ جاری تراجم کی نئی اصطلاح کے خلاف دوبارہ پڑتال کریں۔

7.4 CI میں مستقل مزاجی کی چیکس

ایک اصطلاحاتی لنٹر ہر لوکیل کیٹلاگ اور MDX فائل پر CI میں چلتا ہے:

• لغت کی اصطلاحات کے غیر منظور شدہ رینڈرنگز کا پتہ لگاتا ہے۔
• ایک ہی EN اصطلاح کے دو فائلوں میں غیر مستقل تراجم کا پتہ لگاتا ہے (ایک ہی انگریزی لفظ دو کیٹلاگز میں دو مختلف طریقوں سے ترجمہ)۔
• ممنوع میپنگز کا پتہ لگاتا ہے (مثلاً Department → وزارت)۔
• نتائج کو بلڈ وارننگز (نرم عدم استقلال کے لیے) یا بلڈ ناکامیاں (ممنوع میپنگز کے لیے) کے طور پر رپورٹ کرتا ہے۔

8. RTL ہینڈلنگ

8.1 سمت بطورِ لے آؤٹ پریمیٹو

اردو اور سندھی دائیں سے بائیں رینڈر ہوتی ہیں۔ RTL ایک CSS بعد کا قدم نہیں ہے؛ یہ لے آؤٹ کا ایک فرسٹ کلاس بُعد ہے جو تین میکانزمز کے مل کر کام کرنے سے سنبھالا جاتا ہے۔

8.2 میکانزم 1 — dir attribute

دستاویز کا <html> عنصر en کے لیے dir="ltr" اور ur اور sd کے لیے dir="rtl" رکھتا ہے۔ Docusaurus اسے لوکیل سے خود بخود مرتب کرتا ہے؛ Next.js پورٹل اسے روٹ لے آؤٹ پر تعین شدہ لوکیل سے مرتب کرتا ہے۔ dir attribute ہر اولاد تک سرایت کرتا ہے، اس لیے پورا جزو درخت بغیر کسی فی جزو کام کے پلٹ جاتا ہے۔ lang attribute متوازی طور پر مرتب کیا جاتا ہے (lang="en", lang="ur", lang="sd") اسکرین ریڈرز اور سرچ انجنز کے لیے (§14 دیکھیں)۔

8.3 میکانزم 2 — CSS منطقی خصوصیات

تمام لے آؤٹ CSS منطقی خصوصیات کا استعمال کرتا ہے طبیعی کی بجائے، اس لیے ایک ہی اصول دونوں سمتوں میں کام کرتا ہے:

TailwindCSS (مقفل اسٹیک) اپنی ps-/pe-/ms-/me-/start-/end- یوٹیلیٹیز اور rtl:/ltr: متغیر modifier کے ذریعے منطقی خصوصیات کی تائید کرتا ہے ان نایاب کیسز کے لیے جہاں لفظی mirror ضروری ہو۔ ٹیم منطقی یوٹیلیٹیز پر معیار قائم رکھتی ہے؛ طبیعی pl-/pr-/ml-/mr- کو صریح جواز کے بغیر لنٹ جھنڈا لگاتا ہے۔

8.4 میکانزم 3 — آئیکن اور لے آؤٹ mirroring

سمتی آئیکنز RTL میں mirror ہوتے ہیں: ایک "واپس" تیر جو LTR میں بائیں کی طرف اشارہ کرتا ہے RTL میں دائیں کی طرف اشارہ کرتا ہے؛ ایک "اگلا" شیورون پلٹتا ہے؛ ایک سائیڈبار جو LTR میں بائیں جانب پن ہو RTL میں دائیں جانب پن ہوتا ہے۔ یہ درج ذیل کے ذریعے سنبھالا جاتا ہے:

• ایک <Icon dir="auto" /> ریپر جو افقی مخصوص آئیکنز کو جب وراثت میں ملنے والی سمت RTL ہو پلٹ دیتا ہے۔ آئیکنز جو واقعی غیر سمتی ہیں (play, expand, list-bullet) کو data-no-mirror سے نشان زد کیا جاتا ہے اور ویسے ہی رکھا جاتا ہے۔
• لے آؤٹ سطح کا mirroring flexbox flex-row (جو dir کا خود بخود احترام کرتا ہے) کے ذریعے مطلق پوزیشننگ کے بجائے۔
• صریح rtl: Tailwind متغیر ان چند کیسز کے لیے جہاں لفظی mirror درکار ہو (مثلاً ایک مخصوص avatar overlap)۔

8.5 دو طرفہ متن کا ملغوتہ

جب اردو یا سندھی متن میں embedded Latin ہو (ٹکٹ IDz جیسے SITP-2026-LBR-000123، مخففات جیسے SECP، نمبرز، URLs)، Unicode Bidirectional Algorithm رینڈرنگ سنبھالتا ہے۔ حدود پر spill-over خامیوں سے بچنے کے لیے، ٹیم embedded LTR رنز کو <bdi> میں لپٹاتی ہے اور صارف کے جمع کردہ مواد فیلڈز پر dir="auto" استعمال کرتی ہے تاکہ براؤزر پہلے مضبوط سمتی حرف سے سمت چنے۔ ٹکٹ IDz، CNICs، اور NTNs ہمیشہ RTL نثر کے اندر بھی LTR رینڈر ہوتے ہیں، ایک صریح <span dir="ltr"> ریپر کے استعمال سے۔

8.6 RTL نہیں کیا ہے

RTL ایک علیحدہ ڈیزائن یا علیحدہ جزو درخت نہیں ہے۔ ایک ڈیزائن نظام ہے (/specs/ur/16-branding-design-system/ دیکھیں) جو دو سمتوں میں رینڈر ہوتا ہے۔ کوئی Component.ltr.tsx اور Component.rtl.tsx فائلیں نہیں ہیں۔ چند استثنائات (ایک آئیکن جس کا mirror نہ ہونا ضروری ہو، ایک ہیرو خاکہ جس میں embedded سمعی معنی ہو) کو نشان زد کیا جاتا ہے اور انفرادی طور پر نظرثانی کی جاتی ہے۔

9. ٹائپوگرافی و فونٹس

9.1 مقفل فونٹ اسٹیک

_context.md §7 کے مطابق:

9.2 لوڈنگ حکمتِ عملی

فونٹس سیلف ہوسٹڈ ہیں (رن ٹائم پر Google Fonts سے نہیں لوڈ کیے جاتے، رازداری اور کارکردگی کے لیے) اور فی لوکیل subset کیے جاتے ہیں:

• کسی دیے گئے صفحہ پر صرف فعلی لوکیل کا فونٹ کنبہ لوڈ ہوتا ہے۔ /ur/... پر کوئی زائرِ Inter ڈاؤن لوڈ نہیں کرتا؛ /en/... پر کوئی زائرِ Noto Nastaliq Urdu ڈاؤن لوڈ نہیں کرتا۔
• ہر فونٹ کو unicode-range subsets میں تقسیم کیا جاتا ہے اور font-display: swap کے ساتھ woff2 کے طور پر پیش کیا جاتا ہے تاکہ متن فوراً فال بیک میں رینڈر ہو اور دستیاب ہونے پر web font میں تبدیل ہو جائے۔
• Preload ہنٹس صرف مروجہ above-the-fold subset کے لیے خارج کیے جاتے ہیں۔

9.3 لائن ہائیٹ اور عمودی تال

Nastaliq (اردو) اور Naskh (سندھی) رسمِ خطوط کو لاطینی متن سے لمبی لائن ہائیٹ درکار ہے — Nastaliq بالخصوص بڑا عمودی احاطہ رکھتا ہے (descenders اور stacked diacritics)۔ ڈیزائن نظام فی لوکیل لائن ہائیٹ اور letter-spacing ٹوکنز فراہم کرتا ہے: EN ٹوکنز طے شدہ طور پر ~1.5 لائن ہائیٹ؛ UR ٹوکنز ~2.0؛ SD ٹوکنز ~1.8۔ یہ lang attribute سے کلیدی CSS متغیرات کے ذریعے لاگو ہوتے ہیں، فی جزو override کے ذریعے نہیں۔

9.4 فونٹ سائزز اور قابلِ پڑہائی

اردو اور سندھی ایک ہی فونٹ سائز پر لاطینی سے طبیعی طور پر چھوٹی رینڈر ہوتی ہیں، رسمِ خط کی جیومیٹری کی وجہ سے۔ ڈیزائن نظام ایک فی لوکیل فونٹ سائز اسکیلنگ فیکٹر لاگو کرتا ہے (UR/SD کا باڈی متن ایک ہی بصری درجہ بندی سطح پر EN سے ~10–15% بڑا ہے) تاکہ بصری قابلِ پڑہائی زبانوں کے درمیان مستقل رہے۔

10. دوہرا کیلنڈر نظام (گریگورین + ہجری)

10.1 سرکاری روایت

_context.md §2 کے مطابق، SITP گریگورین اور ہجری دونوں تاریخیں ہر جگہ دکھاتا ہے — پاکستان سرکاری خط و کتابت کی روایت۔ جہاں بھی کوئی تاریخ صارف کو دکھائی جاتی ہے (ٹکٹ کی بنیادی تاریخ، SLA آخری تاریخ، MoM مٹنگ کی تاریخ، سرکاری خط کی تاریخ، اطلاع کا timestamp)، دونوں کیلنڈر ظاہر ہوتے ہیں، گریگورین بنیادی اور ہجری اس کے ساتھ یا نیچے ماخوذ۔

10.2 ذخیرہ بمقابلہ پیشکش

• ذخیرہ: ہر timestamp UTC گریگورین کے طور پر محفوظ ہوتا ہے (MariaDB میں DATETIME(6) — /specs/ur/15-tech-architecture/ §5.3 دیکھیں)۔ ہجری کبھی سچائی کے سرچشمہ کے طور پر محفوظ نہیں ہوتا؛ یہ ہمیشہ ماخوذ ہوتا ہے۔
• پیشکش: ایک لوکیل آگاہ فارمیٹر محفوظ UTC لمحے کو (a) صارف کے لوکیل فارمیٹ میں گریگورین، اور (b) Umm al-Qura یا مساوی فلکیاتی تبدیلی کے ذریعے ہجری میں رینڈر کرتا ہے، پاکستان کے چاند دیکھنے کے لیے موافق جہاں سرکاری تاریخیں مختلف ہوں (اعلان کردہ عوامی چھٹیوں کے لیے ایک محفوظ override ٹیبل کے ذریعے سنبھالا)۔
• ٹائم زون: پیشکش Asia/Karachi (PKT, UTC+5) میں تبدیل کی جاتی ہے۔

10.3 تاریخ پکرز

پورٹل میں ہر تاریخ پیکر (SLA آخری تاریخ override، مٹنگ شیڈولر، رپورٹ تاریخ حد فلٹر، چھٹی کیلنڈر ایڈیٹر) دوہری ان پٹ پیش کرتا ہے: صارف گریگورین تاریخ چنتا ہے اور متعلقہ ہجری تاریخ اس کے ساتھ دکھائی جاتی ہے (اور اسی کا الٹا — ہجری تاریخ چننا گریگورین کو واپس حساب دیتا ہے)۔ دونوں قدریں بیک اینڈ تک جاتی ہیں؛ گریگورین مستند ہے۔

10.4 چھٹی کیلنڈر

سندھ کا عوامی چھٹی کیلنڈر (SLA کے روکنے کے لیے استعمال، _context.md §5 کے مطابق) ہر چھٹی کے لیے گریگورین اور ہجری دونوں تاریخیں رکھتا ہے، کیونکہ اسلامی چھٹیاں ہجری سے تعریف شدہ ہیں (Eid, Ashura, Eid Milad-un-Nabi) جبکہ شہری چھٹیاں گریگورین سے تعریف شدہ ہیں (یومِ آزادی، یومِ مزدور)۔ SLA انجن گریگورین normal شدہ شکل استعمال کرتا ہے۔

11. نمبر، تاریخ، کرنسی و فون فارمیٹنگ

تمام فارمیٹنگ ایک واحد لوکیل آگاہ فارمیٹر سے گزرتی ہے (Intl پر مبنی، حل شدہ لوکیل سے مرتب)۔ کوئی فارمیٹ سٹرنگ ہاتھ سے نہیں بنائی جاتی۔

11.1 عددی پالیسی

پاکستان عموماً اردو اور سندھی نثر میں مشرقی عربی ہندسے (۰۱۲۳۴۵۶۷۸۹) استعمال کرتا ہے، مگر تکنیکی/ڈیٹا سیاق میں لاطینی ہندسے۔ SITP کا طے شدہ نثر میں UR/SD کے لیے مشرقی عربی، ڈیٹا کثیر UI میں لاطینی (ٹیبلز، ڈیش بورڈز، ٹکٹ IDz، SLA کاؤنٹ ڈاؤنز) ہے، قابلِ پڑہائی اور analytics ایکسپورٹس کے ساتھ استقلال کے لیے۔ عددی متغیر ایک فی لوکیل ٹوکن ہے جسے Super Admin ترتیب دے سکتا ہے، اس لیے کوئی محکمہ جو سب لاطینی پسند کرتا ہے وہ بدل سکتا ہے۔

11.2 فون فارمیٹنگ

فون نمبرز E.164 (+92...) میں محفوظ ہوتے ہیں، ان پٹ پر توثیق شدہ، اور PK آگاہ فارمیٹر کے ذریعے رینڈر ہوتے ہیں۔ CNIC اور NTN فارمیٹس اپنے سرکاری نمونوں کی پیروی کرتے ہیں (CNIC: XXXXX-XXXXXXX-X؛ NTN: 7 ہندسے) اور RTL لوکیلز میں بھی ہمیشہ LTR رینڈر ہوتے ہیں، <span dir="ltr"> میں لپٹے۔

11.3 کرنسی

تمام کرنسی PKR (پاکستانی روپیہ) ہے۔ پورٹل غیر ملکی کرنسی مقامی طور پر نہیں سنبھالتا؛ IT انڈسٹری فائدہ اٹھانے والے سیاق گھریلو ہے۔ کرنسی integer minor یونٹس (paisa) کے طور پر محفوظ ہے اور پیشکش پر فارمیٹ ہوتی ہے۔

12. مواد کی فال بیک حکمتِ عملی

12.1 قاعدہ

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

12.2 مرئی نشان

ایک غائب کلید کا حل اس طرح رینڈر ہوتا ہے:

• انگریزی سٹرنگ، ایک ہلکے بصری علاج میں (ایک پتلی نقطہ دار underline، یا کونے میں ایک چھوٹا "EN" بیج، صارف کی قابلِ رسائی ترتیبات کے ذریعے configurable)۔
• dev/staging میں کنسول وارننگ (پروڈکشن کنسول آؤٹ پٹ میں کبھی نہیں جو اختتامی صارفین دیکھیں، مگر ٹریکنگ کے لیے Sentry میں logged)۔
• ترجمہ قرض ڈیش بورڈ (§15 دیکھیں) میں ایک قطار جو کلید، لوکیل، اور جہاں استعمال ہوتی ہے فہرست کرتی ہے۔

12.3 فال بیک زنجیر

active-locale string  →  (missing)  →  English string  →  (missing)  →  the key itself in [brackets]

آخری [key.itself] حالت CI میں پکڑی جانے والی سخت ناکامی ہے (§5.3) اور کبھی پروڈکشن تک نہیں پہنچنی چاہیے۔ درمیانی حالت (علامت کے ساتھ انگریزی فال بیک) قابلِ قبول وقفہ ہے؛ مقصد کسی بھی جاری لوکیل میں دونوں میں سے کسی کا صفر ہے۔

12.4 طویل فارمیٹ مواد

MDX مواد (KB مضامین، SOPs) کے لیے، اگر کسی لوکیل کا ترجمہ stale یا غائب ہو، تو صفحہ اوپر ایک بینر کے ساتھ انگریزی نسخہ رینڈر کرتا ہے: "یہ مضمون ابھی [اردو/سندھی] میں دستیاب نہیں۔ انگریزی اصل دکھائی جا رہی ہے۔" بینر ایک تاثر (feedback) لنک رکھتا ہے تاکہ صارفین ترجیح کی درخواست کر سکیں، اور فرق logged ہوتا ہے۔

13. SEO: فی لوکیل hreflang و sitemap

13.1 hreflang

ہر عوامی صفحہ ہر لوکیل کے لیے <link rel="alternate"> ٹیگز، ساتھ x-default خارج کرتا ہے:

<link rel="alternate" hreflang="en" href="https://sindhitportal.maahir.io/en/..." />
<link rel="alternate" hreflang="ur" href="https://sindhitportal.maahir.io/ur/..." />
<link rel="alternate" hreflang="sd" href="https://sindhitportal.maahir.io/sd/..." />
<link rel="alternate" hreflang="x-default" href="https://sindhitportal.maahir.io/en/..." />

x-default EN مرجع کی طرف اشارہ کرتا ہے۔ لوکیل سابقہ شدہ URL مستند ہے (§3.1 دیکھیں)؛ نقلِ مواد کے ابہام سے بچنے کے لیے کوئی غیر سابقہ شدہ لوکیل نہیں ہے۔ hreflang Next.js پورٹل (فی راستہ) اور Docusaurus دستاویزاتی سائٹ (بلٹ اِن i18n تائید) دونوں کے ذریعے خارج کیا جاتا ہے۔

13.2 Sitemap

ایک فی لوکیل sitemap انڈیکس بلڈ وقت پر تیار کیا جاتا ہے:

/sitemap.xml          → index listing the per-locale sitemaps
/sitemap-en.xml       → all EN public URLs
/sitemap-ur.xml       → all UR public URLs
/sitemap-sd.xml       → all SD public URLs

ہر فی لوکیل sitemap میں صرف اسی لوکیل کے سابقہ میں URLs فہرست ہیں، lastmod مواد کی آخری ترجمہ منظوری کی عکاسی کرتا ہے (EN مرجع کی ترمیم نہیں)، اس لیے سرچ انجنز دیکھتے ہیں کہ UR یا SD نسخہ واقعی کب تبدیل ہوا۔

13.3 مقامیاندازی شدہ میٹا ڈیٹا

<title>, <meta description>, Open Graph, اور Twitter Card ٹیگز سب لوکیل کیٹلاگ سے ماخوذ ہوتے ہیں — کبھی ہارڈکوڈ نہیں، کبھی SEO پرت کے ذریعے خودکار ترجمہ نہیں۔ ہر عوامی صفحہ کا میٹا ڈیٹا ایک نظرثانی شدہ ترجمہ ہے۔ OG تصاویر مقامیاندازی شدہ متن overlays رکھتی ہیں جہاں ڈیزائن نظام تائید کرتا ہے (/specs/ur/16-branding-design-system/ دیکھیں)۔

13.4 robots اور crawl بجٹ

/ur/ اور /sd/ درخت مکمل طور پر crawl کے قابل ہیں (بلاک نہیں)؛ یہ فرسٹ کلاس مواد ہیں۔ سرچ انجن کا crawl بجٹ observability میں نگرانی کیا جاتا ہے؛ اگر کوئی لوکیل مستقل طور پر کم اِنڈیکسڈ ہو، تو وجہ (سست رینڈر، غائب hreflang، پتلا مواد) کی تفتیش اور اصلاح کی جاتی ہے۔

14. فی لوکیل قابلِ رسائی

WCAG 2.1 AA مطابقت (_context.md §2 میں مقفل) تینوں لوکیلز پر یکساں لاگو ہوتی ہے۔ قابلِ رسائی ایک واحد لوکیل کا معاملہ نہیں ہے۔

14.1 زبان کی نسبتی

• ہر صفحہ درست <html lang="..." dir="..."> مرتب کرتا ہے۔
• مخلوط زبان کے رنز کو <span lang="..."> میں لپٹایا جاتا ہے تاکہ اسکرین ریڈر جملہ کے بیچ میں آواز بدلے (مثلاً سندھی پیراگراف جو انگریزی مخفف کا حوالہ دے)۔
• صارف کا جمع کردہ مواد lang="auto" استعمال کرتا ہے تاکہ اسکرین ریڈر زبان اٹھا لے۔

14.2 RTL اسکرین ریڈر تائید

• تمام تعاملی عناصر کے مرئی فوکس اشاریے ہیں جو دونوں سمتوں میں کام کرتے ہیں (فوکس رنگن درست جانب)۔
• DOM میں پڑھنے کی ترتیب RTL میں بصری ترتیب سے مطابقت رکھتی ہے (کوئی CSS حیلے نہیں جو دیکھنے والے صارفین کے لیے مواد کو دوبارہ ترتیب دیں مگر اسکرین ریڈر بہاؤ توڑ دیں)۔
• لینڈ مارک کردار (nav, main, aside, footer) سمت سے آزاد اور مستقل طور پر اعلان شدہ ہیں۔

14.3 رنگ تضاد اور ٹائپوگرافی

• برانڈ پیلیٹ (Ajrak سے متاثر نیلا/مغولانی/سیاہ — _context.md §7 دیکھیں) LTR اور RTL دونوں لے آؤٹس میں WCAG AA تضاد پر جانچا جاتا ہے۔
• فی لوکیل فونٹ اسکیلنگ (§9.4) اور لائن ہائیٹ ٹوکنز (§9.3) AA کم از کم باڈی متن سائز پر قابلِ پڑہائی کے لیے توثیق شدہ ہیں۔
• لمبے اردو/سندھی الفاظ کو overflow-wrap: anywhere کے ساتھ کہیں بھی ٹوٹنے کی اجازت ہے تاکہ تنگ ویوپورٹس پر افقی scroll نہ ہو۔

14.4 کی بورڈ نیویگیشن

Tab ترتیب LTR اور RTL دونوں میں بصری ترتیب کی پیروی کرتی ہے۔ کی بورڈ شارٹ کٹس جو سمت کا تاثر دیتی ہیں (مثلاً واپس کے لیے Alt+Left) RTL میں mirror ہوتی ہیں (واپس کے لیے Alt+Right) یا جہاں ممکن ہو سمت سے غیر جانبدار بنائی جاتی ہیں۔ Skip-to-content لنکس دونوں سمتوں میں کام کرتے ہیں۔

14.5 معاون ٹیکنالوجی جانچ

ہر ریلیز میں تینوں لوکیلز پر NVDA + Firefox اور VoiceOver + Safari پر معاون ٹیکنالوجی کا جائزہ شامل ہے، Nastaliq اور Naskh تلفظ پر خصوصی توجہ کے ساتھ۔ نتائج لوکیل کو published نشان زد کرنے سے پہلے بند ہونے تک ٹریک کیے جاتے ہیں۔

15. ترجمہ QA و نظرثانی گیٹس

15.1 QA پائپ لائن

ترجمہ کے معیار کو چار گیٹس پر نافذ کیا جاتا ہے:

15.2 ترجمہ قرض ڈیش بورڈ

ایک اندرونی ڈیش بورڈ (Super Admin اور Department Admin کو نظر آنے والا) رپورٹ کرتا ہے:

• ہفتہ وار فی لوکیل پروڈکشن میں EN فال بیک واقعات کی گنتی۔
• stale تراجم کی گنتی (آخری منظوری کے بعد EN تبدیل)۔
• ہر نظرثانی قطار میں source-only اور ai-draft اشیاء کی گنتی۔
• نظرثانی کنندگان کی کارکردگی (فی نظرثانی کنندہ فی ہفتہ منظور شدہ اشیاء)۔
• تعداد کے مطابق top فال بیک کلیدز (تاکہ سب سے زیادہ صارف کو نظر آنے والے فرق کو ترجیح دی جائے)۔

15.3 لسانی QA نمونہ چینی

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

15.4 دونوں سمتوں میں بصری regression

بصری regression سویٹ (/specs/ur/13-test-strategy/ کا حصہ) ہری کہانی کو dir="ltr" اور dir="rtl" دونوں میں چلاتا ہے۔ کوئی تبدیلی جو EN میں درست مگر UR یا SD میں لے آؤٹ توڑ دے، سویٹ ناکام کرتی ہے۔

16. سرکاری اصطلاحات و تمیز

16.1 محکمہ بمقابلہ وزارت کا امتیاز

SITP میں سب سے اہم اصطلاحی قاعدہ، _glossary.md میں مقفل (top critical-distinction note):

S&ITD ایک صوبائی محکمہ ہے — اردو محکمہ / سندھی محڪمو۔ یہ ایک وزارت نہیں ہے — اردو وزارت / سندھی وزارت۔ مترجمین کو کبھی "Department" کو "وزارت" رینڈر نہیں کرنا چاہیے یا اس کا الٹا۔

یہ اس لیے اہم ہے کیونکہ پاکستان کی وفاقی وزارتیں اور صوبائی محکمے آئینی طور پر الگ ہیں؛ کسی سرکاری خط یا عوامی صفحہ پر S&ITD کو "وزارت" کہنا ایک واقعاتی اور سیاسی غلطی ہے، اندازِ بیان کی نہیں۔ AI ترجمہ پائپ لائن کو یہ ایک سخت ممنوع میپنگ کے طور پر دیا جاتا ہے؛ QA لنٹر (§7.4, §15 G1) کسی بھی ترجمے کو ناکام کرتا ہے جو "Department" کے لیے وزارت یا "Ministry" کے لیے محکمہ پیدا کرے۔

16.2 دیگر مقفل امتیازات

16.3 کبھی ترجمہ نہ ہونے والی اصطلاحات

کچھ اصطلاحات لغت کے قاعدے کے مطابق تینوں لوکیلز میں اپنی اصل شکل میں رکھی جاتی ہیں:

• مخففات: SITP, S&ITD, SACM, NADRA, SECP, FBR, SRB, PSEB, NITB, SLA, FRT, TAT, CSAT, RBAC, 2FA, OTP, PII, OCR, LLM, RAG, MoM, TRI, PKI, IVR, RTI, WCAG, RTL, CII, CERT-PK, PPP, ADP, SIFC, MoU۔
• نظام شناخت کنندے: ٹکٹ IDz (SITP-2026-LBR-000123), CNIC, NTN, STRN, SECP انکارپوریشن نمبرز۔
• مصنوعات/نظام نام جو proper nouns ہیں: e-Office, Keycloak, Meilisearch, MinIO, Metabase, Mailjet, WhatsApp۔

مترجمین اور AI پائپ لائن کو ہدایت کی جاتی ہے کہ انہیں ویسی ہی چھوڑ دیں؛ NADRA کو اردو رسمِ خط میں "ترجمہ" کرنے کی کوشش ایک عیب ہے۔

16.4 نقلِ نگاری (transliteration) فال بیک

جہاں لغت کسی اصطلاح کو (معیاری ترجمہ درکار) ("standard translation needed") سے نشان زد کرے، اصطلاح کو مقامی رسمِ خط میں نقلِ نگاری کیا جاتا ہے اور مستقبل میں لغت کی بہتری کے لیے نشان زد کیا جاتا ہے۔ یہ اشیاء قرض ڈیش بورڈ (§15.2) میں ظاہر ہوتی ہیں تاکہ لغت کے مالکان انہیں بند کریں۔

17. فعلی تقاضے

18. غیر فعلی تقاضے

19. صارف کہانیاں

US-PUB-101 — بغیر جگہ کھوئے لوکیل بدلیں [Must]

بطورِ کمپنی نمائندہ میں چاہتا ہوں نشست کے بیچ میں پورٹل کو انگریزی سے اردو پر بدلنا تاکہ میں اپنی پسند کی زبان میں مواد پڑھ سکوں بغیر وہ ٹکٹ یا صفحہ کھوئے جسے میں دیکھ رہا تھا۔

قبول کے معیار (Gherkin)

Scenario: Locale switch preserves location
  Given a Company Representative is viewing ticket SITP-2026-LBR-000123 in the English locale
  When they click the locale switcher and select Urdu
  Then the URL rewrites to the /ur/ prefix for the same ticket
  And the page re-renders in Urdu with right-to-left direction
  And the same ticket SITP-2026-LBR-000123 remains on screen
  And the sitp_locale cookie is set to "ur"
  And their user record's locale is persisted as "ur"

US-PUB-102 — تاریخیں گریگورین اور ہجری دونوں میں دیکھیں [Must]

بطورِ افسر میں چاہتا ہوں کسی ٹکٹ کی ہر تاریخ گریگورین اور ہجری دونوں دکھائے تاکہ میری سرکاری خط و کتابت سرکاری روایت سے مطابقت رکھے۔

قبول کے معیار (Gherkin)

Scenario: Dual calendar display
  Given an Officer is viewing a ticket with created-at 2026-07-17 14:30 PKT
  Then the created-at timestamp shows "17 Jul 2026" (Gregorian)
  And beside or beneath it shows the corresponding Hijri date
  And both are rendered in the Officer's locale numeral format

US-PUB-103 — بہ تقاضا کسی آنے والے اردو ٹکٹ کا ترجمہ کریں [Should]

بطورِ انگریزی لوکیل والا افسر میں چاہتا ہوں اردو میں داخل شدہ ٹکٹ پر "ترجمہ" کلک کرنا تاکہ میں اپنی انگریزی نشست چھوڑے بغیر اسے سمجھ سکوں۔

قبول کے معیار (Gherkin)

Scenario: On-demand machine translation
  Given an Officer with locale "en" is viewing a ticket whose description was authored in Urdu
  When they click the "Translate" affordance
  Then the system returns an English rendering via the AI translation capability
  And the rendering is clearly labelled "Machine translation"
  And the original Urdu text is preserved as the record
  And an audit row is written recording the translation call

US-PUB-104 — خاموش انگریزی فال بیک کبھی نہ دیکھیں [Must]

بطورِ سندھی لوکیل صارف میں چاہتا ہوں جاننا کب کوئی مواد اس لیے انگریزی میں دکھائی دے رہا ہے کیونکہ سندھی نسخہ غائب ہے تاکہ مجھے غیر متوقع زبان کی تبدیلی سے الجھن نہ ہو۔

قبول کے معیار (Gherkin)

Scenario: Visible fallback marker
  Given the Sindhi locale catalog is missing the key "tickets.newBadge.tooltip"
  When a Sindhi-locale user views the ticket list
  Then the tooltip shows the English string
  And the tooltip is rendered with the fallback marker (dotted underline or EN badge)
  And the missing key is logged to the translation debt dashboard

US-PUB-105 — نظرثانی کنندہ ایک AI ترجمہ مسودہ منظور کرے [Must]

بطورِ مقامی اردو نظرثانی کنندہ میں چاہتا ہوں نئے تحریر کردہ KB مضمون کا AI تیار کردہ اردو مسودہ نظرثانی کرنا تاکہ صرف درست، لغت کے مطابق اردو عوامی سائٹ تک پہنچے۔

قبول کے معیار (Gherkin)

Scenario: Native review gate
  Given a KB article was authored in English and the AI translation pass produced an Urdu draft
  And the draft's status is "ai-draft"
  When the reviewer opens the review workbench
  Then they see the English source, the Urdu draft, and the glossary-approved terms side by side
  And they can edit the draft inline
  And on approval the status moves to "approved" and then "published"
  And their edits are saved to the AI tuning corpus

20. ٹیسٹ کیسز

21. کھلے سوالات / TBD

دستاویز کا اختتام۔