چگونه واژه‌نامه ترجمه‌ای بسازیم که مترجمان و هوش مصنوعی واقعاً بتوانند از آن استفاده کنند
واژه‌نامه ترجمه را با زمینه، اصطلاحات تأییدشده، مالکان و وضعیت‌های بازبینی بسازید. یک قالب CSV دانلود کنید و پنج اصلاح ورودی ناقص را بررسی کنید.
برای ساخت واژه‌نامه ترجمه، مفاهیمی را که به واژه‌گزینی کنترل‌شده نیاز دارند انتخاب کنید، معنای هرکدام را در سند خود تعریف کنید، برای هر زبان و زمینه یک معادل تأیید کنید و مسئولی برای نگهداری این تصمیم‌ها تعیین کنید. سپس ورودی‌ها را در بندهای واقعی بیازمایید و بعد آن‌ها را به مترجمان یا ابزار ترجمه بسپارید.
مفیدترین تمایز میان واژه‌نامه اصلی که تصمیم‌های شما را ثبت می‌کند و خروجی کوچک‌تری که یک ابزار می‌تواند مصرف کند است. یک فایل ورودی دوستونی ممکن است لازم باشد، اما نمی‌تواند جایگزین زمینه، شواهد و تاریخچه تأییدی شود که آن دو ستون را قابل اعتماد کرده است.
با قالب خالی واژه‌نامه و نمونه واژه‌نامه تکمیل‌شده شروع کنید. هر دو فایل CSV با کدگذاری UTF-8 هستند. نمونه از یک محصول خیالی و تصمیم‌های نمونه انگلیسی به فرانسوی استفاده می‌کند؛ این یک فهرست اصطلاحات تأییدشده، پروژه مشتری یا پیش‌تنظیم آماده واردکردن برای BookTranslator نیست.
واژه‌نامه را کوچک‌تر از فرهنگ لغت نگه دارید
اصطلاحی را وارد کنید که انتخاب ناسازگار یا مبهم معنای آن را تغییر دهد، پیمایش را گیج کند، تمایز مهمی را تضعیف کند یا کار بازبینی قابل اجتناب ایجاد کند. هر اسمی را فقط به این دلیل که نرم‌افزار آن را استخراج کرده جمع نکنید.
یک مرحله انتخاب مفید این پرسش‌ها را مطرح می‌کند:
- آیا این مفهوم در بخش‌ها، فایل‌ها یا مشارکت‌کنندگان مختلف تکرار می‌شود؟
- آیا واژه مبدأ بیش از یک معنای مرتبط دارد؟
- آیا سازمان، نویسنده یا حوزه موضوعی به شکل معادل خاصی نیاز دارد؟
- آیا انتخاب متفاوت باعث می‌شود هشدار، دستور، رابط کاربری یا استدلال سخت‌تر دنبال شود؟
- آیا اصطلاح جدید، مورد اختلاف یا شناخته‌شده‌ای است که در این پروژه باعث اصلاح شده است؟
یک اصطلاح نادر اما مهم می‌تواند پیش از یک واژه معمول پرتکرار شایسته ورود به واژه‌نامه باشد. یک اصطلاح استاندارد که ابهام واقعی ندارد ممکن است اصلاً نیازی به ورودی نداشته باشد.
راهنمای مقدماتی مدیریت اصطلاحات برای ترجمه از COTSOES، اصطلاحات مرتبط با سازمان و مسئولیت‌های صریح اعتبارسنجی را توصیه می‌کند. همچنین هشدار می‌دهد که تعداد ورودی‌ها به‌تنهایی کیفیت را اثبات نمی‌کند. این اصول در اینجا مهم‌تر از قدمت نمونه‌های نرم‌افزاری آن هستند.
استخراج نامزدها فقط صندوق ورودی است. یک عبارت استخراج‌شده زمانی به اصطلاح مفید تبدیل می‌شود که بدانید چه معنایی دارد، کجا کاربرد دارد و چه کسی معادل را تأیید کرده است.
یک رکورد را حول یک معنا بسازید
مالکیت رکورد را تنها به رشته مبدأ ندهید. واژه انگلیسی «charge» می‌تواند ویژگی الکتریکی یا مبلغ صورت‌حساب را توصیف کند. یک ردیف که هر رخداد را به یک واژه فرانسوی نگاشت کند، خطا را رمزگذاری می‌کند نه سازگاری را.
به هر مفهوم یک شناسه پایدار بدهید، سپس تصمیم وابسته به زبان را اضافه کنید. در یک صفحه‌گسترده ساده، برای هر مفهوم و جفت زبان مبدأ/مقصد یک ردیف استفاده کنید. دو ردیف می‌توانند املای مبدأ یکسانی داشته باشند بدون اینکه نماینده یک مفهوم واحد باشند.
قالب شامل این فیلدها است:
| گروه فیلد | فیلدها | چه چیزی را جلوگیری می‌کنند |
|---|---|---|
| هویت | شناسهٔ مدخل، شناسهٔ مفهوم، اصطلاح مبدأ، زبان مبدأ، زبان مقصد | اشتباه گرفتن معناهای متفاوت یا گونه‌های زبانی |
| معنا | تعریف، حوزه، نقش دستوری، بافت مبدأ، ارجاع بافت | انتخاب یک معادل واژه‌نامه‌ای محتمل برای کاربرد نادرست |
| تصمیم مقصد | معادل تأییدشده، بافت مقصد، نشانگر ترجمه‌نشدنی، گونه‌های ردشده، قاعدهٔ کاربرد | یکسان پنداشتن گزینه‌های جایگزین یا تغییرات دستوری |
| پاسخگویی | وضعیت، مالک، منبع تصمیم، آخرین بازبینی، نسخه، یادداشت تغییر | تبدیل بی‌صدای یک ترجیح پیش‌نویس یا منسوخ به سیاست |
ارجاع بافت باید به بازبین امکان دهد تا آن قطعه را دوباره پیدا کند: نسخه و بخش فایل، یک مدخل اصطلاح معتبر، یا منبعی بادوام دیگر. «از اینترنت» کافی نیست. برای مفهومی که خود نویسندهٔ اصلی تعریف کرده است، تعریف موجود در دست‌نوشته می‌تواند شاهد مرتبط باشد.
تعریف را از بافت مبدأ جدا نگه دارید. تعریف می‌گوید مفهوم چیست؛ بافت نشان می‌دهد چگونه به کار می‌رود. جمله‌ای مانند «کارگاه را انتخاب کنید» کاربرد را نشان می‌دهد اما توضیح نمی‌دهد که یک کارگاه شامل چه چیزی است یا چه تفاوتی با یک پروژه دارد.
پنج مدخل رایج واژه‌نامه را اصلاح کنید
اصلاح‌های زیر به نمونهٔ داستانی قابل‌دانلود تعلق دارند. آن‌ها تصمیم‌های ویرایشی را نشان می‌دهند، نه قواعد جهانی اصطلاح‌شناسی فرانسه. قطعه‌های نمونه متن پیرامونی را فراهم می‌کنند.
۱. یک واژهٔ چندمعنا با یک معادل مقصد تحمیلی
مدخل ضعیف: charge → charge
اصلاح: مفاهیم جداگانه بسازید:
- ویژگی الکتریکی: مبدأ
charge؛ مقصدcharge électrique؛ حوزه «الکترونیک مقدماتی»؛ بافت «The capacitor stores electric charge.» - مبلغ صورت‌حساب: مبدأ
charge؛ مقصدfrais؛ حوزه «صورت‌حساب»؛ بافت «The delivery charge is shown before payment.»
این به آن معنا نیست که هر یک از این نگاشت‌ها باید بر هر رخداد «charge» غلبه کند. حوزه و بافت مدخل بخشی از تصمیم هستند. اگر ابزار انتخابی نمی‌تواند آن‌ها را تشخیص دهد، از خروجی‌های پروژهٔ جداگانه، عبارت بلندتر بدون ابهام، یا بازبینی انسانی به‌جای جایگزینی سراسری استفاده کنید.
۲. اصطلاحی بدون نقش دستوری
مدخل ضعیف: seal → sceller
اصلاح: فعل را از قطعه جدا کنید:
- «پاکت را مهر و موم کن»: یک فعل، با معادل نمونه
scellerدر این پروژه. - «واشر لاستیکی را عوض کن»: یک اسم که به یک قطعه اشاره دارد، با معادل
joint.
صفحه‌گسترده اکنون دو مفهوم را توصیف می‌کند، نه اینکه پیشنهاد کند یک قطعه لاستیکی یک عمل است. برای یک سند فنی واقعی، از بازبین حوزه بخواهید معنای قطعه و اصطلاح ترجیحی را تأیید کند.
۳. دو ترجمه قابل قبول بدون ترجیح پروژه
مدخل ضعیف: workspace → espace de travail / zone de travail
اصلاح: espace de travail را برای ظرف نام‌گذاری‌شدهٔ برنامهٔ خیالی تأیید کنید. zone de travail را به‌عنوان گونهٔ ردشده برای این مفهوم رابط کاربری ثبت کنید، نه به‌عنوان فرانسوی بد به‌طور کلی. یادداشت کاربرد اضافه کنید که صرف دستوری عادی مجاز است.
گونهٔ ردشده به دلیل و دامنه نیاز دارد. در غیر این صورت ممکن است بازبین عبارتی کاملاً معتبر را در بافت متفاوت «تصحیح» کند.
۴. نام محصولی که فقط به‌طور ضمنی محافظت شده است
مدخل ضعیف: LeafDeck → LeafDeck
اصلاح: do_not_translate=true را تنظیم کنید، آن را به‌عنوان نام محصول خیالی مشخص کنید، بزرگی و کوچکی حروف را حفظ کنید، و به تصمیم نام‌گذاری پروژهٔ نمایشی استناد کنید. بیان کنید که این قاعده برای واژه‌های نامرتبط در یک توصیف عادی اعمال نمی‌شود.
تطابق صرف متن مبدأ و مقصد توضیح نمی‌دهد که آیا حفظ عمدی است یا صرفاً کاری ناتمام. برای فهرست گسترده‌تر موارد استثنا از راهنمای تصمیم‌گیری دربارهٔ ترجمه‌نکردن استفاده کنید.
۵. تصمیم پیش‌نویس که به‌عنوان تأییدشده ارائه شده است
مدخل ضعیف: sync → synchroniser / mettre à jour، بدون مالک یا وضعیت.
اصلاح: ابتدا عمل را تعریف کنید. برای فرمان خیالی که کتابخانهٔ دستگاه را همگام‌سازی می‌کند، synchroniser را به‌عنوان فعل تأیید کنید و گزینهٔ جایگزین را برای این فرمان خاص نامناسب ثبت کنید. یک مالک و منبع تصمیم تاریخ‌دار تعیین کنید.
برچسب اسمی پیشنهادی جداگانه را تا زمانی که بازبین آن را حل‌وفصل کند در وضعیت draft نگه دارید. فایل CSV نمونه عمداً آن سطر پیش‌نویس را شامل می‌شود. یک صفحه‌گستردهٔ ظاهراً تمیز مدرکی بر تأییدشده بودن هر سطر نیست.
از یک دروازهٔ کیفیت مدخل استفاده کنید، نه یک امتیاز تزئینی
پیش از تأیید یک مدخل، شش پرسش بله/خیر بپرسید:
- معنا: آیا شخص دیگری می‌تواند این مفهوم را از مفاهیم مجاور تشخیص دهد؟
- شواهد: آیا می‌تواند منبع پشتیبان یا تصمیم نویسنده را پیدا کند؟
- زبان: آیا شکل مقصد برای زبان، دستور و حوزهٔ مشخص‌شده کار می‌کند؟
- دامنه: آیا می‌دانند قاعده کجا اعمال می‌شود و کجا نمی‌شود؟
- پاسخگویی: آیا مالکی مسئول حل تغییرات است؟
- کاربرد: آیا مدخل در یک جملهٔ نمونه بررسی شده است؟
پاسخ حل‌نشده یعنی مدخل در پیش‌نویس می‌ماند. این یک معیار پذیرش ویرایشی است، نه سنجهٔ عددی معتبر برای کیفیت ترجمه.
کار را بر اساس تخصص تقسیم کنید. نویسنده یا متخصص موضوع، مفهوم را تأیید می‌کند؛ بازبین زبان مقصد، کاربرد را تأیید می‌کند؛ و مسئول اصطلاح‌شناسی تصمیم را ثبت و نسخه تأییدشده را توزیع می‌کند. در یک پروژه کوچک، یک نفر می‌تواند چندین نقش را ایفا کند، اما هنوز باید به پرسش‌ها پاسخ داده شود.
اگر بازبینی با یک مدخل مخالفت کرد، گزینه‌های رقیب و قطعه‌ای که تضاد را آشکار می‌کند ثبت کنید. به جای اجازه دادن به پیام‌های خصوصی برای تبدیل شدن به استثناهای مستندنشده، گردش‌کار پرسش مترجم را دنبال کنید.
خروجی را فقط پس از تأیید برای ابزار دریافت‌کننده صادر کنید
واژه‌نامه اصلی شما و فرهنگ لغت یک موتور، اهداف متفاوتی دارند. واژه‌نامه اصلی تصمیم‌ها را برای افراد توضیح می‌دهد. یک فایل ورودی باید از طرح‌واره و رفتار تطبیق یک ابزار خاص پیروی کند.
برای ابزاری که از ورود واژه‌نامه پشتیبانی می‌کند:
- جفت زبان مبدأ/مقصد مورد نیاز و حوزه پروژه را انتخاب کنید.
- مدخل‌های
draftوdeprecatedرا حذف کنید. - رشته‌های مبدأ تکراری را که ابزار دریافت‌کننده نمی‌تواند از هم تفکیک کند، حل کنید.
- فقط فیلدهای پشتیبانی‌شده را به قالب ورودی فعلی ابزار نگاشت کنید.
- تأیید کنید که چگونه با حروف بزرگ و کوچک، صرف‌ها، اصطلاحات چندکلمه‌ای و متن محافظت‌شده رفتار می‌کند.
- یک ورودی کوچک نمونه را آزمایش کنید و ترجمه بازگشتی را بررسی کنید.
برای مثال، قالب CSV یک‌طرفه مستندشده Google Cloud Translation از جفت‌های مبدأ/مقصد بدون سرصفحه استفاده می‌کند، در حالی که CSV مجموعه اصطلاحات معادل آن از سرصفحه‌های زبانی استفاده می‌کند. تطبیق واژه‌نامه آن به طور پیش‌فرض به حروف بزرگ و کوچک حساس است و برخی مدخل‌های کلمات ایست نادیده گرفته می‌شوند. این‌ها قواعد Google Cloud هستند، نه قواعد عمومی CSV یا قابلیت‌های BookTranslator. قبل از آماده‌سازی خروجی برای آن سرویس، مستندات فعلی واژه‌نامه Google Cloud را بررسی کنید.
CSV غنی‌شده با حاشیه‌نویسی این مقاله را در یک پنجره ورود تصادفی بارگذاری نکنید. این یک نسخه اصلی کاری است. برعکس، تعاریف و تاریخچه تأیید آن را فقط به این دلیل که یک ابزار تنها دو ستون می‌پذیرد، دور نریزید.
هنگام استفاده از یک سیستم هوش مصنوعی با فیلد دستور پشتیبانی‌شده، یک زیرمجموعه مرتبط و تأییدشده به همراه زمینه لازم برای تشخیص معانی ارائه دهید. یک دستور می‌تواند درخواست اصطلاح‌شناسی کند؛ اما ثابت نمی‌کند که خروجی از آن پیروی کرده است. نتیجه را بررسی کنید. اگر سیستم هیچ ورودی واژه‌نامه پشتیبانی‌شده‌ای ارائه نمی‌دهد، نسخه اصلی را به عنوان مرجع بازبین نگه دارید، نه اینکه راهی برای وارد کردن آن اختراع کنید.
برای سازمان‌هایی با تیم‌های خط مقدم چندزبانه، یکدستی اصطلاحات پس از ترجمه نیز اهمیت دارد. مواد آموزشی، سیاست‌ها و ارتباطات عملیاتی ممکن است نیاز باشد که به زبان‌های ترجیحی کارکنان برسند و در عین حال عبارت‌های تأییدشده را حفظ کنند. iTacit توضیح می‌دهد که چگونه ارتباطات چندزبانه از اطلاعات محیط کار در زبان‌ها، کشورها و فرهنگ‌های مختلف پشتیبانی می‌کند.
زبان‌ها را بدون پاک کردن تصمیم‌های محلی اضافه کنید
هنگام افزودن یک زبان مقصد دیگر، شناسه مفهوم را دوباره استفاده کنید، اما به آن زبان مقصد، هدف، وضعیت، مسئول و شواهد خودش را بدهید. تأیید در فرانسه، معادل آلمانی را تأیید نمی‌کند. هدف خالی به معنای «حل‌نشده» است، نه «به طور خودکار از مبدأ استفاده کن».
همین انضباط در داخل یک زبان نیز اعمال می‌شود. تصمیم‌های خاص زبان مقصد را وقتی به طور معناداری متفاوت هستند، جدا کنید. ردیف‌های تکراری را فقط برای افزودن برچسب‌های منطقه‌ای که چیزی را تغییر نمی‌دهند، ایجاد نکنید.
این وضعیت‌ها را ساده نگه دارید:
- پیش‌نویس: یک تصمیم نامزد یا مورد اختلاف؛ بخشی از خروجی تأییدشده نیست.
- تأییدشده: برای دامنه و نسخه اعلام‌شده پذیرفته شده است.
- منسوخ: برای تاریخچه و تشخیص نگه داشته می‌شود، اما برای کارهای جدید توصیه نمی‌شود.
برای یک تغییر اساسی، شکل قدیمی، شکل جدید، دلیل، نسخه مؤثر، مسئول و مکان‌های مبدأ تحت تأثیر را ثبت کنید. خروجی مربوطه را بازسازی کنید و به مترجمان بگویید کدام قطعه‌ها نیاز به بازنگری دارند. یک اصطلاح را در میانه پروژه بی‌سروصدا جایگزین نکنید و انتظار نداشته باشید که فصل‌های قبلاً ترجمه‌شده خودشان به‌روزرسانی شوند.
مدخل‌ها را زمانی بازبینی کنید که محصول، نسخه خطی مبدأ، استاندارد یا کاربرد پذیرفته‌شده تغییر می‌کند. یک یادآور تقویمی می‌تواند کمک کند، اما تعریف تغییر یافته محرک قوی‌تری است.
واژه‌نامه را پیش از گسترش، در قطعه‌های متن اعتبارسنجی کنید
یک واژه‌نامه می‌تواند درون خود مرتب باشد و باز هم در یک جمله شکست بخورد. از مجموعه کوچکی از قطعه‌های متن استفاده کنید که به‌طور عامدانه شامل این موارد باشد:
- یک واژه مبهم مبدأ با دو معنا؛
- یک اصطلاح به‌عنوان سرصفحه و درون متن؛
- یک صورت مفرد، جمع یا تغییر دستوری دیگر؛
- یک نام محافظت‌شده در کنار زبان عادی؛ و
- یک اصطلاح در جدول، عنوان، دستورالعمل یا ساختار مهم دیگر سند.
مثال قابل دانلود «delivery charge» را با «electric charge» جفت می‌کند و «seal» را هم به‌عنوان اسم و هم فعل می‌آورد. این موارد نشان می‌دهند چرا جایگزینی بدون دامنه، آزمون پذیرش نادرستی است.
برای هر قطعه متن، مبدأ، نسخه واژه‌نامه، خروجی مقصد، تصمیم بازبین و در صورت نیاز اصلاح را ثبت کنید. اگر واقعاً یک سرویس ترجمه را آزمایش می‌کنید، سرویس/مدل، تاریخ، تنظیمات و خروجی خام را اضافه کنید. مثال‌های این مقاله ادعا نمی‌کنند که چنین آزمون سرویسی انجام شده است.
پس از ترجمه کامل سند، به بازبینی یکدستی اصطلاحات بروید. ساخت واژه‌نامه سیاست را تعیین می‌کند؛ بازبینی خروجی مشخص می‌کند که آیا متن تحویل‌شده بدون غیرطبیعی شدن از آن پیروی می‌کند یا نه.
یک سابقه تصمیم تحویل دهید، نه فقط فهرست واژه
تحویل نهایی باید شامل نسخه مبدأ، واژه‌نامه اصلی تأییدشده، خروجی ابزار دریافت‌کننده در صورت وجود، گزارش پرسش‌های حل‌نشده و مثال‌های نماینده باشد. فردی که ترجمه را انجام می‌دهد باید بداند کدام فایل معتبر است و درباره تعارض‌ها از چه کسی بپرسد.
برای یک کتاب کامل یا سند بلند پشتیبانی‌شده، گردش‌کار ترجمه فایل BookTranslator می‌تواند پیش‌نویسی برای بازبینی بعدی فراهم کند. واژه‌نامه تأییدشده خود را در کنار آن پیش‌نویس نگه دارید. کاربرگ اینجا یک مرجع ویرایشی بیرونی است، نه ادعایی بر اینکه BookTranslator واژه‌نامه‌های CSV مدیریت‌شده توسط کاربر را وارد می‌کند یا هر مدخل را اعمال می‌کند.
با چند مفهوم مهم شروع کنید، تصمیم‌ها را قابل بررسی کنید و از ابهام واقعی یا یافته‌های بازبینی گسترش دهید. هدف، تصمیم‌های حل‌نشده کمتر در سند بعدی است—نه بزرگ‌ترین واژه‌نامه.
مطالب مرتبط
