تصور کنید ۳۸۹ کلید متنی در سه زبان مختلف و تغییر در ۱۲۲ فایل را تنها در یک جلسه کاری مدیریت کنید. این دقیقاً همان اتفاقی است که در ۱۱ سپتامبر ۲۰۲۶ رخ داد؛ زمانی که یک توسعه‌دهنده برای بومی‌سازی اپلیکیشن Parlotype — یک برنامه تبدیل گفتار به متن ساخته شده با .NET 10 و Avalonia 12 — از ابزار Claude Code استفاده کرد.
بومی‌سازی (Localization) — شبیه به ترجمه یک کتاب که در آن باید دقت کرد اندازه کلمات در صفحه جدید جا شود — معمولاً زمانی شکست می‌خورد که برنامه‌نویسان ابتدا متن‌ها را استخراج و سپس بررسی می‌کنند. در این پروژه، ترتیب برعکس بود. توسعه‌دهنده ابتدا حفاظ‌ها (Guardrails) — مانند اسکریپت‌های تطبیق و تست‌های xUnit — را ساخت و سپس سراغ جابجایی ۴۵۰ کلید متنی رفت. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، اعتماد کورکورانه به خروجی مدل‌های زبانی ریسک بالایی دارد؛ به همین دلیل در اینجا از عامل (Agent) هوش مصنوعی به عنوان یک موتور با توان عملیاتی بالا اما مستعد «انحراف» استفاده شد. این رویکرد با روندی همسو است که در آن سهم مهارت‌های غیرانگلیسی در عامل‌های هوش مصنوعی برای مدیریت بهتر زبان‌های متنوع در حال رشد است.
طبق مستندات این پروژه، معماری حفاظ‌ها شامل لایه‌های زیر بود:
- اسکریپت‌های تطبیق: یک اسکریپت PowerShell برای اطمینان از یکسان بودن کلیدها و جای‌گذارهای
{0}در تمام زبان‌ها. - درگاه‌های انتشار: استفاده از xUnit برای مسدود کردن هر بیلد (Build) که دارای کلیدهای گم‌شده باشد.
- قلاب‌های عامل: تنظیماتی در
.claude/settings.jsonکه باعث می‌شد عامل بلافاصله پس از هر تغییر، اسکریپت تطبیق را اجرا کند. - فایل‌های مهارت: یک سند راهنما در
.claude/skills/localization/SKILL.mdبرای آموزش مدل درباره نحوه نام‌گذاری کلیدها. - ردیابی خط پایه: سیستمی برای اطمینان از اینکه تعداد متون سخت‌افزاری (Hardcoded) در فایل‌های
.axamlهرگز افزایش نیابد.
یکی از چالش‌های فنی، پیاده‌سازی تغییر زبان در لحظه (Live-switching) در Avalonia 12 بود. توسعه‌دهنده برای حل تضاد بین Bindings کامپایل‌شده و نیاز به تغییر پویا، کلاس TrExtension را طراحی کرد. این معماری از Localizer.Entry(key) استفاده می‌کند که هر کلید را به یک شیء LocalizedString متصل می‌کند. به این ترتیب، وقتی زبان تغییر می‌کند، تنها یک اعلان (Notification) ارسال می‌شود، نه یک پخش سراسری در کل برنامه.
در لایه مارک‌آپ، پیاده‌سازی ساده است: <TextBlock Text="{loc:Tr Settings_Theme_Title}" />. دو تصمیم کلیدی در اینجا گرفته شد: جداسازی فرهنگ رابط کاربری (UI Culture) از فرهنگ سیستمی برای حفظ فرمت تاریخ و اعداد کاربر، و تولید کمکی‌های تایپ‌شده (Typed Helpers) در Strings.cs برای جلوگیری از خطاهای زمان اجرا.
از نظر معماری، Parlotype.Core بدون وابستگی باقی ماند تا جهت وابستگی‌ها معکوس نشود. اما چون Core باید جملاتی مثل خطاهای ارائه‌دهنده ابری را بسازد، از یک الگوی تفکیک استفاده شد: Core دلیل خطا را به صورت داده (Enum) تعریف می‌کند و لایه Desktop کلمات واقعی را انتخاب می‌کند. برای جلوگیری از نقاط کور در این بخش، تست‌هایی نوشته شد که بررسی می‌کرد خروجی نهایی در زبان روسی حتماً شامل حروف سیریلیک باشد.
با وجود این همه سخت‌گیری، سه نقص سیستمی به محیط تولید راه یافتند:
۱. کوری‌سنج‌های نابینا: اسکنر متون سخت‌افزاری با استفاده از Regex کار می‌کرد اما برخی ویژگی‌ها مثل OnContent را نادیده می‌گرفت. همچنین متونی که بین تگ‌ها (Element Content) بودند، هرگز بررسی نشدند. در نهایت، نویسه‌های XML مثل ✕ به دلیل داشتن حرف 'x' به اشتباه به عنوان متن قابل ترجمه شمرده شدند.
۲. ترکیبات قدیمی در C#: در ۶ نقطه از برنامه، متون در View Modelها با کد C# ترکیب شده بودند. این مقادیر درست محاسبه می‌شدند اما چیزی به View دستور نمی‌داد که آن‌ها را دوباره بخواند. برای حل این مشکل، نیاز بود متد OnCultureChanged بازنویسی شود یا یک Enum برای وضعیت‌ها (مانند Ready یا Recording) تعریف گردد تا متن بر اساس وضعیت فعلی بازسازی شود.
۳. غفلت مستند شده: تولتیپ دکمه ضبط («Hold Right Ctrl to talk») انگلیسی باقی ماند. این مورد حتی در مستندات معماری به عنوان «به عمد انگلیسی» ثبت شده بود و تنها از طریق گزارش یک کاربر و یک اسکرین‌شات شناسایی شد.
این تجربه ثابت می‌کند که عامل‌های هوش مصنوعی توان عملیاتی خیره‌کننده‌ای دارند؛ آن‌ها برنامه، ADR، ژنراتور، تست‌ها و حتی اصلاحات را نوشتند. برای بهینه‌سازی این فرآیند و کاهش هزینه‌های عملیاتی، برخی توسعه‌دهندگان از لایه‌های پیش‌پردازش محلی برای کاهش توکن‌های Claude Code استفاده می‌کنند تا کارایی سیستم افزایش یابد. اما نکته تکان‌دهنده این است که عامل هرگز متوجه «اشتباه بودن» برنامه نشد. تمام نقص‌ها توسط انسان و از طریق مشاهده اسکرین‌شات‌ها یا بررسی کد شناسایی شدند.
گام بعدی شما
- هنگام استفاده از عامل‌ها برای مهاجرت‌های انبوه کد، هر حفاظ (Guardrail) را با ایجاد خطای عمدی تست کنید تا از «سبز بودن کاذب» تست‌ها مطمئن شوید.
- تایید بصری (Visual Verification) را اجباری کنید؛ تست‌های سبز تنها یک فرضیه هستند، اما خروجی UI حقیقت است.
- به جای دستورات کلی مثل «متن‌ها را استخراج کن»، معیارهای پذیرش دقیق بدهید: «پنجره باید کاملاً روسی باشد و با مشاهده بصری تایید شود».
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو