چگونه یک اپلیکیشن موبایل را بومی‌سازی کنیم

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

این تمایز کلیدی است: بومی‌سازی اپلیکیشن موبایل فقط ترجمه متن نیست. بلکه تطبیق اپلیکیشن، صفحه محصول و فرآیند QA برای هر بازار هدف است. Apple می‌گوید App Store در ۱۷۵ منطقه و ۴۰ زبان در دسترس است، در حالی که Android 13 تنظیمات زبان هر اپلیکیشن در سطح سیستم را معرفی کرد. به عبارت دیگر، هر دو پلتفرم اصلی اکنون فرض می‌کنند که انتخاب زبان یک تجربه محصولی اصلی است، نه یک فکر ثانویه.

این راهنما مراحل عملی را برای تیم‌های iOS و Android بررسی می‌کند.

خلاصه:

• بومی‌سازی درون‌اپلیکیشنی را از بومی‌سازی App Store و Google Play جدا کنید.
• رشته‌ها را قبل از ترجمه هر چیزی استخراج کنید.
• جمع‌بندی‌ها، متغیرها، تاریخ‌ها، ارز و RTL را زودتر مدیریت کنید.
• قبل از ارسال ترجمه‌های واقعی، با شبه‌زبان‌ها تست کنید.
• اسکرین‌شات‌ها و دارایی‌های فروشگاه را بومی‌سازی کنید، نه فقط توضیحات را.

بومی‌سازی اپلیکیشن موبایل واقعاً شامل چه چیزهایی می‌شود

کار بومی‌سازی معمولاً در دو مسیر قرار می‌گیرد.

۱. بومی‌سازی درون‌اپلیکیشنی

این خود محصول است:

• رشته‌های رابط کاربری
• پیام‌های خطا و متن‌های آشناسازی
• تاریخ‌ها، زمان، اعداد، ارز و واحدها
• رشته‌های حساس به جمع و جنسیت
• گسترش چیدمان و رفتار راست‌به‌چپ
• تصاویر یا آیکون‌هایی که حاوی متن یا معنای جهتی هستند

Apple صریحاً استفاده از Xcode، APIهای Foundation، Auto Layout، پشتیبانی Unicode، کاتالوگ‌های دارایی بومی‌سازی‌شده و نمادهای آگاه از جهت را برای آماده‌سازی اپلیکیشن‌ها برای بازارهای جهانی توصیه می‌کند. Android نیز به طور مشابه منابع آگاه از محلی، پشتیبانی از زبان اپلیکیشن و چیدمان‌های آگاه از RTL را به جای متن و موقعیت‌یابی ثابت توصیه می‌کند.

۲. بومی‌سازی لیست فروشگاه

این نحوه کشف اپلیکیشن شما توسط کاربران است:

• نام اپلیکیشن
• زیرعنوان یا توضیح کوتاه
• توضیح کامل
• کلمات کلیدی
• اسکرین‌شات‌ها
• پیش‌نمایش‌های اپلیکیشن یا ویدیوهای تبلیغاتی

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

با بین‌المللی‌سازی شروع کنید، نه ترجمه

ترجمه آخرین مرحله در خط لوله‌ای است که با ساختار شروع می‌شود.

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

در Android، Google هشدار می‌دهد که فایل پیش‌فرض res/values/strings.xml شما باید هر رشته‌ای که اپلیکیشن نیاز دارد را تعریف کند. اگر فایل پیش‌فرض ناقص باشد و دستگاه در یک محلی پشتیبانی‌نشده اجرا شود، اپلیکیشن ممکن است بارگذاری نشود و خطایی با دکمه Force Close نمایش دهد. به همین دلیل بومی‌سازی با بهداشت منابع شروع می‌شود، نه انتخاب زبان.

برای iOS، Apple توصیه می‌کند متن و تصاویر قابل مشاهده توسط کاربر را از کد اجرایی جدا کنید تا بتوانند به عنوان فایل‌های منبع بومی‌سازی شوند. در گردش کارهای مدرن Apple، کاتالوگ‌های رشته رویکرد توصیه‌شده در Xcode 15 و بعد از آن برای رشته‌هایی هستند که حاوی جمع هستند.

قاعده عملی:

• هرگز متن رابط کاربری را در ویوها یا کنترلرها به صورت ثابت قرار ندهید
• یک زبان مبدأ اصلی داشته باشید
• مطمئن شوید هر رشته رو به کاربر دارای یک کلید پایدار، زمینه و پیش‌فرض است
• نظرات مترجم را برای رشته‌های مبهم درج کنید

یک مثال کوچک این موضوع را روشن‌تر می‌کند.

Android معمولاً با یک فایل پیش‌فرض strings.xml شروع می‌کند:

<!-- Primary CTA on the checkout screen. Keep it short. -->
<string name="checkout_cta">Pay now</string>
<string name="welcome_title">Welcome back, %1$s</string>

سپس رابط کاربری شما به جای نوشتن ثابت انگلیسی، منبع را می‌خواند:

Text(text = stringResource(R.string.checkout_cta))

در پلتفرم‌های Apple، Xcode 15+ اغلب همین ایده را در یک کاتالوگ رشته مدیریت می‌کند. یک نمونه ساده‌شده Localizable.xcstrings می‌تواند به این شکل باشد:

{
  "sourceLanguage": "en",
  "strings": {
    "Pay now": {
      "localizations": {
        "en": { "stringUnit": { "value": "Pay now" } },
        "fr": { "stringUnit": { "value": "Payer maintenant" } }
      }
    }
  }
}

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

اگر اپلیکیشن شما فایل‌های زبان ساختاریافته نیز ارسال می‌کند، راهنمای ما درباره بهترین مترجم‌های JSON در ۲۰۲۶ می‌تواند به شما در فکر کردن درباره اتوماسیون و حفظ فرمت کمک کند.

اگر یک گزینه ابزار مستقیم برای فایل‌های منبع اپلیکیشن می‌خواهید، OpenL JSON Translator ارزش بررسی دارد. این ابزار برای ترجمه فایل‌های .json بدون خراب کردن کلیدها یا ساختار طراحی شده است، که دقیقاً همان چیزی است که وقتی رشته‌های اپلیکیشن در فایل‌های بومی‌سازی قابل خواندن توسط ماشین ذخیره می‌شوند نیاز دارید. گردش کار ساده است: JSON صادرشده از اپلیکیشن، CMS یا خط لوله بومی‌سازی خود را آپلود کنید، زبان مقصد را انتخاب کنید و یک فایل JSON ترجمه‌شده با همان ساختار دانلود کنید. طبق صفحه محصول، از بیش از ۱۰۰ زبان و فایل‌هایی تا ۵۰ مگابایت پشتیبانی می‌کند، که آن را به یک ابزار عملی اولیه برای تیم‌های بومی‌سازی اپلیکیشن که محتوای ساختاریافته را مدیریت می‌کنند تبدیل می‌کند.

پشتیبانی از انتخاب زبان در سطح اپلیکیشن

کاربران به طور فزاینده‌ای انتظار دارند زبان اپلیکیشن را جدا از زبان دستگاه خود انتخاب کنند.

در پلتفرم‌های Apple، کاربران می‌توانند زبان مورد نظر خود را برای یک اپلیکیشن مستقل از زبان دستگاه انتخاب کنند. در Android، Android 13 یک تنظیم متمرکز زبان اپلیکیشن اضافه کرد و Google توصیه می‌کند پشتیبانی خودکار زبان هر اپلیکیشن را فعال کنید یا انتخاب‌گر خود را به APIهای رسمی متصل کنید.

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

از پشته بومی‌سازی پلتفرم استفاده کنید

از وسوسه اختراع یک سیستم بومی‌سازی موازی خودداری کنید مگر اینکه واقعاً به آن نیاز داشته باشید.

برای اکثر تیم‌ها، پشته پیش‌فرض پلتفرم کافی است:

• iOS: کاتالوگ‌های رشته، Localizable.strings، .stringsdict، فرمت‌کننده‌های Foundation، Auto Layout
• Android: res/values/، پوشه‌های منبع خاص محلی، LocaleConfig، setApplicationLocales()، supportsRtl

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

بخش‌هایی که اکثر تیم‌ها از دست می‌دهند را بومی‌سازی کنید

تیم‌ها اغلب جملات قابل مشاهده را ترجمه می‌کنند و مکانیک‌های محصول اطراف آنها را از دست می‌دهند.

جمع‌بندی‌ها، متغیرها و دستور زبان

قوانین جمع جهانی نیستند. قوانین جمع Unicode CLDR دسته‌هایی مانند zero، one، two، few، many و other را تعریف می‌کنند و زبان‌های مختلف از زیرمجموعه‌های متفاوتی استفاده می‌کنند. Apple اشاره می‌کند که در گردش کارهای قدیمی‌تر .stringsdict، other تنها دسته الزامی است، اما نادیده گرفتن دسته‌های خاص زبان همچنان می‌تواند خروجی از نظر دستوری نادرست تولید کند. هر دو Android و iOS به دلیلی بر مدیریت جمع آگاه از محلی تکیه دارند.

اینجاست که ترجمه ماشینی ساده‌لوحانه شکست می‌خورد:

• 1 file در مقابل 2 files در انگلیسی آسان است
• زبان‌های اسلاوی اغلب به بیش از دو شکل جمع نیاز دارند
• برخی زبان‌ها اسم‌ها، فعل‌ها یا کلمات اطراف را با هم تغییر می‌دهند

هرگز رابط کاربری جمع‌بندی‌شده را با الحاق قطعاتی مانند "You have " + count + " messages" نسازید. به جای آن از منابع جمع پلتفرم استفاده کنید.

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

Android:

<plurals name="files_remaining">
  <item quantity="one">%1$d file remaining</item>
  <item quantity="other">%1$d files remaining</item>
</plurals>

Text(text = pluralStringResource(R.plurals.files_remaining, count, count))

مثال قدیمی .stringsdict در iOS:

<plist version="1.0">
<dict>
  <key>%#@files@</key>
  <dict>
    <key>NSStringLocalizedFormatKey</key>
    <string>%#@files@</string>
    <key>files</key>
    <dict>
      <key>NSStringFormatSpecTypeKey</key>
      <string>NSStringPluralRuleType</string>
      <key>NSStringFormatValueTypeKey</key>
      <string>d</string>
      <key>one</key>
      <string>%d file remaining</string>
      <key>other</key>
      <string>%d files remaining</string>
    </dict>
  </dict>
</dict>
</plist>

در Xcode 15 و بعد از آن، Apple مدیریت جمع‌بندی‌ها را در کاتالوگ‌های رشته توصیه می‌کند، اما اصل یکسان باقی می‌ماند: یک الگوی پیام به پلتفرم بدهید و بگذارید شکل زبانی درست را انتخاب کند.

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

تاریخ‌ها، اعداد، ارز و واحدها

Apple صریحاً استفاده از APIهای Foundation را برای قالب‌بندی تاریخ‌ها، طول‌ها، وزن‌ها، قیمت‌ها و نمادهای ارز در محلی‌های مختلف توصیه می‌کند. همین اصل در Android نیز اعمال می‌شود: داده‌ها را با APIهای آگاه از محلی قالب‌بندی کنید به جای نشانه‌گذاری ثابت، علائم اعشار یا ترتیب واحد.

شکست‌های معمول شامل:

• 03/04/2026 که در مناطق مختلف معانی متفاوتی دارد
• علامت دلار ثابت برای بازارهای غیر USD
• 1,234.56 که در محلی‌هایی که از ویرگول به عنوان جداکننده اعشار استفاده می‌کنند به صورت نادرست نمایش داده می‌شود
• واحدهای اندازه‌گیری در سیستم اشتباه نمایش داده می‌شوند

اگر اپلیکیشن شما شامل زمان‌بندی، صورت‌حساب، بازه‌های تحویل یا تحلیل‌ها است، این بخشی از بومی‌سازی است، نه پرداخت نهایی.

گسترش چیدمان و پشتیبانی از راست‌به‌چپ

انگلیسی معمولاً فشرده است. آلمانی طولانی‌تر می‌شود. عربی و عبری جهت خواندن را معکوس می‌کنند. چیدمانی که در انگلیسی خوب به نظر می‌رسد می‌تواند در محلی‌های دیگر به شدت خراب شود.

Apple توصیه می‌کند قبل از وارد کردن ترجمه‌های واقعی، با شبه‌زبان‌ها از جمله یک شبه‌زبان راست‌به‌چپ و یک شبه‌زبان با طول دوبرابر تست کنید. Android توصیه می‌کند از start و end به جای left و right استفاده کنید، android:supportsRtl="true" را فعال کنید و چیدمان‌های RTL را روی دستگاه با Force RTL تست کنید.

چک‌لیست شما در اینجا ساده است:

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

تصاویر، آیکون‌ها، اسکرین‌شات‌ها و ویدیو

راهنمای بومی‌سازی Apple نکته مهمی را بیان می‌کند که بسیاری از تیم‌ها نادیده می‌گیرند: تصاویر هم می‌توانند بومی‌سازی شوند. این شامل مجموعه تصاویر، مجموعه نمادها و جهت‌دهی برای نمادهای سفارشی می‌شود. اگر اسکرین‌شات شما حاوی رابط کاربری انگلیسی، متن انگلیسی در بنرها یا فلش‌های چپ‌به‌راست باشد، آن اسکرین‌شات بومی‌سازی نشده است.

این به ویژه برای صفحات آشناسازی، کارت‌های آموزشی و دارایی‌های App Store مهم است. کاربران «تصاویر بازاریابی» را از «زبان محصول» ذهنی جدا نمی‌کنند. آنها کل تجربه را یکجا قضاوت می‌کنند.

صفحات App Store و Google Play خود را جداگانه بومی‌سازی کنید

اینجاست که بسیاری از تیم‌ها حتی پس از انجام خوب کار درون‌اپلیکیشنی، نصب‌ها را از دست می‌دهند.

الزامات App Store که باید برایشان برنامه‌ریزی کنید

Apple بومی‌سازی فراداده در App Store Connect را توصیه می‌کند، از جمله توضیحات اپلیکیشن، کلمات کلیدی، پیش‌نمایش‌های اپلیکیشن و اسکرین‌شات‌ها. Apple همچنین می‌گوید می‌توانید تا ۱۰ اسکرین‌شات در صفحه محصول خود و تا ۳ پیش‌نمایش اپلیکیشن برای هر اندازه دستگاه و زبان پشتیبانی‌شده قرار دهید. پیش‌نمایش‌های اپلیکیشن می‌توانند تا ۳۰ ثانیه باشند و وقتی پیش‌نمایشی موجود نیست اسکرین‌شات‌ها اهمیت بیشتری پیدا می‌کنند زیرا اولین یک تا سه اسکرین‌شات ممکن است در نتایج جستجو ظاهر شوند.

این دو پیامد دارد:

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

الزامات Google Play که باید برایشان برنامه‌ریزی کنید

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

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

یک ویژگی جاری به‌ویژه مرتبط: Play Console می‌گوید می‌تواند به طور مداوم رشته‌های اپلیکیشن را با استفاده از مدل‌های Gemini بدون هزینه ترجمه کند. به طور خاص‌تر، Google می‌گوید این برای رشته‌های اپلیکیشن از strings.xml در بسته‌های اپلیکیشن آپلود‌شده به نسخه‌های پیش‌نویس اعمال می‌شود و می‌توانید ترجمه‌های تولیدشده را در یک شبیه‌ساز داخلی قبل از انتشار پیش‌نمایش کنید. این روش قدرتمندی برای سرعت بخشیدن به پوشش اولیه است، اما همچنان باید با بازبینی انسانی برای جریان‌های حیاتی دنبال شود.

گردش کار انتشار و QA بسازید

یک فرآیند بومی‌سازی خوب کمتر درباره ترجمه سریع‌تر و بیشتر درباره ارسال شگفتی‌های کمتر است.

مرحله ۱. محلی‌های هدف را عمدی انتخاب کنید

با «همه چیز را به ۲۰ زبان ترجمه کن» شروع نکنید.

با این‌ها شروع کنید:

• ترکیب فعلی دانلودهای شما
• کشورهایی که فعالانه پشتیبانی می‌کنید
• پوشش صورت‌حساب، حقوقی و پشتیبانی مشتری
• آیا می‌توانید هم اپلیکیشن و هم لیست فروشگاه را همزمان بومی‌سازی کنید

ارسال یک بازار به صورت کامل معمولاً از ارسال پنج بازار به صورت نصفه بهتر است.

مرحله ۲. دارایی‌های آماده بومی‌سازی بسازید

قبل از شروع ترجمه، تثبیت و آماده کنید:

• رشته‌های مبدأ با زمینه
• لیست اسکرین‌شات بر اساس محلی
• واژه‌نامه و قوانین نام محصول
• قوانین جایگزین
• راهنمای محدودیت کاراکتر برای متن فروشگاه
• مالکان بازبینی خاص محلی

اگر اپلیکیشن از مخازن جداگانه یا فرمت‌های فایل متعدد استفاده می‌کند، نام‌گذاری و استخراج را زودتر استاندارد کنید.

مرحله ۳. ابتدا با شبه‌بومی‌سازی تست کنید

در پلتفرم‌های Apple، از شبه‌زبان‌های با طول دوبرابر و راست‌به‌چپ استفاده کنید. در Android، محلی‌های پشتیبانی‌نشده، Force RTL و تنظیمات زبان اپلیکیشن را تست کنید. این موارد را شناسایی می‌کند:

• دکمه‌های بریده‌شده
• سربرگ‌های کلیپ‌شده
• متن پنهان
• تراز اشتباه
• رشته‌های بومی‌سازی‌نشده
• فرضیات ثابت چپ/راست

این یکی از ارزان‌ترین پاس‌های QA است که می‌توانید اجرا کنید.

مرحله ۴. QA زبانی را روی دستگاه‌های واقعی اجرا کنید

پس از رسیدن ترجمه‌ها:

• جریان‌های حیاتی را در هر زبان هدف تست کنید
• رفتار زبان سیستم و زبان اپلیکیشن را مقایسه کنید
• رفتار جمع و جایگزین‌ها را بررسی کنید
• پرداخت‌ها، تاریخ‌ها و آدرس‌ها را بررسی کنید
• اسکرین‌شات‌ها و لیست‌های فروشگاه را در بازار بررسی کنید

اگر یک باگ بر آشناسازی، پرداخت، تأیید هویت یا اعلان‌ها تأثیر بگذارد، آن را به عنوان مسدودکننده انتشار در نظر بگیرید.

چک‌لیست اولین اسپرینت بومی‌سازی

اگر این اولین راه‌اندازی جدی شماست، اسپرینت را به اندازه کافی کوچک نگه دارید تا به طور تمیز تمام شود:

• ۱ محلی هدف انتخاب کنید، نه ۱۰.
• رشته‌های مبدأ را برای یک شاخه انتشار تثبیت کنید.
• تمام رشته‌های آشناسازی، پرداخت، حساب و اعلان را با نظرات زمینه صادر کنید.
• اسکرین‌شات‌هایی که می‌خواهید برای App Store و Google Play بومی‌سازی کنید را ضبط کنید.
• قبل از ارسال متن واقعی به مترجمان، یک پاس شبه‌بومی‌سازی اجرا کنید.
• رشته‌های اپلیکیشن و متن لیست فروشگاه را در همان اسپرینت ترجمه کنید.
• ترجمه‌ها را دوباره وارد کنید و تغییر زبان اپلیکیشن را در هر دو iOS و Android تست کنید.
• ۵ سفر کاربری برتر را روی دستگاه‌های واقعی QA کنید.
• اسکرین‌شات‌ها، پیش‌نمایش‌های اپلیکیشن و فراداده فروشگاه را برای همان محلی به‌روزرسانی کنید.
• ابتدا به TestFlight یا یک مسیر داخلی ارسال کنید، سپس تیکت‌های پشتیبانی و گزارش‌های خرابی را زیر نظر بگیرید.

این چک‌لیست عمداً محدود است. یک محلی با تجربه اپلیکیشن تمیز و دارایی‌های فروشگاه هم‌زمان بسیار بیشتر از یک راه‌اندازی عجولانه در بازارهای متعدد به شما می‌آموزد.

نمونه‌های دنیای واقعی

ایده‌های اصلی بالا نظری نیستند.

DoorDash ترجمه را به عنوان مشکل پلتفرم ساخت

در ۲۰۲۲، DoorDash گفت که قبلاً بیش از یک میلیون رشته را در چهار زبان ترجمه کرده و آشناسازی زبان جدید را از ساعت‌ها تلاش توسعه‌دهنده به یک دستور واحد در یک دقیقه کاهش داده است. درس جالب فقط مقیاس نیست. ساختار است: DoorDash رشته‌های ایستا و پویا را جدا کرد، پشتیبانی از واژه‌نامه و راهنمای سبک اضافه کرد و محافظ‌هایی ساخت تا رشته‌های ترجمه‌نشده از بین نروند.

در یک پست وبلاگ DoorDash در ۲ فوریه ۲۰۲۶، شرکت گفت پلتفرم بازسازی‌شده آشناسازی آن اکنون ثبت‌نام‌ها را در تمام بازارهای DoorDash پشتیبانی می‌کند و راه‌اندازی‌های سریع بین‌المللی با بومی‌سازی یکپارچه را ممکن می‌سازد. این دقیقاً شبیه بومی‌سازی بالغ است: گردش کارهای قابل استفاده مجدد، انعطاف‌پذیری منطقه‌ای و هک‌های یک‌باره کمتر.

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

Meta می‌گوید حدود ۵۷٪ از کاربران Facebook for Android و ۴۹٪ از کاربران Facebook for iOS از اپلیکیشن به زبانی غیر از انگلیسی استفاده می‌کنند. در همان نوشته، Meta می‌گوید حذف فایل‌های ترجمه بسته‌بندی‌شده تا ۱۶.۶ مگابایت در اپلیکیشن iOS صرفه‌جویی کرد و به Android اجازه داد تقریباً یک دوجین زبان دیگر را بدون افزایش حجم اپلیکیشن اضافه کند.

نکته کلیدی حتی برای تیم‌های کوچک‌تر مفید است: بومی‌سازی عواقب مهندسی دارد. بر حجم باینری، بارگذاری در زمان اجرا، تحویل ترجمه و مکانیک‌های انتشار تأثیر می‌گذارد، نه فقط نویسندگی.

چک‌لیست نهایی قبل از انتشار

از این به عنوان آخرین پاس استفاده کنید:

• تمام رشته‌های قابل مشاهده توسط کاربر استخراج شده‌اند.
• منابع پیش‌فرض بازگشتی کامل هستند.
• جمع‌بندی‌ها و جایگزین‌ها از پشتیبانی بومی‌سازی بومی پلتفرم استفاده می‌کنند.
• تاریخ‌ها، زمان، اعداد، ارزها و واحدها آگاه از محلی هستند.
• چیدمان‌های RTL و متن جهت ترکیبی تست شده‌اند.
• متن لیست فروشگاه برای بازارهای هدف بومی‌سازی شده است.
• اسکرین‌شات‌ها و پیش‌نمایش‌ها برای زبان‌های با اولویت بومی‌سازی شده‌اند.
• انتخاب زبان درون‌اپلیکیشنی در iOS و Android به درستی کار می‌کند.
• QA زبانی مهم‌ترین سفرهای کاربری را پوشش داده است.

جمع‌بندی نهایی

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

اگر این کار را برای اولین بار انجام می‌دهید، هدفتان پوشش جهانی کامل در روز اول نباشد. یک یا دو محلی استراتژیک انتخاب کنید، اپلیکیشن و صفحه فروشگاه را با هم بومی‌سازی کنید، یک پاس QA جدی اجرا کنید و از استفاده واقعی بیاموزید. اگر قبلاً فایل‌های منبع و محتوای رو به توسعه‌دهنده مدیریت می‌کنید، این گردش کار را با نحوه ترجمه مستندات فنی بدون خراب کردن کد و بهترین مترجم‌های JSON در ۲۰۲۶ ترکیب کنید.

اگر فقط یک اقدام این هفته انجام می‌دهید، این کار را بکنید: ۱ محلی انتخاب کنید، ۱ پاس شبه‌بومی‌سازی اجرا کنید و ۱ لیست App Store یا Google Play مطابق را بومی‌سازی کنید. این آزمون سه‌بخشی بیشتر از ترجمه بیست محلی به صورت موازی درباره آمادگی شما به شما می‌گوید.

اگر به یک پاس اولیه سریع برای متن اپلیکیشن، اسکرین‌شات‌ها یا فایل‌های زبان ساختاریافته نیاز دارید، از اتوماسیون برای تسریع پیش‌نویس استفاده کنید، سپس یک مرحله QA انسانی قبل از انتشار نگه دارید. این بخشی است که اعتماد کاربر را محافظت می‌کند و از راه‌اندازی «ترجمه‌شده اما واقعاً بومی‌سازی‌نشده» جلوگیری می‌کند.

منابع

• Apple Developer. Localization. https://developer.apple.com/localization/
• Apple Developer. Creating Your Product Page. https://developer.apple.com/app-store/product-page/
• Apple Developer. Upload app previews and screenshots. https://developer.apple.com/help/app-store-connect/manage-app-information/upload-app-previews-and-screenshots
• Apple Developer. Localizing strings that contain plurals. https://developer.apple.com/documentation/xcode/localizing-strings-that-contain-plurals
• Apple Developer. Testing Your Internationalized App. https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPInternational/TestingYourInternationalApp/TestingYourInternationalApp.html
• Apple Developer. Get it right (to left). https://developer.apple.com/videos/play/wwdc2022/10107/
• Android Developers. Localize your app. https://developer.android.com/guide/topics/resources/localization
• Android Developers. Per-app language preferences. https://developer.android.com/guide/topics/resources/app-languages
• Android Developers. Support different languages and cultures. https://developer.android.com/training/basics/supporting-devices/languages
• Google Play Console Help. Translate and localize your app. https://support.google.com/googleplay/android-developer/answer/9844778?hl=en
• Google Play Console Help. Create and set up your app. https://support.google.com/googleplay/android-developer/answer/9859152?hl=en
• Unicode CLDR. Plural Rules. https://cldr.unicode.org/index/cldr-spec/plural-rules
• DoorDash Engineering. Building a Platform to Translate DoorDash into Multiple Languages. https://careersatdoordash.com/blog/building-a-platform-to-translate-doordash-into-multiple-languages/
• DoorDash Engineering. Unified Dasher Onboarding: A modular platform to scale globally. https://careersatdoordash.com/blog/doordash-unified-dasher-onboarding-a-modular-platform-to-scale-globally/
• Engineering at Meta. Language packs: Meta’s mobile localization solution. https://engineering.fb.com/2022/05/09/android/language-packs/