مسیرهای کامل را ترجمه کنید
با یک کار واقعی شروع کنید: مشتری محصولی را انتخاب می‌کند، وارد حساب می‌شود، پرداخت می‌کند، به‌روزرسانی سفارش را دریافت می‌کند و درخواست کمک می‌دهد. همه‌ی پیام‌هایی را که در این مسیر می‌بیند فهرست کنید؛ از خطاهای اعتبارسنجی و ایمیل‌ها تا حالت‌های خالی و پاسخ‌های مدیریتی. ترجمه‌ی صفحه‌ی اصلی به‌تنهایی نمی‌تواند این مسیر را کامل کند. برای واژگانی که در این سطوح به کار می‌رود مالک تعیین کنید، به‌ویژه واژه‌هایی مانند در انتظار، تأییدشده، تحویل‌شده و بازپرداخت‌شده. این اصطلاح‌ها باید هرجا مشتری با آن‌ها روبه‌رو می‌شود همان وضعیت‌ها را توصیف کنند، حتی اگر صفحه‌ها را تیم‌های مختلف نگهداری کنند.
جهت طراحی و معنا را با هم در نظر بگیرید
زبان عربی به رسیدگی آگاهانه به جهت نیاز دارد، نه فقط رشته‌های ترجمه‌شده. زبان صفحه و جهت متن را جداگانه اعلام کنید و از فاصله‌گذاری منطقی استفاده کنید تا چیدمان بتواند از جهت سند پیروی کند. سپس محتوای واقعی را بازبینی کنید: یک جمله ممکن است شامل نام لاتین محصول، نشانی ایمیل و شناسه‌ی تراکنش باشد. بررسی کنید که این موارد همچنان خوانا بمانند و درست کپی شوند. برچسب‌های بلند آلمانی، نشانه‌گذاری فرانسوی و ارتفاع خط عربی را در همان کامپوننت‌ها آزمایش کنید؛ با محتوای واقعی، نه ترجمه‌های کوتاهِ جای‌نگهدار.
معنای داده را پایدار نگه دارید
مشخص کنید کدام مقدارها شناسه‌اند و کدام فقط شیوه‌ی نمایش. برچسب ترجمه‌شده‌ی پرداخت نباید شناسه‌ی شبکه یا نشانی دریافت را تغییر دهد. تاریخ‌ها به قرارداد زمانیِ روشن نیاز دارند، و قیمت‌ها به ارز صریح؛ یک عدد که ظاهری محلی دارد، به‌تنهایی هیچ‌کدام را توضیح نمی‌دهد. تعیین کنید مبالغ، حالت‌های جمع و تاریخ‌ها در هر زبان‌ـ‌منطقه چگونه نمایش داده می‌شوند، و آن‌ها را در فاکتورها، جدول‌ها و خروجی‌ها آزمایش کنید. وضعیت تجاریِ ذخیره‌شده را مستقل از برچسب ترجمه‌شده‌ی آن نگه دارید تا تغییر زبان نتواند تراکنش زیربنایی را تغییر دهد.
هنگام تغییر زبان، زمینه را حفظ کنید
تغییر زبان باید مشتری را به صفحه‌ی متناظر ببرد، در حالی که زمینه‌ی مفید حفظ شده باشد. فهرست محصولات فیلترشده، درخواست پشتیبانی باز یا لینک بازگشت از پرداخت را در نظر بگیرید. مشخص کنید کدام پارامترها همچنان معنا دارند و کدام‌یک به معادل ترجمه‌شده نیاز دارند. از فرستادن بی‌سروصدای همه‌ی تغییر زبان‌ها به صفحه‌ی اصلی پرهیز کنید. عنوان صفحه‌ها، توضیحات، ناوبری و لینک‌های داخلی را با هم بازبینی کنید و درباره‌ی ترجمه‌های مفقود تصمیم تحریری بگیرید. انتشار نسخه‌ی جایگزین باید آگاهانه باشد و مسیر روشنی برای تکمیل نسخه‌ی بومی‌سازی‌شده داشته باشد.
بومی‌سازی را بخشی از کار انتشار بدانید
چک‌لیست بازبینی را حول کارها بسازید، نه فقط یک صفحه‌گسترده از رشته‌ها. از بازبین بخواهید در هر زبان پشتیبانی‌شده و روی صفحه‌ی باریک، ثبت‌نام را کامل کند، دسترسی را بازیابی کند، سفارشی را بررسی کند و تیکت ثبت کند. استفاده از صفحه‌کلید، برچسب‌های صفحه‌خوان و شناسه‌های دارای جهت‌های ترکیبی را هم لحاظ کنید. مشکلات را کنار نقص‌های عملکردی ثبت کنید تا مالک و تصمیم انتشار داشته باشند. وقتی قابلیتی تغییر می‌کند، پیام‌ها، محتوای راهنما و اعلان‌های آن نیز باید با هم تغییر کنند. پشتیبانی زبانی فقط زمانی مفید می‌ماند که کل تجربه همراه با محصول تکامل پیدا کند.