برای تبدیل دنیای واقعی به یک چکیده‌ی دیجیتالی، دانستن فرایند خلاصه‌نویسی ضروری است و توسعه‌دهندگان هم مانند مترجمان ادبی باید این فرایند را یاد بگیرند. اما منظور از عمل ترجمه چیست؟ اومبرتو اکو (فیلسوف و نشانه‌شناسی از قرن بیستم) ترجمه را به‌صورت خلاصه این چنین تعریف می‌کند: بیان نکته‌ای به زبانی دیگر.

تشبیه، ابزار قدرتمندی برای حل مسائل جدید و یافتن راه‌حل‌های خلاقانه برای آن‌ها است؛ بنابراین از تشبیهبرنامه‌نویسی به ترجمه چه می‌توان آموخت؟ برای مثال، برنامه‌نویسی، مسائل دامنه‌ای (مثل موجودی انبار سخت‌افزار، یک کاتالوگ کتابخانه‌ی عمومی، سیستم رزرو بلیت) را به برنامه‌های کامپیوتری ترجمه می‌کند.

تطبیق سیستم دنیای واقعی با دنیای دیجیتالی به معیارهای متعددی وابسته است. برای تبدیل داده‌های آنالوگ به داده‌های دیجیتال، فرایند گسسته‌سازی یا تجزیه لازم است؛ اما تجزیه و گسسته‌سازی مفاهیم به انحراف‌ در معنا وابسته هستند؛ اما این سؤال مطرح می‌شود که مترجم‌های معمولی چگونه مشکل انحراف یا دوگانگی معنایی را حل می‌کنند؟ برنامه‌نویس‌ها چه درس‌هایی می‌توانند از آن بگیرند؟

کتاب، جلد، دستورالعمل، جنسیت

با مثال کتابخانه‌ی داده‌ها و واقعیت از ویلیام کنت، می‌توان به سؤال‌های فوق پاسخ داد. در ابتدا لازم است مفاهیم اصلی دامنه‌ی موردنیاز مشخص و سپس به زبان طبیعی ترجمه شوند. سپس، یک مجموعه‌ی واژگان از دامنه‌ی موردنظر ساخته شود. در این نمونه مجموعه‌ی واژگان شامل کتاب‌ها، مؤلف‌ها، ناشر‌ها، ژانرها و موارد دیگر است.

با مجموعه‌ی واژگان می‌توان مفاهیم را به یک زبان برنامه‌نویسی برگرداند و چکیده‌هایی قابل‌درک را برای کامپیوتر ساخت؛ اما چگونه می‌توان فهمید، کدام یک از مفاهیم واقعی باید به خلاصه‌های برنامه‌نویسی تبدیل شوند؟

در ساخت نرم‌افزار کتابخانه‌ای می‌توان فرض کرد یک کتاب برابر با یک انتزاع یا شیء داخل برنامه باشد؛ اما یک کتاب از چه مواردی تشکیل شده است؟ اگر مؤلفی مثل جودی واکمن جامعه‌شناس، دو کتاب منتشر کرده باشد، پایگاه داده‌ی کتاب‌شناسی، دو شاخص از یک کتاب را در محتوای خود خواهد داشت (برای مثال TechnoFeminism و Feminism Confronts Technology).

در مورد ساخت پایگاه داده برای قرض کتاب چه می‌توان گفت؟ اگر یک کتابخانه پنج کپی از دو کتاب را بخرد، به‌معنی وجود ده رکورد کتاب در پایگاه داده است. معنای کتاب، براساس زمینه هم تغییر می‌کند: در پایگاه داده‌ی کتاب‌شناسی، بر عناوین مجزا تفکیک می‌شوند؛ درحالی‌که پایگاه داده‌ی قرض کتاب به تعداد کل کپی‌های کتابخانه اشاره دارد.

مجموعه‌ی چهارجلدی هنر برنامه‌نویسی کامپیوتری اثر دونالد نوت را چگونه می‌توان در یک کتابخانه توصیف کرد؟ این مجموعه را باید یک کتاب به شمار آورد یا چهار کتاب مجزا؟ در مورد نسخه‌ی سه‌گانه‌ی ارباب حلقه‌ها چه می‌توان گفت که سه کتاب در یک کتاب قرار دارد؟ (طبق درخواست تالکین). مسئله‌ای که در ابتدا ساده به نظر می‌رسید (کتاب، یک کتاب است) حالا پیچیده و پر از جزئیات شده است.

طبقه‌بندی، کار ساده‌ای نیست. در نمونه‌ی کتاب‌ها یک طبقه‌بندی نادرست، جستجوی عنوان و دسترسی به اطلاعات کتاب را محدود می‌کند. سیستم‌های طبقه‌بندی بدون انعطاف و دارای انحراف می‌توانند تأثیرگذاری مؤلف را کاهش دهند. برای مثال در بعضی کشورها، نام خانوادگی زنان پس از ازدواج، به نام خانوادگی همسر آن‌ها تغییر می‌کند.

یکی از پیشتازان علم کامپیوتر، کاتلین بوت نی بریتن در سال ۱۹۴۷ مقاله‌ای با عنوان معرفی اولین زبان اسمبلی: بریتن نوشت اما با نام خانوادگی همسر خود، بوت، کتاب را منتشر کرد. اگر پایگاه‌داده‌ای آثار منتشرشده را براساس نام تولد و نام تأهل او به هم لینک نکند، آن وقت ممکن است شخص در جستجوی مقاله‌های شخص اشتباه کند و به این صورت تأثیرگذاری او دست‌کم گرفته شود. همین اتفاق هنگام جستجوی مقاله‌های باربارا لیسکف (نی هوبرمن) هم رخ می‌دهد.

وقتی شخصیت به میان می‌آیند، تعریف انتزاع برنامه‌نویسی دشوارتر می‌شود. حالا فرض کنید دراین‌میان بحث جنسیت هم مطرح شود، چه اتفاقی رخ می‌دهد؟ براساس مقاله‌ی جدیدی در مورد تشخیص جنسیت خودکار (AGR)، درنظر گرفتن جنسیت به‌صورت ارقام دودویی می‌تواند پیامدهای مخربی برای افراد داشته باشد (برای مثال خشونت جنسی، اشتباه جنسیتی یا حذف هویت را به‌دنبال دارد). در نتیجه، بسیاری از روش‌های AGR، مفهوم جنسیت را به درستی توضیح نمی‌دهند.

آیا در خلاصه‌سازی یا ساخت انتزاع یک شخص، فرض می‌شود جنسیت او در طول زندگی تغییر نمی‌کند؟ آیا جنسیت یک معیار روانشناختی است یا ویژگی‌های فیزیکی، فاکتور تفکیک جنسیت هستند؟ اگر در این روش‌ها جنسیت به‌صورت یک دسته‌بندی ظاهر نشود، چگونه می‌توان به تفسیر نتایج پرداخت؟ به‌طورکلی می‌توان گفت ترجمه‌ی مفاهیم جهان واقعی به مفاهیم نرم‌افزاری آن‌قدر هم که به نظر می‌رسد، آسان نیست.

مقصود متن در ترجمه

ترجمه اساسا همان عمل تفسیر است. وقتی مترجم‌ها می‌خواهند متنی را به یک زبان دیگر تبدیل کنند، درواقع به‌جای یک نسخه‌ی تحت‌اللفظی یا المثنی به‌دنبال تفسیری از نسخه‌ی اصلی هستند؛ اما این سؤال مطرح می‌شود که چه فاکتورهایی برای درک متن اصلی لازم است؟

امبرتو اکو به این مسئله، بیان همان چیز می‌گوید. او معتقد است تشخیص هسته‌ی یک متن یا بنیادی‌ترین عنصر آن، غیرممکن است. رمان مشهور اکو: نام گل سرخ (۱۹۸۰) با ادسو ملک، کشیش سده‌های میانه آغاز می‌شود که انجیل را از حفظ می‌خواند و مرتکب اشتباهاتی هم می‌شود. یک مترجم انگلیسی متوجه می‌شود منظور از چیز در متن کتاب همان انجیل است نه اشتباه آدسو؛ اما مترجم به‌جای ترجمه‌ی جملات از زبان آدسو (همان‌طور که اکو نوشته است)، جملات را به‌صورت تحت‌اللفظی و همان‌طور که در انجیل ظاهر می‌شوند، ترجمه می‌کند.

در این رمان با نثر بازی می‌شود (کشیش قرن چهاردهم که می‌تواند انجیل را از حفظ بخواند). صرف‌نظر از اینکه خطاهای موجود در متون انجیل به‌پای اکو یا آدسو نوشته شوند، این خطاها می‌خواهند پیامی را منتقل کنند اما این پیام کاملا در ترجمه گم شده است. مترجم با ارجاع کلمه‌ی چیز به انجیل، روح اثر را از بین برده است.

اما این تنها ناهنجاری موجود در ترجمه‌ی متون نیست: مترجم‌ها صرفا برای ابعاد مشخصی از متن، اولویت بیشتری قائل هستند. قدیمی‌ترین نسخه‌ی اودیسه‌ی هومر با وزن dactylic hexameter (وزن شعر حماسی یونان باستان، dactylic به‌معنی دو هجای با تأکید و هجای سوم بدون تأکید، hexameters به‌معنی ۶ پایه) نوشته شده است. امروزه، اغلب مترجم‌ها شعر را بدون درنظر گرفتن نظم آن، به نثر روان تبدیل می‌کنند.

امیلی ویلسون، پژوهشگر آثار کلاسیک که نسخه‌ی اودیسه‌ی او در سال ۲۰۱۸ منتشر شد، با این روش مخالف است. به اعتقاد او حماسه‌ی هومر شعری است که ترجمه‌ی آن باید قابل پیش‌بینی و دارای ریتم مشخص باشد. ازاین‌رو از وزن Iambic Parameter (وزنی در ادبیات انگلیسی، iambic به‌معنی هجای اول بدون تأکید، هجای دوم با تأکید pentameter به‌معنی پنج‌پایه) استفاده می‌کند که وزن رایج در ادبیات انگلیسی است.

این انتخاب نشان‌دهنده‌ی باورها و اولویت‌های ویلسون است. بعضی مترجم‌ها تنها بر محتوا متمرکز هستند تا فرم (رسیدن به معنای دقیق کلمات و عبارت‌ها) و معتقدند اگر خطوط را در یک ساختار شعری مشخص قرار دهند، معنا دچار انحراف می‌شود اما به عقیده‌ی افرادی مثل ویلسون، فرم هم به همان اندازه‌ اهمیت دارد.

حالا دوباره به مثال جنسیت برمی‌گردیم، در این مثال کل تعاریف و مفاهیم جنسیت به صفر و یک‌های دیجیتالی تبدیل می‌شوند؛ اما این سؤال‌ها مطرح می‌شود که در چه تعداد از وب‌سایت‌ها، توسعه‌دهندگان ویژگی‌هایی مثل نام، تاریخ تولد و جنسیت را به‌عنوان ویژگی‌های اصلی معرفی یک شخص درنظر می‌گیرند؟ و تا چه اندازه از گزینه‌های دودویی مرد یا زن، برای معرفی جنسیت استفاده می‌شود؟ آیا این روش ترجمه‌ی شخصیت افراد، مبنای صحیحی دارد؟

 جودیث بوتلر در مقدمه‌‌ی در باب علم نوشتار، اثر ژاک دریدا (فیلسوف و زبان‌شناس قرن بیستم) می‌نویسد: یک ترجمه نه‌تنها زبان مقصد را دستکاری می‌کند و به آن اضافه می‌کند بلکه بر زبان مبدأ خود هم تأثیرگذار است. ژان بودریار (فیلسوف و زبان‌شناس قرن بیستم) در رساله‌ی خود با عنوان وانموده‌ها و وانمایی‌ها یادآوری می‌کند: انتزاع امروزی دیگر نقشه‌‌ی راه، آینه یا مفهوم نیست. امروزه دیگر قلمرو از نقشه بزرگ‌تر نیست. بلکه این نقشه است که از قلمرو هم فراتر می‌رود. به همین ترتیب در نمونه‌ی گزینه‌های دودویی جنسیت، بخشی از نوع بشر ادغام یا حذف می‌شود زیرا مترجم (برنامه‌نویس) تمرکز خود را بر یک مفهوم دیگر (تفکیک دو جنس) گذاشته است.

کلمه، ترجمه‌ی افکار شما نیست

اصطلاح برنامه‌نویسی به‌مثابه ترجمه بعدها به‌دلیل افزایش مفاهیم زبان‌های برنامه‌نویسی و خود زبان انگلیسی، شکل پیچیده‌تری به خود گرفت. کلمات به‌کاررفته در برنامه‌ها در ظاهر مشابه کلمات زبان انگلیسی هستند اما معنای یکسانی را منتقل نمی‌کنند.

در مکالمه‌ی معمولی انگلیسی، کاربر به شخصی گفته می‌شود که با یک برنامه (شیء یا ساختار) کار می‌کند و دارای ویژگی‌های متعدد است. معمولا در گفت‌وگو با مشتری در مورد کاربران هم بحث می‌شود. هر برنامه دارای یک گروه کاربر است که نماینده‌ی اشخاص جهان واقعی و مصرف‌کنندگان آن هستند.

با پیشرفت گفت‌وگو، کلمه‌ی کاربر دستخوش تکامل می‌شود: برای مثال از توصیف کاربران یک وب‌سایت (ازجمله مشتریان یا تاجرها) تا یک زیرمجموعه‌ی مشخص (مشتریان به‌غیر از تاجرها) را در برمی‌گیرد. صرف‌نظر از اینکه کاربر را در ابتدای کار چگونه توصیف می‌کنید، اگر بخواهید تغییر در تعریف کاربر اعمال کنید، باید کد مرتبط با آن را هم به‌روزرسانی کنید تا برای برنامه قابل‌درک باشد.

کلمه‌ی کاربری که در مکالمه‌ی روزمره به کار می‌رود، به‌معنی یک شخص واقعی است اما کلمه‌ی کاربر در کد لزوما به این معنی نیست. درواقع یک اصطلاح کدنویسی ممکن است صرفا نشان‌دهنده‌ی ویژگی‌های موردنظر یک توسعه‌دهنده باشد.

این تعریف برای توسعه‌دهندگان دیگر یا حتی برای خود برنامه‌نویس که در آینده به کد خود مراجعه می‌کند، می‌تواند معنای متفاوتی داشته باشد یا ممکن است توسعه‌دهنده در مورد معنای کاربر در جهان واقعی در مقابل معنای آن در یک متن برنامه دچار ابهام شود. وقتی برنامه‌ای را می‌خوانید، سعی می‌کنید مفهوم اصلی آن را دریافت کنید و آن را در جهان واقعی تصور کنید؛ اما گاهی این کار امکان‌پذیر نیست.

دریدا این مشکل را به یک ساختمان خرابه تشبیه می‌کند. وقتی شخصی سعی می‌کند برنامه را به یک فرم بامفهوم ترجمه کند، مانند باستان‌شناسی است که سعی می‌کند ظاهر اولیه‌ی یک بنای مخروبه را از روی شکل امروزی آن حدس بزند. در دنیای برنامه‌نویسی، این مشکل در کار با کدهای وراثتی تشدید می‌شود.

به‌عنوان یک برنامه‌نویس همیشه باید از خود بپرسید: چگونه می‌توان موجودیت‌های داخل کد را نمایش داد؟ اگر تصمیم بگیرید کد را در آینده بخوانید، آیا می‌توانید به‌صورت مسئله‌ پی ببرید؟ چگونه می‌توان این کد را با دنیای واقعی تطبیق داد؟ همان‌طور که اکو هم اشاره می‌کند، این کار به‌هیچ‌عنوان ساده نیست. پس چاره چیست؟

انعطاف در یافتن معنا

خوشبختانه اکو، راه‌حلی برای این مشکل پیشنهاد می‌دهد. به‌جای بیان همان نکته، او مترجم را تشویق می‌کند که از مفهوم تقریبی استفاده کند. معرفی یک کلمه‌ی توصیفی در اینجا ضروری است. اکو در Dire Quasi la Stessa Cosa می‌گوید:

زمین تقریبا مشابه مریخ است، هر دو به دور خورشید می‌چرخند و هر دو شکل بیضی دارند اما از آنجا که هر دو مانند کره هستند، می‌توان آن‌ها را با پرتقال یا توپ فوتبال هم مقایسه کرد.

با تعریف پارامتر تقریبا می‌توان به یک نوع دادوستد یا مبادله در برنامه‌نویسی رسید. در برنامه‌نویسی هم نیاز به تعریف یک عنصر مشابه و انعطاف‌پذیر است. افراد معمولا طی مکالمه‌ها انعطاف‌پذیر هستند و به تطبیق و دادوستد کلمات در حین صحبت می‌پردازند.

استیون سی. اسکینا، الگوریتمی برای ارزان‌ترین پرواز شهر X به شهر Y طراحی کرد. او برای تبدیل این مسئله‌ی جهان واقعی به برنامه از الگوریتم کوتاه‌ترین مسیر دکسترا استفاده کرد (این الگوریتم به یافتن کوتاه‌ترین مسیر ممکن بین دو گره از یک گراف می‌پردازد). او باید یک مسئله‌ی گرافی را حل می‌کرد اما مشتری‌ها متوجه شدند اسکینا یک مسئله‌ی مهم را از قلم انداخته است: قوانین هوانوردی و هواپیمایی.

آن‌ها اسکینا را قانع کردند که از روش دیگری برای حل مسئله استفاده کند و اسیکنا هم روش صف اولویت را انتخاب کرد؛ بنابراین باید راه‌حل قبلی را کنار می‌گذاشت و بر یادگیری یک راه‌حل جدید و جایگزین تمرکز می‌کرد. علاوه‌بر این، راه‌حل او برای پاسخگویی به نیازهای مشتری از سرعت کافی هم برخوردار بود؛ بنابراین او مفهوم تقریبا همان چیز را برای حل مسئله درک کرد.

همین ایده را می‌توان بر مسئله‌ی جنسیت یا ایده‌ی کاربر اعمال کرد؛ بنابراین باید با این نگرش که تغییر و تطبیق اجتناب‌ناپذیر هستند، به کدنویسی پرداخت.

نتیجه‌گیری

بنابراین با درنظر گرفتن برنامه‌نویسی به‌مثابه ترجمه، چه می‌توان آموخت؟ از دیدگاه تجاری، روش‌های زیادی برای ترجمه‌ی جهان واقعی به برنامه وجود دارد. تشخیص صحیح مسئله به حل سریع و مستقیم آن کمک می‌کند.

از دیدگاه برنامه‌نویسی، ترجمه‌ی جهان واقعی، چشم‌انداز‌های یا نسخه‌های احتمالی را در ذهن توسعه‌دهندگان به وجود می‌آورد و در حل مسئله این پرسش‌ها مطرح می‌شود: آیا انتزاع‌ها یا چکیده‌ها به‌درستی انتخاب شده‌اند؟ آیا برنامه‌نویس‌ها روی بخش صحیحی از مسئله تمرکز کرده‌اند؟

از دیدگاه هنجاری و اخلاقی، ترجمه‌ی جهان واقعی و تبدیل آن به کد، بر موجودیت‌های جهان واقعی (که در برنامه نمایش داده شده‌اند) و همین‌طور کاربرهایی که با این موجودیت‌ها در ارتباط هستند، تأثیر می‌گذارد. در مثال کتابخانه، طبقه‌بندی اشتباه کتاب‌ها یا نویسنده‌ها، دسترسی به اطلاعات را غیرممکن می‌سازد. اشتباه در زندگی یا ویژگی‌های افراد هم (مثال جنسیت) تأثیرگذاری مؤلف را بالا می‌برند و احتمال اشتباه را بالا می‌برد.

بهترین ترجمه‌ها، با اعمال تغییراتی در متن اصلی ممکن می‌شوند. بهترین برنامه‌ها هم چکیده‌های ضروری از واقعیت هستند و مسئولیت بهبود واقعیت قابل‌نمایش بر عهده‌ی برنامه‌نویس‌ها است.