Localization Data Model، Translation Memory و Terminology

۱. صفحه اول: تطابق ۱۰۰٪ هم می‌تواند اشتباه باشد

فرض کنید محصول دو سال است واژه workspace را استفاده می‌کند. در Translation Memory آلمانی، برای «Open workspace» ترجمه Arbeitsbereich öffnen وجود دارد و ابزار CAT آن را ۱۰۰٪ match نشان می‌دهد. اما یک ماه قبل تیم محصول نام feature را تغییر داده و Projektbereich را به‌عنوان اصطلاح فعلی UI تأیید کرده است. ترجمه قدیمی از نظر متن دقیق است، ولی از نظر وضعیت محصول stale است.

موضوع این درس همین مرز است. داده localization فقط مجموعه‌ای از stringها نیست. Translation Unit قابل reuse باید source و target، جفت locale، context، status، provenance و lifecycle داشته باشد. Terminology یک asset متفاوت و governed است که می‌تواند term ترجیحی، ممنوع، مخصوص محصول یا deprecated را تعریف کند. reuse زمانی قابل دفاع می‌شود که این رکوردها با هم ارزیابی شوند، نه اینکه درصد match به‌جای approval بنشیند.

راهنمای فعلی Microsoft، Translation Memory را مخزن source/target translation unit می‌داند، exact/context match و fuzzy match را از هم جدا می‌کند و صریحاً درباره duplicate، inconsistent و obsolete شدن داده‌های TM و نیاز به maintenance هشدار می‌دهد. [S-MS-TM] در localization overview نیز TM و terminology list به‌عنوان linguistic assetهای جدا مطرح می‌شوند و TMX و TBX برای interchange این دو نوع داده ذکر شده‌اند. [S-MS-LOC] الزام‌های W3C درباره terminology نیز بر شناسایی term و اتصال terminology data برای reuse در مراحل و ابزارهای localization تأکید دارند. [S-W3C-TERM]

Artifact محدود درس Localization Data & Terminology Governance Record v1 است. این رکورد نوع داده، source/target، locale pair، namespace محصول/context، status، provenance، terminology constraint، reuse decision، mutation، repair، transfer و residual limitation را ثبت می‌کند. این artifact linguistic QA انجام نمی‌دهد، ترجمه AI را approve نمی‌کند و exact یا fuzzy score را به‌طور خودکار درست فرض نمی‌کند.

۲. مسیر یادگیری: شکل database هدف اصلی نیست

در مسیر پایه ابتدا دو مفهوم را جدا کنید. Translation Unit یک segment source/target قابل reuse در یک locale pair است. Terminology Record یک term را govern می‌کند و می‌گوید target ترجیحی یا ممنوع چیست و این rule در چه scopeای معتبر است. بعد fieldهای context، source identity/version، status، review history و terminology version را اضافه کنید تا reuse قابل بررسی شود.

در مسیر repair از یک reuse decision خراب شروع کنید: exact match deprecated را auto approve کنید، termbase را با full-sentence TM یکی کنید، provenance را حذف کنید یا fuzzy score بالا را جای terminology فعلی بنشانید. قبل از اجرا issue code مورد انتظار را پیش‌بینی کنید، audit را اجرا کنید و فقط همان boundary را repair کنید.

در مسیر experienced، fixture را مثل یک data-governance contract review کنید. باید بتوانید بپرسید: این ترجمه متعلق به کدام product و surface بوده؟ active است یا deprecated؟ کدام source version review شده؟ چه terminology ruleای زمان approval برقرار بوده؟ candidate exact/context/fuzzy/new است؟ و historical match پذیرفته، رد یا به review برگردانده شده؟ می‌توان توضیح مقدماتی را کوتاه کرد، اما mutation و evidence و transfer حذف نمی‌شوند.

۳. مدل ذهنی: چهار لایه با مسئولیت متفاوت

Source resource identity می‌گوید الان دقیقاً چه messageای localize می‌شود. key ثابت مثل nav.open_workspace مفید است، ولی کافی نیست؛ product، surface، source version و حتی معنای source می‌تواند تغییر کند.

Translation Memory segmentهای source/target قابل reuse را نگه می‌دارد. در مدل جدی، Translation Unit فقط دو string نیست؛ locale pair، context، lifecycle status و provenance لازم است تا رکورد قدیمی قابل تشخیص باشد. Microsoft حتی بین ۱۰۰٪ segment match و context match تفاوت می‌گذارد و fuzzy match را چیزی می‌داند که باید در context جاری بررسی شود. [S-MS-TM]

Terminology term را govern می‌کند، نه full sentence را. ممکن است برای Product Alpha، ترجمه فعلی workspace برابر Projektbereich باشد و Arbeitsbereich ممنوع شده باشد، در حالی که Product Beta هنوز Arbeitsbereich را معتبر بداند. پس termbase باید scope و version داشته باشد. یکی کردن termbase و TM یک boundary واقعی governance را پاک می‌کند. [S-MS-LOC]

Reuse decision تصمیم پاسخ‌گو بر پایه evidence است. similarity فقط candidate پیدا می‌کند؛ quality score جهانی نیست. ۱۰۰٪ match ممکن است به‌علت تغییر terminology یا product meaning stale باشد. ۹۲٪ fuzzy match ممکن است در یک context مفید و در context دیگر نامناسب باشد. مدل باید امکان reject کردن historical match را حفظ کند.

۴. لایه پایه: identity، context، lifecycle و provenance

Translation Unit حداقلی این درس شامل id، source، target، source_locale، target_locale، context، status، provenance، terminology_version و در صورت نیاز superseded_by است. Context حداقل product، surface و resource key دارد. Provenance شامل source version، reviewer و review date است. Status بین حالت‌هایی مثل approved، deprecated و review_required تفاوت می‌گذارد.

هر field سؤال متفاوتی را جواب می‌دهد. status می‌گوید رکورد فعلاً eligible هست یا نه. source_version نشان می‌دهد کدام revision واقعاً review شده. terminology_version policy زمان approval را مشخص می‌کند. superseded_by از رکورد قدیمی به successor فعلی trace می‌دهد. هیچ‌کدام به‌تنهایی correctness را ثابت نمی‌کنند، ولی با هم stale reuse را diagnosable می‌کنند.

Terminology Record عمداً ساختاری متفاوت دارد: source term، target locale، preferred target، forbidden alternativeها، scope محصول/context، status و version. termbase می‌تواند روی Translation Unit constraint بگذارد، بدون اینکه خودش Translation Unit باشد. الزام‌های W3C درباره terminology association و reuse نیز با این تفکیک سازگار است. [S-W3C-TERM]

Timestamp را freshness score جادویی فرض نکنید. رکوردی که دیروز review شده ممکن است برای namespace دیگری اشتباه باشد؛ term پایدار قدیمی ممکن است هنوز معتبر باشد. زمان بخشی از provenance است، نه proof.

۵. توضیح عمیق: exact، context، fuzzy و new فقط کلاس candidate هستند

pipeline مناسب ابتدا candidate پیدا می‌کند و بعد governance decision می‌گیرد.

Exact segment match یعنی source text یکسان است. این موضوع product meaning، resource context، terminology یا status فعلی را ثابت نمی‌کند. Microsoft صریحاً segment-only 100% match را از context match جدا می‌کند. [S-MS-TM]

Context match candidate را قوی‌تر می‌کند، ولی terminology یا lifecycle فعلی را override نمی‌کند.

Fuzzy match یک retrieval hint با درصد similarity است. Microsoft توضیح می‌دهد که translator باید هر fuzzy match را در context جاری بسنجد؛ بعضی با اصلاح کم قابل استفاده‌اند، بعضی نیاز به بازترجمه دارند و بعضی اصلاً قابل استفاده نیستند. [S-MS-TM] پس این درس fuzzy score را metadata candidate نگه می‌دارد، نه threshold جهانی approval.

New translation failure نیست. وقتی historical unit قرارداد جاری را برآورده نمی‌کند، ساخت ترجمه جدید می‌تواند تصمیم درست باشد.

Lab تصمیم‌ها را با labelهایی مثل REJECT_STALE، REUSE_CANDIDATE_REVIEW_REQUIRED، REVIEW_REQUIRED_TERM_CONFLICT و NAMESPACE_OR_NEW_REVIEW ثبت می‌کند. هیچ‌کدام به معنی linguistic approval خودکار نیست. نتیجه QA و AI-assisted review متعلق به درس بعدی است.

۶. مثال کامل: workspace بعد از rename محصول

Product Alpha قبلاً workspace را Arbeitsbereich ترجمه می‌کرد. TU-001 برای “Open workspace” مقدار “Arbeitsbereich öffnen” دارد. source text امروز هم دقیقاً match می‌شود، اما status رکورد deprecated است، terminology version قدیمی است و TU-002 به‌عنوان successor ثبت شده.

Terminology فعلی Product Alpha می‌گوید preferred term آلمانی Projektbereich است و Arbeitsbereich ممنوع است. TU-002 target جدید “Projektbereich öffnen” را دارد، context و terminology version فعلی را نگه می‌دارد و approved است. با این حال data layer آن را reuse candidate requiring current review ثبت می‌کند، نه approval زبانی قطعی. این درس candidate و evidence را govern می‌کند و outcome درس QA را نمی‌دزدد.

candidate دیگری برای “Create a new workspace” یک fuzzy historical match با score 92 دارد، اما target آن term قدیمی ممنوع را استفاده می‌کند. evidence صحیح این نیست که «۹۲ زیاد است، پس reuse کن». evidence صحیح این است: similarity candidate را پیدا کرد؛ termbase فعلی conflict را نشان داد؛ provenance می‌گوید unit قبل از terminology change ساخته شده؛ decision باید REVIEW_REQUIRED_TERM_CONFLICT باشد.

Evidence matrix هر مرحله را قابل audit می‌کند: Record Type، Source، Target، Locale Pair، Context، Status، Provenance، Terminology Constraint و Reuse Decision. اگر row نتواند توضیح دهد چرا candidate رد یا escalate شده، مدل برای outcome درس بیش از حد lossy است.

۷. Failure modeهای پنهان

Auto approval برای exact match: سیستم ۱۰۰٪ را می‌بیند و approved=true می‌گذارد؛ نام feature قدیمی دوباره وارد UI می‌شود.

یکی کردن TM و termbase: full sentence translation و term policy در یک جدول بدون record type واقعی ادغام می‌شوند؛ reviewer نمی‌فهمد row ترجمه جمله است یا terminology constraint.

حذف provenance: برای یک source دو target وجود دارد، اما source version، reviewer، review date یا successor نداریم؛ duplicate را می‌بینیم ولی current بودن قابل دفاع نیست.

Similarity به‌عنوان quality: fuzzy score به confidence زبانی تبدیل می‌شود، در حالی که similarity درباره current terminology، audience، legal meaning یا UI context چیزی نمی‌گوید.

فعال نگه داشتن تاریخچه: همه historical rowها برای همیشه active می‌مانند. Microsoft obsolete/duplicate/terminology-inconsistent شدن TM را دقیقاً از مسائل maintenance معرفی می‌کند. [S-MS-TM]

Overclaim درباره interchange: فایل TMX یا TBX import می‌شود و تیم semantic compatibility را نتیجه می‌گیرد. interchange representation را portable می‌کند، نه context و lifecycle و namespace policy محصول را. [S-MS-LOC]

۸. پل برای مهندس باتجربه: localization asset را مثل governed code data ببینید

تشبیه قوی این نیست که «translation هم string است»؛ بهتر است بگوییم localization asset schema، provenance، migration، lifecycle state و compatibility boundary دارد. rename یک feature شبیه data migration است: historical row ممکن است برای audit بماند، اما read path جاری نباید آن را active فرض کند.

repository خوب می‌تواند توضیح دهد candidate چرا وجود دارد و decision چرا گرفته شده. بنابراین stable ID، status صریح، review event، supersession link و terminology scope ارزشمند می‌شوند. همچنین immutable history را از active view برای reuse پیشنهادها جدا می‌کند.

این درس را به معماری کامل CAT platform تبدیل نکنید. search engine، vector index، vendor workflow، MT engine یا reviewer UI لازم نیست. آن‌ها construct را پنهان می‌کنند. implementation محدود، dataset deterministic و auditی است که stale/conflicting reuse و changed-context overgeneralization را آشکار کند.

۹. Alternatives و trade-off

TM و terminology می‌توانند در serviceهای جدا، tableهای جدا یا یک physical store با record typeهای متفاوت باشند. layout فیزیکی نسبت به separation معنایی اهمیت کمتری دارد. اگر یک table استفاده می‌شود، record_type و validation ruleها باید مانع شوند term policy نقش sentence-level TU بگیرد.

history می‌تواند با status flag در همان store بماند، archive شود یا temporal/versioned storage داشته باشد. نگه داشتن history برای audit مفید است؛ active نگه داشتن همه history مشکل است. lifecycle باید explicit باشد.

candidate retrieval می‌تواند exact string، fuzzy CAT matching، token similarity یا embedding باشد. retrieval technique مالک acceptance نیست. context، status، terminology و provenance همچنان boundary تصمیم را می‌سازند.

TMX و TBX برای exchange بین toolها ارزشمندند. Microsoft TMX را برای translation-memory data و TBX را برای terminology data معرفی می‌کند. [S-MS-TM] [S-MS-LOC] اما portability syntax می‌تواند باعث overclaim semantic portability شود. Lab بنابراین semantic_compatibility_guaranteed=false را الزام می‌کند و بعد از import، product-specific validation را لازم می‌داند.

۱۰. تمرین هدایت‌شده و مستقل

تمرین هدایت‌شده: baseline audit را اجرا کنید و چهار reuse candidate را ببینید. قبل از اجرا پیش‌بینی کنید کدام exact match باید به‌دلیل stale بودن رد شود، کدام candidate فعلی هنوز review می‌خواهد و کدام fuzzy match به‌علت terminology conflict باید escalate شود.

بعد mutationها را اجرا کنید. deprecated exact match را AUTO_APPROVE کنید؛ audit باید STALE_EXACT_AUTO_APPROVAL بدهد. terminology را داخل translation-unit collection ادغام کنید؛ TM_TERMBASE_BOUNDARY باید fail شود. provenance current unit را حذف کنید؛ PROVENANCE_REQUIRED لازم است. fuzzy 92 را فقط به‌خاطر score approve کنید؛ FUZZY_SCORE_OVERCLAIM باید ظاهر شود. در آخر ادعا کنید import TMX/TBX semantic compatibility را تضمین می‌کند؛ audit باید INTERCHANGE_SEMANTIC_OVERCLAIM بدهد.

تمرین مستقل: Product Beta همان source term یعنی workspace را دارد، اما audience و terminology تثبیت‌شده‌اش متفاوت است. مشخص کنید چه چیزی share می‌شود، چه چیزی namespaced می‌شود و چه چیزی review جدید لازم دارد. فقط به‌دلیل یکسان بودن token انگلیسی، target Product Alpha را کپی نکنید.

۱۱. Verification و evidence: observation، inference، decision

در Localization Data & Terminology Governance Record v1 سه سطح جدا می‌شوند.

Observation: TU-001.status == deprecated؛ termbase Product Alpha مقدار Arbeitsbereich را forbidden می‌داند؛ TU-001.terminology_version == 1 و terminology فعلی version 3 است.

Inference: exact match تاریخی برای context فعلی Alpha stale است.

Decision: TU-001 را برای reuse جاری رد کن و successor آن را بررسی کن یا ترجمه جدید را وارد review کن.

در row fuzzy، observation می‌تواند score 92 باشد. inference محدود فقط این است که source به‌اندازه کافی مشابه است تا inspect شود. decision هنوز terminology و context را بررسی می‌کند. اگر preferred term فعلی نقض شده، record باید escalate شود.

Mutation evidence شامل predicted failure، observed issue code، diagnosis، repair و rerun است. Transfer evidence باید نشان دهد learner method را برای Product Beta منتقل کرده، نه answer Alpha را. Residual limitation باید صریح بگوید این fixture deterministic linguistic QA، human approval، ارزیابی machine translation یا interoperability واقعی vendor platform را ثابت نمی‌کند. این محدودیت بخشی از evidence است و نباید حذف شود.

۱۲. Assessment و transfer

باید بتوانید boundary بین TM و termbase را بیان کنید، مدل محدود را پیاده کنید، stale/conflicting reuse را diagnose کنید، fieldهای lifecycle/provenance را دفاع کنید، بگویید TMX/TBX چه چیزی را حمل می‌کنند و چه چیزی را ثابت نمی‌کنند، و method را به namespace محصول دوم منتقل کنید.

failهای blocking عبارت‌اند از: deprecated exact match خودکار approve شود؛ terminology و TU غیرقابل تمایز شوند؛ provenance در تصمیم lifecycle حذف شود؛ fuzzy percentage quality score جهانی فرض شود؛ interchange syntax semantic compatibility تلقی شود؛ یا changed-context task فقط terminology محصول اول را کپی کند.

AI می‌تواند بعد از بیان governing contract، checkهای پیشنهادی بدهد؛ اما نباید evidence را جعل کند یا acceptance accountable را جای reviewer بگیرد. این درس وقتی تمام می‌شود که data و evidence، safe reuse را reviewable کنند؛ نه وقتی tool درصد match بالایی نشان می‌دهد.

۱۳. منابع و freshness boundary

S-MS-TM — Microsoft، Translation memories. راهنمای فعلی translation unitها، exact/context و fuzzy match، TMX و مسائل maintenance مانند duplicate، inconsistent، obsolete و out-of-sync terminology را توضیح می‌دهد. [S-MS-TM]

S-MS-LOC — Microsoft، Localizing your product. راهنمای فعلی TM و terminology list را assetهای متمایز می‌داند، TMX/TBX interchange را معرفی می‌کند و review در context واقعی کاربر را مهم می‌داند. [S-MS-LOC]

S-W3C-TERM — W3C، Internationalization and Localization Markup Requirements، بخش terminology. شناسایی term و اتصال terminology data را برای reuse در مراحل و ابزارهای localization توصیف می‌کند. [S-W3C-TERM]

source boundary گسترش پیدا نکرده است. صفحات Microsoft از نوع practice-evolving و review_due آن‌ها 2026-12-31 است؛ منبع W3C foundational استفاده می‌شود. اگر guidance رسمی materially تغییر کرد، review باید زودتر انجام شود. این درس از portable file، exact match یا fuzzy percentage، correctness مخصوص محصول را نتیجه نمی‌گیرد.