گردش‌کار بومی‌سازی کاتالوگ محصول

پیش از ترجمه منبع را منجمد کنید

کاتالوگ را export و snapshot تغییرناپذیر منبع را حفظ کنید. منشأ، زمان export و revision یا hash فایل را ثبت کنید. به هر variant هویت پایدار بدهید و پیش از ساخت کارهای زبانی، شناسه مفقود یا تکراری را بررسی کنید. manifest جفت‌های محصول-زبان مورد پردازش را نگه دارید.

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

واقعیت‌های محافظت‌شده را از متن قابل‌ویرایش جدا کنید

برای SKU، قیمت، ارز، واحد، رابطه variant و دیگر مقدارهای عملیاتی رکورد محافظت‌شده بسازید. فقط patch متن را تولید کنید. هنگام assembly مقادیر محافظت‌شده را مستقیم از منبع کپی و دوباره مقایسه کنید تا مدل مرجع فیلدی نشود که فقط آن را به‌عنوان زمینه دیده است.

ادعاها را هم قابل‌ردیابی کنید. گزاره‌های تأییدشده را به شواهدشان وصل و به مرحله پیش‌نویس بگویید هر مورد پشتیبانی‌نشده را علامت بزند. پیکربندی زیر policy نمونه pipeline است، نه فایلی که Shopify یا WooCommerce می‌پذیرد. آداپتور شما باید آن را به قرارداد واقعی مقصد نگاشت کند.

{
  "identity": ["product_id", "variant_id", "locale"],
  "protected": ["sku", "price_minor", "currency", "unit", "parent_id"],
  "editable": ["title", "description", "care_text"],
  "revisionInputs": ["source", "glossary", "prompt"],
  "releaseRequires": ["field_checks", "fact_review", "language_review"],
  "destinationWrite": "separate_authorization"
}

واژه‌نامه و brief locale را متصل کنید

brief locale باید مخاطب، لحن، اصطلاحات تأییدشده و قواعد ارائه را مشخص کند. مفهوم محصول را از املای ترجیحی جدا نگه دارید. W3C ITS فراداده اصطلاح و ترجمه‌ای را تعریف می‌کند که می‌تواند به سیستم بومی‌سازی غنی‌تر کمک کند؛ این گردش‌کار از رکورد ویراستاری نسخه‌دار ساده‌تری استفاده می‌کند.

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

مورد محلی: 20 محصول، 40 patch زبانی

کاتالوگ منجمد 20 محصول مصنوعی به 20 patch ژاپنی و 20 patch آلمانی توسط عامل ترجمه‌ای تولید شد که صریحاً برای gpt-5.6-luna با استدلال xhigh پیکربندی شده بود. هر patch فقط sku، locale، title و description دارد. assembler قیمت، ارز، ماده و ابعاد را از source.json کپی می‌کند؛ بنابراین حفظ این واقعیت‌ها ویژگی pipeline است، نه کاری که به کپی‌کردن توسط مدل واگذار شده باشد.

هر دو فایل ذخیره‌شده validated-ja.json و validated-de.json دارای 20 ردیف و فهرست failures خالی هستند. بازسازی فقط‌خواندنی با هر دو خروجی ذخیره‌شده مطابقت دارد. از این الگو در batch خود استفاده کنید: revision منبع را حفظ، patchهای زبان را جدا ذخیره و پیش از ساخت بسته بازبینی پوشش و فیلدهای مجاز را اعتبارسنجی کنید.

پیش از بازبینی ویراستاری کنترل قطعی اجرا کنید

schema خروجی، فیلدهای مجاز، نگاشت شناسه، revision منبع، متن لازم و مقدارهای محافظت‌شده را اعتبارسنجی کنید. تعداد placeholder را با grammar واقعی template برنامه مقایسه کنید. markup را parse کنید و روی HTML جایگزینی عمومی متن اعمال نکنید. رکورد malformed را نگه دارید و از importer نخواهید اصلاحش کند.

برای فایل بازبینی spreadsheet، OWASP خطر formula-injection و نبود تبدیل امن عمومی CSV را مستند کرده است. policy خروجی بررسی‌شده ابزار spreadsheet انتخابی را استفاده و آن artifact را از import ماشین جدا نگه دارید. افزودن prefix escape برای مشاهده انسانی نباید SKU را در payload فروشگاه ناخواسته تغییر دهد.

تصمیم‌های بازبینی را به نسخه محتوا ببندید

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

در artifactهای مورد محلی، از جمله DEMO-003 و DEMO-010، patchهای اصلاح‌شده ژاپنی و patchهای آلمانی که در raw-ja.json حفظ شده‌اند به ردیف‌هایی با review_status: unreviewed assemble می‌شوند. هر دو گزارش translation_semantic_review: pending را حفظ می‌کنند. اصلاح با کمک AI مرحله بازنگری است، نه تأیید گویشور بومی یا تاجر. نامزد خام و اصلاح‌شده را حفظ و سپس از بازبین مناسب بخواهید دقیقاً همان متنی را که وارد بسته import می‌شود تأیید کند.

بسته مقصد را assemble و تأیید کنید

نامزدهای تأییدشده و جاری منبع را انتخاب و فقط فیلدهای مجاز آن‌ها را transform کنید. API ترجمه Shopify از قرارداد resource و digest استفاده می‌کند؛ deployment WooCommerce به نگاشت محصول و برای چند زبان به لایه بومی‌سازی تأییدشده نیاز دارد. بسته عمومی بازبینی خودِ import عمومی فروشگاه نیست.

یک import مجاز کوچک را در staging آزمایش کنید. نتیجه importer را ذخیره، فیلدهای هدف را دوباره بخوانید و رفتار محصول و locale را بررسی کنید. مجموعه محصول برنامه‌ریزی‌شده را با outcomeهای ذخیره‌شده تطبیق دهید. ردیف‌های ناموفق را جدا نگه دارید و در صورت نیاز مقادیر قبلی را برای بازگردانی محدود حفظ کنید.

نتیجه و محدودیت‌هایش را ثبت کنید

manifest کامل باید منبع، واژه‌نامه، prompt، نامزد، کنترل، تأیید و نتیجه مقصد را به هم وصل کند. برای هر تلاش هرجا شواهد وجود دارد مصرف واقعی را ثبت کنید، از جمله تلاش‌های مجدد. مصرف مفقود و نتیجه بازبینی مفقود را صریحاً نامعلوم نگه دارید. فایلی که parse می‌شود ثابت نمی‌کند فروشگاه آن را پذیرفته است.

در مورد محلی محدود، مدل انتخابی Luna بود، نه Astra، و هیچ gateway call یا import واقعی فروشگاه وجود نداشت. مصرف API، ID درخواست و صورتحساب آشکار نشدند؛ model_api_usage و model_api_cost همچنان null هستند، نه صفر. مرحله بعد تأیید معنایی و سپس آزمون جداگانه مقصد با مجوز است.

پرسش‌های پرتکرار