۱۰ اشتباه رایج در ترجمه (و راه‌های جلوگیری از آن‌ها)

یک شعار بدترجمه‌شده ۱۰ میلیون دلار برای HSBC هزینه داشت. یک خطا در قالب تاریخ باعث نابودی ۵۰ هزار دلار تجهیزات کارخانه شد. ترجمه خودکار Facebook حتی به بازداشت یک نفر منجر شد. اشتباهات ترجمه فقط خجالت‌آور نیستند — واقعاً به کارها آسیب می‌زنند. اینجا ۱۰ مورد مشخص را می‌بینید، همراه با مثال‌های واقعی و اصلاح‌هایی که در چند ثانیه انجام می‌شوند.

1. ترجمه کلمه‌به‌کلمه اصطلاحات

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

❌ “It’s raining cats and dogs” → 「下猫下狗」(چینی تحت‌اللفظی: «گربه و سگ از آسمان می‌بارد»)

✅ 「倾盆大雨」(چینی: «باران سیل‌آسا») / “Il pleut des cordes” (فرانسوی: «طناب می‌بارد») / “Es regnet in Strömen” (آلمانی: «باران به‌صورت سیلابی می‌بارد»)

❌ “Break a leg” → 「رجل اكسر」(عربی: تحت‌اللفظی «یک پا بشکن»)

✅ 「بالتوفيق」(عربی: «موفق باشی») / «Ни пуха ни пера!» (روسی: معادل فرهنگیِ آرزوی موفقیت)

❌ شعار آبجوی Coors یعنی “Turn it loose” → در اسپانیایی به چیزی شبیه «اسهال گرفتن» تبدیل شد

✅ یک شعار بومی‌سازی‌شده که با گویشوران بومی بازار هدف تست شده باشد

❌ “To have other cats to whip” (فرانسوی: «avoir d’autres chats à fouetter») → در انگلیسیِ تحت‌اللفظی بی‌معنا می‌شود

✅ “To have other fish to fry” — معادل طبیعی آن در انگلیسی

چطور از آن جلوگیری کنیم: هر وقت به یک اصطلاح برخوردید، از خودتان بپرسید: «آیا این عبارت دقیقاً با همین معنا در زبان مقصد هم وجود دارد؟» اگر پاسخ منفی است — و تقریباً همیشه همین‌طور است — به‌جای ترجمه واژه‌ها، معادل محلی را پیدا کنید.

2. نادیده گرفتن رسمیت و register

در انگلیسی از “you” برای همه استفاده می‌شود. بیشتر زبان‌های دیگر این‌طور نیستند. استفاده از شکل نامناسب خطاب می‌تواند از کمی ناهنجار بودن تا کاملاً توهین‌آمیز بودن پیش برود — به‌ویژه در فضای کسب‌وکار، حقوقی و ارتباط با مشتری.

❌ ژاپنی: استفاده از あなた (anata) در خدمات مشتری. معنای لغوی‌اش «شما» است، اما در این بافت می‌تواند سرد و فاصله‌دار به نظر برسد.

✅ お客様 (okyakusama، «مشتری گرامی») یا نام مشتری + 様 (-sama)

❌ فرانسوی: استفاده از “Tu” به‌جای “Vous” در ایمیل کاری. لحن غیررسمی با کسی که نمی‌شناسید، گستاخانه به نظر می‌رسد.

✅ برای هر کسی که رابطه غیررسمی تثبیت‌شده‌ای با او ندارید، “Vous” را به‌کار ببرید. پیش‌فرض: رسمی.

❌ ایتالیایی: استفاده از “Tu” به‌جای “Lei” برای خطاب به مشتری. در ایتالیایی “Lei” شکل رسمی رایج است.

✅ “Lei” + فعل‌های سوم‌شخص در بافت رسمی و کاری

❌ کره‌ای: استفاده از 반말 (banmal، گفتار غیررسمی) در ایمیل کاری به‌جای 존댓말 (jondaenmal، گفتار مؤدبانه).

✅ مگر اینکه رابطه کاملاً دوستانه و غیررسمی باشد، از بالاترین سطح ادب (فرم‌های 합니다 / 합니까) استفاده کنید

چطور از آن جلوگیری کنیم: برای هر زبانی که به آن ترجمه می‌کنید، دو چیز را یاد بگیرید: تفاوت خطاب رسمی/غیررسمی، و register مورد انتظار مخاطب. اگر شک دارید، رسمی را انتخاب کنید — کمی بیش‌ازحد مؤدب بودن امن‌تر از بی‌ادب به نظر رسیدن است. در ژاپنی، کره‌ای و تایلندی، نظام‌های ادب بسیار پیچیده‌اند و machine translation به‌تنهایی از پس آن برنمی‌آید.

3. اشتباه گرفتن قالب تاریخ و عدد

فقط ایالات متحده و چند قلمرو محدود از MM/DD/YYYY استفاده می‌کنند. بیشتر جهان از DD/MM/YYYY یا YYYY-MM-DD استفاده می‌کند. اشتباه در این بخش فقط غیرحرفه‌ای به نظر نمی‌رسد — بلکه داده را هم خراب می‌کند.

❌ نوشتن 03/06/2026 در قراردادی برای مخاطب اروپایی. نویسنده ۶ مارس را مدنظر دارد؛ خواننده ۳ ژوئن می‌فهمد.

✅ “6 March 2026” یا “March 6, 2026” — قالب‌هایی بدون ابهام بین مناطق

❌ نوشتن 1,500.75 در سند آلمانی. در آلمانی جای ویرگول و ممیز عوض می‌شود: 1.500,75. در پرتغالی برزیلی هم همین‌طور است. در فرانسوی و ایتالیایی سوئیسی از آپاستروف استفاده می‌شود: 1’500.75.

✅ 1.500,75 (آلمانی/پرتغالی)، 1 500,75 (فرانسوی)، یا قالب‌بندی متناسب با locale

❌ فرض گرفتن اینکه همه از تقویم میلادی استفاده می‌کنند. عربستان در اسناد رسمی از تقویم هجری استفاده می‌کند. تایلند از تقویم بودایی (سال +۵۴۳) استفاده می‌کند. ژاپن هم سال‌های دوره امپراتوری را به‌کار می‌برد (Reiwa 8 = 2026).

✅ بررسی کنید مخاطب شما از چه سیستم تقویمی استفاده می‌کند

چطور از آن جلوگیری کنیم: تاریخ‌ها را در داخل سیستم با ISO 8601 ‏(YYYY-MM-DD) نگه دارید. سپس آن‌ها را در قالب مورد انتظار خواننده نمایش دهید. در اسناد ترجمه‌شده، نوشتن جمله‌ای مثل «تاریخ‌های این سند با قالب DD/MM/YYYY نمایش داده شده‌اند» بسیار مفید است. پنج ثانیه زمان می‌گیرد و روزها سردرگمی را کم می‌کند.

4. False friends: وقتی کلمات به شما دروغ می‌گویند

false friend کلمه‌ای است که در دو زبان یکسان یا تقریباً یکسان به نظر می‌رسد، اما معنی کاملاً متفاوتی دارد. خطرش دقیقاً در همین شباهت است: مترجم چیزی آشنا می‌بیند و دیگر مکث نمی‌کند تا بررسی کند.

واژه انگلیسی	دوست دروغین	زبان	معنی واقعی
embarrassed	embarazada	Spanish	باردار
actually	attualmente	Italian	در حال حاضر
gift	Gift	German	سم
sensible	sensibile	Italian	حساس
eventually	eventualmente	Portuguese	شاید / احتمالاً
library	librairie	French	کتاب‌فروشی
demand	talep etmek	Turkish	درخواست کردن
pain	pain	French	نان
magazine	магазин (magazin)	Russian	فروشگاه
brave	braaf	Dutch	مؤدب / سربه‌راه
location	location	French	اجاره
pretender	pretender	Portuguese	قصد داشتن

Parker Pens این را به سختی یاد گرفت: شعار انگلیسی‌اش می‌گفت این قلم “won’t leak in your pocket and embarrass you.” در ترجمه اسپانیایی، با اشتباه گرفتن embarazar به‌جای “embarrass”، جمله به چیزی شبیه «در جیب شما نشت نمی‌کند و شما را باردار نمی‌کند» تبدیل شد. false friends فقط یکی از راه‌هایی هستند که زبان‌ها مترجم را غافلگیر می‌کنند — در مجموعه واقعیت‌های شگفت‌انگیز زبانی نمونه‌های بیشتری از این دام‌ها داریم.

چطور از آن جلوگیری کنیم: برای هر جفت‌زبانی که با آن کار می‌کنید، یک glossary از false friendهای شناخته‌شده داشته باشید. آن‌ها را با هشدارهایی مثل “Do Not Translate” مشخص کنید. اگر در زبان مقصد کلمه‌ای بیش از حد آشنا به نظر رسید، مکث کنید و آن را بررسی کنید — خطر دقیقاً در همین شباهت است.

5. اعتماد کورکورانه به machine translation

Machine translation خیلی بهتر شده است — اما هنوز هم خطاهای مفهومی‌ای می‌کند که انسان نمی‌کند. در ژوئیه ۲۰۲۵، ترجمه خودکار Meta به‌اشتباه اعلام کرد که یک نخست‌وزیر ایالتی در هند «درگذشته است»، فقط چون او برای فرد دیگری پیام تسلیت نوشته بود. دفتر او این ابزار را «خطرناک» خواند و خواستار تعلیق آن برای Kannada شد.

نمونه‌های واقعی دیگر:

❌ عربی → عبری (Facebook, 2017): عبارت “Good morning” که مردی فلسطینی نوشته بود، به‌طور خودکار «به آن‌ها حمله کنید» ترجمه شد. پلیس اسرائیل پیش از مشخص شدن خطا او را بازداشت کرد.

✅ یک مترجم انسانی می‌فهمد که صباح الخير فقط یعنی «صبح بخیر».

❌ هندی → انگلیسی (Uber, 2025): “Mother Dairy ke samne hun” («من جلوی Mother Dairy هستم»، یک برند معروف هندی) به “I am facing the threat of murder.” تبدیل شد.

✅ مترجم باید تشخیص می‌داد که “Mother Dairy” نام برند است، نه واژه‌ای برای ترجمه.

❌ انگلیسی → فرانسوی (Montreal Transit, 2025): “Bishop Street” روی نقشه‌های اتوبوس توسط AI به “Beeshop” تبدیل شد.

✅ اسم‌های خاص ترجمه نمی‌شوند. انسان اصلاً چنین کاری نمی‌کند.

چطور از آن جلوگیری کنیم: machine translation یک پیش‌نویس است، نه محصول نهایی. هر چیزی که رو به مشتری، حقوقی، پزشکی یا حساس از نظر ایمنی باشد باید حتماً بازبینی انسانی شود. ابزارهای مختلف هم نقاط کور متفاوتی دارند — مقایسه OpenL و Google Translate نشان می‌دهد هر ابزار کجا بیشتر خطا می‌کند. قانون ساده است: اگر نتیجه اشتباه فقط خجالت باشد، شاید ریسک آن پذیرفتنی باشد. اگر مسئولیت حقوقی یا آسیب فیزیکی در میان است، نه.

6. کش‌آمدن متن و خراب شدن layout

زبان‌های مختلف مقدار متفاوتی فضا می‌گیرند. ترجمه از انگلیسی به آلمانی معمولاً متن را ۲۵ تا ۴۰ درصد بزرگ‌تر می‌کند. ایتالیایی و پرتغالی: ۱۵ تا ۳۰ درصد. فرانسوی و اسپانیایی: ۱۵ تا ۲۵ درصد. حتی زبان‌هایی با خط فشرده هم غافلگیرکننده‌اند — واژه‌های روسیِ سیریلیک به‌طور میانگین از معادل‌های انگلیسی‌شان بلندترند، و ترکیب‌های هلندی با آلمانی رقابت می‌کنند. رشته‌های کوتاه UI حتی شدیدتر رشد می‌کنند.

❌ یک دکمه “Submit” با عرض 80px. آلمانیِ “Absenden” بیرون می‌زند. ایتالیاییِ “Invia” جا می‌شود، اما روسیِ “Отправить” نه. ترکیِ “Gönder” هم می‌تواند layout را بشکند.

✅ دکمه‌ها را با حاشیه‌ای برای ۳۰٪+ گسترش طراحی کنید، یا از layoutهای منعطفی استفاده کنید که با محتوا رشد می‌کنند

❌ یک PDF با جعبه‌های متنی تنگ: هلندیِ “Sollicitatieformulier” (۱۷ کاراکتر) جای “Job Application” (۱۵ کاراکتر) می‌آید، اما آلمانیِ “Bewerbungsformular” (۱۹ کاراکتر) از صفحه بیرون می‌زند.

✅ قبل از نهایی‌سازی، layout را در همه زبان‌های مقصد بررسی کنید. در طراحی اولیه فضای خالی بگذارید

چطور از آن جلوگیری کنیم: در طراحی UI، آلمانی زبان stress-test خوبی است — اگر در آلمانی جا شد، احتمالاً در بیشتر زبان‌ها هم جا می‌شود. برای اسناد، همیشه بعد از ترجمه یک pass بازبینی layout انجام دهید. اگر در حال ترجمه PDF هستید، این مشکل حتی رایج‌تر است — راهنمای ما برای ترجمه PDF بدون از دست دادن قالب ابزارها و workflow لازم را توضیح می‌دهد. W3C توصیه می‌کند برای ترجمه از انگلیسی به زبان‌های اروپایی حداقل ۳۰ تا ۴۰ درصد گسترش فضا در نظر بگیرید.

7. ناهماهنگی در اصطلاحات

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

❌ در یک قرارداد حقوقی انگلیسی: صفحه ۱ می‌گوید “Service Agreement”، صفحه ۵ می‌گوید “Services Contract”، و صفحه ۸ می‌گوید “Terms of Engagement”. همه به یک سند اشاره دارند. خواننده می‌پرسد: این‌ها سه چیز متفاوت‌اند؟

✅ برای هر مفهوم یک اصطلاح انتخاب کنید و در کل سند و همه ترجمه‌هایش به همان پایبند بمانید

❌ ترجمه پزشکی ژاپنی (NIH, 2025): 「患者」 در یک پاراگراف “patient” ترجمه شده و در پاراگراف بعدی “case”، و این ابهام ایجاد کرده که آیا متن درباره همان فرد است یا نه

✅ برای اصطلاحات تخصصی glossary بسازید و آن را در سراسر پروژه enforce کنید

چطور از آن جلوگیری کنیم: قبل از شروع پروژه ترجمه، یک mini-glossary از ۱۰ تا ۲۰ اصطلاح مهم و ترجمه‌های تأییدشده‌شان بسازید. آن را با همه افرادی که روی سند کار می‌کنند به اشتراک بگذارید. ابزارهای translation memory که در پلتفرم‌های حرفه‌ای مثل OpenL وجود دارند، این کار را خودکار می‌کنند — به خاطر می‌سپارند که شما یک اصطلاح را چگونه ترجمه کرده‌اید و همان را دوباره به‌کار می‌برند.

8. ترجمه کردن نام‌هایی که نباید ترجمه شوند

اسم افراد، برندها، مکان‌ها و محصولات تقریباً هیچ‌وقت ترجمه نمی‌شوند. اما ابزارهای machine translation این را نمی‌دانند و حتی مترجم انسانی هم گاهی بیش‌ازحد اصلاح می‌کند.

❌ اسپانیایی → انگلیسی (سایت گردشگری مکزیک): “Tulum” شد “Jumpsuit”، “Acolman” شد “I Blame”، و “Progreso” شد “Progress.”

✅ نام مکان‌ها ترجمه نمی‌شوند. باید در شکل اصلی خود باقی بمانند.

❌ انگلیسی → چینی: “Palo Alto” → 「高木头」(«چوب بلند»). در حالی که این نام یک شهر است، نه انبار چوب.

✅ “Palo Alto（加州一城市）” — نام را نگه دارید و در صورت نیاز توضیح اضافه کنید

❌ روسی → انگلیسی: “Василий” → “Cornflower” (چون василёк یعنی گل cornflower). اما اینجا اسم شخص است: Vasily.

✅ “Vasily” — transliterate کنید، ترجمه نکنید

چطور از آن جلوگیری کنیم: این قانون را به checklist ترجمه اضافه کنید: «اسم‌های خاص، نام برندها، محصولات و مکان‌ها ترجمه نمی‌شوند.» اگر ابزار خودکار به نام‌ها دست زد، فوراً آن را flag کنید. این یکی از همان حوزه‌هایی است که ماشین‌ها مرتب در آن شکست می‌خورند و انسان‌ها نه.

9. نقاط کور فرهنگی

ترجمه بین فرهنگ‌ها انجام می‌شود، نه فقط بین زبان‌ها. یک ترجمه کاملاً دقیق هم اگر بافت فرهنگی مخاطب را نادیده بگیرد، ممکن است شکست بخورد.

❌ استفاده از رنگ سفید به‌عنوان رنگ عروسی برای مخاطب چینی یا هندی. در بسیاری از فرهنگ‌های شرق آسیا، سفید = مراسم خاکسپاری؛ قرمز = عروسی. در بخش‌هایی از غرب آفریقا، قرمز = سوگواری.

✅ پیش از نهایی کردن ترکیب متن و تصویر، نمادشناسی رنگ را در فرهنگ هدف بررسی کنید

❌ یک کمپین Ramadan برای بازیکنان خاورمیانه‌ای که در آن شخصیت‌ها با غذا و آبجو نشان داده شده بودند. در حالی که Ramadan دوره روزه‌داری است.

✅ اگر به رویداد فرهنگی یا مذهبی اشاره می‌کنید، با فردی از همان فرهنگ مشورت کنید

❌ استفاده از ایموجی thumbs-up برای مخاطبان خاورمیانه و غرب آفریقا — در بعضی مناطق این حرکت تقریباً معادل نشان دادن انگشت وسط است.

✅ در ارتباط بین‌فرهنگی، متن از ایموجی امن‌تر است. اگر از ایموجی استفاده می‌کنید، اول معنی آن را در فرهنگ مقصد چک کنید.

چطور از آن جلوگیری کنیم: برای هر کمپین یا سندی که وارد بازار جدید می‌شود، فقط یک سؤال بپرسید: «آیا فردی محلی در زنجیره بازبینی حضور دارد؟» اگر نه، یکی اضافه کنید. هزینه ۱۵ دقیقه review توسط گویشور بومی در مقایسه با جمع‌کردن و بازسازی یک کمپین شکست‌خورده تقریباً هیچ است.

10. Character encoding: وقتی “Krüger” می‌شود “Kr?ger”

این شاید کم‌زرق‌وبرق‌ترین اشتباه این فهرست باشد — و در عین حال یکی از رایج‌ترین‌ها. وقتی حروف دارای نشانه (é، ü، ñ، ç، ø)، کاراکترهای CJK یا متن سیریلیک با encoding اشتباه ذخیره یا منتقل شوند، به نویسه‌های خراب و نامفهوم تبدیل می‌شوند. اصطلاح فنی آن mojibake است.

❌ آلمانی: “Krüger” → “Kr?ger” (یا “Kr�ger” با نویسه جایگزین)

✅ “Krüger” — همیشه با UTF-8 ذخیره و منتقل کنید

❌ ژاپنی: 「翻訳」(«ترجمه») → ”�|��” در موضوع ایمیل

✅ 「翻訳」 — تنظیمات encoding را در email clientها و CMSها بررسی کنید

❌ روسی: “Россия” → “Ðîññèÿ” وقتی Windows-1251 به‌صورت ISO-8859-1 خوانده شود

✅ همیشه از UTF-8 استفاده کنید. این encoding همه‌چیز را پوشش می‌دهد: لاتین، سیریلیک، CJK، عربی، تایلندی — همه در یک استاندارد.

چطور از آن جلوگیری کنیم: همیشه از UTF-8 استفاده کنید — این استاندارد مدرن است و همه خط‌های رایج امروز را پشتیبانی می‌کند. قبل از ارسال یا آپلود متن ترجمه‌شده، یک بررسی بصری سریع انجام دهید: آیا نویسه‌های خاص درست دیده می‌شوند؟ هنگام export از Excel، صراحتاً “CSV UTF-8” را انتخاب کنید. اگر شک دارید، فایل را در یک ویرایشگر متن ساده باز کنید — اگر آنجا خراب است، همه‌جا خراب است.

مرور سریع: checklist ده‌ثانیه‌ای قبل از ارسال

قبل از اینکه یک ترجمه را ارسال، منتشر یا چاپ کنید، این چهار سؤال را مرور کنید:

1. Idioms: آیا عبارتی کلمه‌به‌کلمه ترجمه شده است؟ → با معادل محلی جایگزینش کنید.
2. Formality: آیا register برای مخاطب و بافت درست است؟ → اگر شک دارید، رسمی را انتخاب کنید.
3. Dates: آیا تاریخ‌ها در قالب مورد انتظار خواننده هستند؟ → قالب را صریح بنویسید.
4. Names: آیا نام خاصی «ترجمه» شده است؟ → اصل آن را برگردانید.

ده ثانیه. چهار سؤال. همه چیز را نمی‌گیرد، اما اشتباهاتی را می‌گیرد که تیتر می‌شوند.

FAQ

آیا ChatGPT / Claude این اشتباهات را خودکار برطرف می‌کنند؟

نه به‌صورت قابل اتکا. LLMها در مدیریت idiomها و register از machine translation قدیمی بهترند، اما هنوز false friendها را اشتباه می‌گیرند، هنوز اسم‌ها را بد ترجمه می‌کنند، و هنوز judgment فرهنگی واقعی ندارند. آن‌ها نمی‌دانند “Mother Dairy” یک برند است — فقط دو کلمه می‌بینند و ترجمه‌شان می‌کنند. خروجی LLM را هم مانند هر ترجمه ماشینی دیگری ببینید: پیش‌نویس قوی، اما نیازمند بازبینی انسانی.

برای جلوگیری از این اشتباهات، تفاوت ابزار رایگان با مترجم حرفه‌ای پولی چیست؟

ابزارهای رایگان یک ترجمه خام تحویل می‌دهند. مترجمان حرفه‌ای و پلتفرم‌های حرفه‌ای مثل OpenL این‌ها را اضافه می‌کنند: مدیریت اصطلاحات برای جلوگیری از ناهماهنگی، حفظ format برای جلوگیری از شکستن layout، و درک بافت برای تشخیص idiomها و false friendها. این فاصله در خطاهای #1–5 (اصطلاحات، register، false friendها و ظرافت فرهنگی) بیشترین نمود را دارد. در خطای #10 کمتر است، چون ابزارهای خوب در هر دو سرِ ماجرا UTF-8 را خوب مدیریت می‌کنند.

کدام اشتباه بیشترین هزینه را دارد؟

خطای #5 (اعتماد کورکورانه به خروجی خودکار) به‌طور مداوم پرهزینه‌ترین شکست‌ها را ایجاد می‌کند. ری‌برند ۱۰ میلیون‌دلاری HSBC، نابودی ۵۰ هزار دلار تجهیزات، و ماجرای اعلام دروغین مرگ یک سیاستمدار زنده توسط Meta، همگی از انتشار machine translation بدون بازبینی انسانی آمده‌اند. راه‌حل — این‌که قبل از انتشار یک انسان خروجی را بخواند — چند دقیقه زمان می‌خواهد و ممکن است میلیون‌ها صرفه‌جویی کند.

Sources

• PMC/NIH: Errors in Japanese–English AI-assisted translation (2025) — دسته‌بندی خطاهای ترجمه پزشکی ژاپنی–انگلیسیِ کمک‌گرفته از AI
• STAR Translation: When Translation Goes Wrong — نمونه‌های واقعیِ خطاهای ترجمه در پزشکی، برندسازی و تابلوها
• POEditor: 6 Famous Mistranslations in Localization — نمونه‌های مشهور مربوط به HSBC، Pepsi، KFC و دیگر برندها
• Meta apologizes after auto-translation mistakenly announces Indian state chief minister’s death (CNN, July 2025) — نمونه‌ای از اعلام اشتباه مرگ یک سیاستمدار زنده توسط ترجمه خودکار Meta
• Uber auto-translation: “Mother Dairy” becomes “threat of murder” (Livemint, 2025) — خطای ترجمه خودکار از هندی به انگلیسی
• Montreal Transit: AI labels Bishop Street bus stop as “Beeshop” (CTV News, 2025) — شکست AI در ترجمه تابلو و نام خیابان
• Goethe-Institut: Oh Heavenly Berry — false friend stories from German learners — داستان‌هایی درباره false friendها
• W3C: Text Size in Translation — مرجع معتبر درباره رشد اندازه متن در ترجمه
• SandVox: Text Expansion in Localization — نرخ گسترش متن در زبان‌های مختلف
• Lingoda: False Friends in Languages — جدول false friendها در جفت‌زبان‌های اصلی
• Ulatus: Lessons from Marketing Localization Failures — شکست‌های بازاریابی محلی‌سازی و نقاط کور فرهنگی
• Forbes: Why Global Brands Fail When They Communicate Locally (Feb 2026) — نگاه راهبردی به شکست برندها در ارتباط محلی