فرض کنید نسخه انگلیسی سایت‌تان آماده است و صفحه‌ها در نگاه اول بی‌نقص به نظر می‌رسند. بعد بازدیدکننده‌ای فرم تماس را ناقص می‌فرستد و یک پیام خطای فارسی جلوی چشمش ظاهر می‌شود. افزودن زبان به سایت دقیقاً در همین جزئیات موفق می‌شود یا شکست می‌خورد. پاسخ کوتاه این است: ساختار فعلی را بسنجید، دامنه و مسئول‌ها را مکتوب کنید، نسخه جدید را در محیط آزمایشی بسازید و با معیار پذیرش روشن منتشر کنید.
این چک‌لیست را از جایگاه مدیر پروژه نوشته‌ام؛ یعنی کسی که آخر کار باید امضا کند که هر زبان واقعاً آماده است. به همین دلیل، در افزودن زبان به سایت بیشتر از ترجمه، درباره دامنه، مسئولیت، آزمون و تحویل حرف می‌زنم.
- دامنه کار فقط صفحه‌ها نیست؛ فرم، ایمیل و اتصالها را هم فهرست کنید.
- برنامه اجرا باید به زمان تحویل محتوای تأییدشده وابسته باشد.
- برای هر زبان، معیار پذیرش و صورت‌جلسه مستقل داشته باشید.
- پیش از انتشار، مسئول پایش و روش بازگشت بدون حذف داده جدید را مشخص کنید.
برای افزودن زبان به سایت موجود چه مراحلی لازم است؟
مسیر کلی چهار گام دارد. برای افزودن زبان به سایت موجود، اول ساختار فنی و صفحه‌ها را بررسی کنید. بعد دامنه ترجمه، مسئول هر کار و زمان آماده‌شدن محتوا را مشخص کنید. سپس نسخه جدید را در محیط آزمایشی بسازید و نشانیها و مسیرهای کاربر را بیازمایید. وقتی معیارهای تحویل تأیید شد، همراه با برنامه پایش و بازگشت منتشر کنید.
اما چک‌لیست افزودن زبان به سایت فقط وقتی به کار می‌آید که هر تیکش قابل وارسی باشد. پس کنار هر مورد این چهار ستون را نگه دارید:
وضعیت: انجام‌نشده، در حال انجام، آماده بازبینی یا تأییدشده.
مسئول: نام یک نفر، نه «تیم فنی» یا «واحد بازاریابی».
مدرک بررسی: تصویر صفحه، پیوند گزارش آزمون یا شماره درخواستی که در سامانه مقصد ثبت شده است.
مانع انتشار: آیا نقص این مورد جلوی انتشار را می‌گیرد یا نه.
تیکی که شاهد ندارد، فقط یک ادعاست. در جلسه تحویل هم معمولاً همین ادعاهای بی‌سند بیشترین بحث را راه می‌اندازند؛ بنابراین مدرک را همان روزی ضمیمه کنید که مورد را تیک می‌زنید.
آیا سایت فعلی برای افزودن زبان مناسب است؟
در بیشتر موارد بله. افزودن زبان به سایت موجود معمولاً شدنی است و سؤال اصلی، میزان کار و محدودیت‌هاست. با این حال، پیش از هر برآوردی این موارد را تیک بزنید:
دسترسی به کد منبع یا مخزن آن، نه فقط پیشخوان مدیریت.
دسترسی مدیر به سامانه مدیریت محتوا (CMS)، یعنی همان پنلی که صفحه‌ها را از آن ویرایش می‌کنید.
دسترسی به میزبانی (هاست) و پنل دامنه.
مجوز معتبر قالب و افزونه‌های تجاری، چون نسخه‌های بدون مجوز معمولاً به‌روزرسانی نمی‌گیرند.
امکان پشتیبان‌گیری کامل از فایل‌ها و پایگاه داده.
خروجی این مرحله یک گزارش کوتاه از محدودیت‌هاست؛ مثلاً «افزونه فرم قدیمی است و پیام‌هایش ترجمه‌پذیر نیست». بدون این گزارش، برآورد بعدی روی حدس بنا می‌شود.
سپس سه نمونه صفحه را دقیق‌تر ببینید: یک صفحه خدمات، یک فرم و یک صفحه پویا مثل فهرست کالا یا نتایج جست‌وجو. سه معیار اینجا تصمیم را می‌سازند:
جداسازی متن از کد: اگر متن دکمه‌ها مستقیم داخل کد قالب نوشته شده باشد، هر زبان جدید یعنی دست‌بردن در کد.
پشتیبانی از جهت نوشتار: فارسی راست‌به‌چپ است و انگلیسی چپ‌به‌راست؛ قالب باید هر دو جهت را بدون به‌هم‌ریختن چیدمان نشان دهد.
مدیریت نسخه‌های زبانی: سامانه باید بداند کدام صفحه انگلیسی معادل کدام صفحه فارسی است.
برای جزئیات جهت نوشتار و قالب‌بندی تاریخ و عدد، راهنماهای بین‌المللی‌سازی وب مرجع خوبی است. اگر هم هنوز درباره ساختار کلی مردد هستید، پیش از تصمیم نکات طراحی سایت چندزبانه را بخوانید.
قاعده تصمیم من برای دو زبانه کردن سایت موجود ساده است. اگر اجزای اصلی قابل توسعه‌اند، بازطراحی کامل الزامی نیست. اما اگر بخشی مهم، مثلاً فرم سفارش، ناسازگار است، اول همان را با نمونه‌ای محدود آزمایش کنید. بعد درباره کل سایت تصمیم بگیرید.
همچنین از مجری بخواهید کارهای ضروری پیش از چندزبانه‌سازی را جدا از بهبودهای اختیاری قیمت بدهد. مثلاً به‌روزرسانی هسته سامانه شاید ضروری باشد؛ تغییر رنگ‌بندی سایت نیست. همین جداسازی جلوی بادکردن بی‌دلیل دامنه را می‌گیرد.
فهرست صفحات، فرم‌ها و اتصال‌های موجود
دامنه کار را با یک کاربرگ ساده ببندید، نه با جمله «کل سایت». تعداد نشانیها با تعداد قالب‌های صفحه یکی نیست؛ دویست صفحه کالا ممکن است فقط یک قالب داشته باشد. در نتیجه زمان توسعه بیشتر به قالبها وابسته است و زمان ترجمه به نشانیها.
نوع صفحه | تعداد | زبان مقصد | وضعیت ترجمه | مسئول | تصمیم انتشار |
|---|---|---|---|---|---|
صفحه اصلی و درباره ما | ۲ | انگلیسی | آماده بازبینی | مترجم | فاز اول |
صفحات خدمات | ۶ | انگلیسی | در حال ترجمه | مترجم | فاز اول |
صفحات کالا | ۲۰۰ | انگلیسی | ۴۰ مورد آماده | واحد فروش | فقط منتخب |
مقالات وبلاگ | ۸۰ | — | خارج از دامنه | — | منتشر نمی‌شود |
اعداد این جدول فرضی‌اند. از همه مهم‌تر ستون آخر است، چون هر ردیف باید تصمیم انتشار روشنی داشته باشد؛ «بعداً می‌بینیم» تصمیم نیست.
در افزودن زبان به سایت، بخش بزرگی از متن اصلاً داخل صفحه‌ها نیست. پس این موارد را هم فهرست کنید و بنویسید هرکدام را از کجا ویرایش می‌کنید:
منوها و پانویس
جست‌وجو و پیام «نتیجه‌ای یافت نشد»
پیامهای خطا و موفقیت فرم‌ها
ایمیل‌ها و پیامک‌های خودکار
فایل‌های دانلودی مثل کاتالوگ PDF
متن داخل تصویرها و بنرها
بعد سراغ اتصالها بروید: سامانه مدیریت ارتباط با مشتری (CRM)، درگاه پرداخت و سرویس پیامک. اما اینجا یک نکته را جدی بگیرید. ترجمه صفحه پرداخت به این معنا نیست که مشتری خارجی بتواند پرداخت کند، یا شما بتوانید به او خدمت بدهید.
برای مثال، فروشگاهی فرضی با ۲۰۰ کالا را در نظر بگیرید که فقط ۴۰ کالای پرفروش را ترجمه میکند. این کار کاملاً شدنی است. اما باید از قبل معلوم باشد دسته‌بندی‌ها چه نشان می‌دهند و جست‌وجوی انگلیسی کالاهای ترجمه‌نشده را برمی‌گرداند یا نه. این هم باید روشن باشد که کاربر روی صفحه بدون ترجمه چه می‌بیند.
تقسیم مسئولیت میان کارفرما، مترجم و توسعه‌دهنده
در اضافه کردن زبان به سایت، بیشتر تأخیرها از کارهایی می‌آید که هیچ‌کس مالکشان نبوده است. به همین دلیل نقش‌ها را از روز اول بنویسید:
کارفرما: بازار هدف، دامنه صفحات و یک تأییدکننده نهایی را تعیین میکند.
مترجم: واژه‌نامه اصطلاحات و متن بازبینی‌شده تحویل می‌دهد.
توسعه‌دهنده: پیاده‌سازی را انجام می‌دهد و شواهد آزمون را تحویل می‌دهد.
با این حال، سه کار معمولاً بین این نقش‌ها گم می‌شود: ورود محتوا به سایت، بازبینی متن روی صفحه واقعی و اصلاح متن‌های کوتاه رابط مثل «ارسال» یا «بیشتر بخوانید». این‌ها را خودبه‌خود جزو ترجمه فرض نکنید و برای هرکدام مسئولی جدا بگذارید. غافلگیری‌های هفته آخر هم معمولاً از همین سه کار بی‌صاحب می‌آید.
برای اضافه کردن زبان انگلیسی سایت، چند تصمیم هم فقط از کارفرما برمی‌آید؛ مثلاً نام انگلیسی محصول‌ها، یا اینکه قیمت با چه واحد پولی نمایش داده شود و اصلاً نمایش داده شود یا نه. یک سؤال را هم کمتر کسی می‌پرسد: شماره تماس و ساعت کاری‌ای که منتشر می‌کنید، واقعاً برای مخاطب خارجی پاسخ‌گوست؟
پیش از شروع، سه مورد را در توافق مکتوب بیاورید: تعداد نوبت‌های اصلاح، مهلت پاسخ به هر درخواست تأیید و روش ثبت تغییر دامنه. این سه بند لازم‌اند، چون بدون آن‌ها هر اصلاح کوچک به مذاکره‌ای تازه تبدیل می‌شود. برای ساختار این بندها، راهنمای نگارش قرارداد طراحی سایت حرفه‌ای کمک‌تان میکند.
برنامه زمان‌بندی بر اساس آماده‌بودن محتوا
مدت زمان چندزبانه کردن سایت را تعداد قالبها، حجم محتوای تأییدشده، اتصالها و نوبت‌های بازبینی تعیین می‌کنند. به همین دلیل به عدد ثابتی که بدون ارزیابی پیشنهاد می‌شود اعتماد نکنید. برآورد معتبر بعد از کاربرگ دامنه می‌آید، نه قبل از آن.
خبر خوب این است که کار فنی منتظر ترجمه نمی‌ماند. ساختار نشانیها، تغییردهنده زبان و آماده‌سازی قالب برای جهت چپ‌به‌راست، موازی با ترجمه پیش می‌روند. اما آزمون چیدمان نهایی به متن واقعی نیاز دارد، چون متن آزمایشی هیچ‌وقت طول واقعی تیترها را نشان نمی‌دهد.
نقطه تأیید | چه چیزی تأیید می‌شود | تأییدکننده |
|---|---|---|
پذیرش دامنه | کاربرگ صفحات، زبان‌ها و موارد خارج از دامنه | کارفرما |
تأیید نمونه صفحه | یک صفحه کامل با متن واقعی روی دسکتاپ و موبایل | کارفرما و مترجم |
تحویل محتوای نهایی | همه متن‌های دامنه، بازبینی‌شده | مترجم |
پذیرش آزمون | گزارش آزمون و فهرست ایرادهای باقی‌مانده | مدیر پروژه و کارفرما |
اجازه انتشار | زمان و شرایط انتشار، به‌صورت مکتوب | تأییدکننده نهایی |
دو حالت را از هم جدا کنید. اگر محتوا آماده و تأییدشده است، برنامه افزودن زبان به سایت بیشتر به کار فنی و آزمون بستگی دارد. ولی اگر محتوا هنوز در حال تولید است، برنامه به سرعت نوشتن و تأیید گره می‌خورد.
در حالت دوم، تأخیر محتوا نباید به انتظاری بی‌پایان تبدیل شود. پس برای هر تأخیر یک تاریخ بازبینی و اثر روشن بر برنامه بنویسید؛ مثلاً «اگر متن خدمات تا تاریخ بازبینی نرسد، آن صفحات به فاز دوم می‌روند».
تاریخ انتشار سایت چندزبانه را روز تأیید آخرین متن تعیین میکند، نه تقویم برنامه‌نویس.
یک صفحه با متن نهایی، فرم و پیام‌هایش آماده کنید. این نمونه، اختلاف درباره لحن و چیدمان را پیش از تکثیر در کل سایت آشکار میکند.
محیط آزمایشی و نقشه نشانی‌های قدیم و جدید
منظور از محیط آزمایشی (Staging) نسخه‌ای جدا از سایت است که تغییرات را در آن می‌سازید و بررسی می‌کنید، بی‌آنکه کاربران واقعی چیزی ببینند. هر مرحله از افزودن زبان به سایت اول باید همین‌جا اجرا شود. در این محیط سه چیز را کنترل کنید:
دسترسی محدود باشد، مثلاً با رمز یا فهرست نشانی‌های مجاز.
موتور جست‌وجو اجازه نمایه‌کردن آن را نداشته باشد.
داده‌ها غیرحساس باشند؛ اطلاعات واقعی مشتری را به محیط آزمایشی نبرید.
سپس نقشه نشانیها را بسازید؛ یعنی برای هر صفحه فعلی، نشانی زبان اصلی، معادل ترجمه و وضعیت انتشار را ثبت کنید:
نشانی فعلی | نشانی زبان اصلی پس از انتشار | معادل انگلیسی | وضعیت |
|---|---|---|---|
/services/seo | /services/seo | /en/services/seo | منتشر می‌شود |
/products/chair-12 | /products/chair-12 | /en/products/chair-12 | منتشر می‌شود |
/blog/news-1 | /blog/news-1 | — | ترجمه ندارد |
ستون اول و دوم در بیشتر ردیف‌ها یکی‌اند و این عمدی است. چون در افزودن زبان به سایت، تغییر نشانی‌های سالم زبان اصلی الزامی نیست و فقط بی‌دلیل ریسک می‌سازد.
اما اگر نشانی‌ای واقعاً تغییر میکند، انتقال دائمی (ریدایرکت ۳۰۱) را به مقصد مرتبط تنظیم و آزمایش کنید. فرستادن همه نشانی‌های قدیمی به صفحه اصلی، کاربر و موتور جست‌وجو را هم‌زمان سردرگم میکند.
تغییردهنده زبان هم باید معادل همان صفحه را باز کند، نه صفحه اصلی نسخه انگلیسی را. برای صفحه‌ای که ترجمه ندارد هم رفتار مشخصی تعیین کنید؛ مثلاً پیامی کوتاه که بگوید این صفحه فقط فارسی است. انتقال بی‌صدا به صفحه‌ای بی‌ربط، کاربر را گمراه میکند.
پیش از هر تغییر روی سایت اصلی، پشتیبان بگیرید و بازیابی‌اش را واقعاً آزمایش کنید. پشتیبانی که هرگز بازیابی نشده، هنوز ثابت نکرده کار میکند. نقشه نشانیها را هم نگه دارید، چون جزو مدارک تحویل است.
آزمون ترجمه، فرم، موبایل و تنظیمات سئو
برای هر مورد آزمون، از قبل بنویسید چطور بررسی می‌کنید و چه نتیجه‌ای انتظار دارید. در نتیجه «به نظرم درست است» جایش را به نتیجه‌ای قابل‌مقایسه می‌دهد. این جدول نقطه شروع خوبی است:
مورد | روش بررسی | نتیجه مورد انتظار |
|---|---|---|
ترجمه کامل | مرور همه صفحات دامنه و متن‌های رابط | هیچ متن فارسی در نسخه انگلیسی باقی نمی‌ماند |
جهت نوشتار | بررسی تیترها، فهرست‌ها، آیکن‌ها و فلش‌ها | چیدمان چپ‌به‌راست و بدون جابه‌جایی |
متن طولانی | بلندترین تیتر و دکمه با متن واقعی | متن بریده نمی‌شود و روی هم نمی‌افتد |
اعداد | قیمت، تاریخ و شماره تماس | رقم‌ها با قالب زبان مقصد نمایش داده می‌شوند |
واحدها | پول، وزن و ابعاد | واحد برای مخاطب هدف قابل فهم است |
ترکیب فارسی و زبان مقصد | نام‌های فارسی داخل متن انگلیسی و برعکس | ترتیب کلمات و نشانه‌ها به هم نمی‌ریزد |
فرم‌ها را تا انتهای مسیر آزمایش کنید: از ارسال در سایت تا ثبت در CRM یا ایمیل مقصد، و رسیدن ایمیل تأیید به کاربر. در هر مرحله، زبان پیام، اعتبارسنجی ورودی و پیام موفقیت را ببینید. برای مثال، فرمی که شماره تلفن خارجی را نامعتبر می‌داند، در عمل مشتری خارجی را رد میکند.
بعد همه‌چیز را روی موبایل و با متن نهایی ببینید: منو، تغییردهنده زبان، جدول‌ها و دکمه اصلی هر صفحه. سالم‌بودن نسخه دسکتاپ چیزی را درباره موبایل ثابت نمی‌کند. بسیاری از ایرادهای افزودن زبان به سایت فقط روی صفحه کوچک دیده می‌شوند؛ بنابراین این مرحله را با نگاهی سرسری به گوشی خودتان تمام نکنید.
نوبت بعدی سئو است، یعنی بهینه‌سازی سایت برای موتور جست‌وجو. عنوان و توضیح هر صفحه ترجمه‌شده، نقشه سایت (Sitemap) و قابلیت نمایه‌شدن صفحات انگلیسی را بررسی کنید. اگر قرار است افزودن زبان به سایت ورودی تازه بیاورد، این بخش را به بعد از انتشار موکول نکنید.
در واقع دو تنظیم فنی اینجا تعیین‌کننده‌اند. hreflang به موتور جست‌وجو می‌گوید هر صفحه چه معادل‌هایی در زبان‌های دیگر دارد. canonical نشانی مرجع هر صفحه را تعیین میکند. خطای رایج این است که canonical همه ترجمه‌ها به صفحه فارسی اشاره کند. این کار عملاً نسخه انگلیسی را از نتایج کنار می‌گذارد.
روابط hreflang هم باید معتبر و متقابل باشند؛ یعنی اگر صفحه فارسی به معادل انگلیسی اشاره میکند، صفحه انگلیسی هم باید به فارسی برگردد. جزئیات را در مستندات معرفی نسخه‌های زبانی به موتور جست‌وجو ببینید.
سرانجام، مسیرهای مهم زبان اصلی را دوباره بیازمایید. افزودن زبان به سایت گاهی قابلیتی قدیمی، مثل جست‌وجوی فارسی یا فرم سفارش، را بی‌سروصدا خراب میکند.
آزمونی که فقط نسخه تازه را می‌بیند، نیمی از ریسک را ندیده است.
معیار پذیرش و مدارک لازم هنگام تحویل
پایان افزودن زبان به سایت را با یک صورت‌جلسه پذیرش، جداگانه برای هر زبان، ثبت کنید. این صورت‌جلسه دست‌کم این موارد را دارد:
دامنه تأییدشده، با پیوند به کاربرگ
نسخه یا تاریخ انتشار
نتیجه آزمون‌ها
ایرادهای باقی‌مانده و مسئول هرکدام
نام امضاکننده و تاریخ امضا
هر معیار پذیرش باید قابل سنجش باشد. مثلاً «سایت درست کار کند» معیار نیست. اما این یکی معیار است: «همه صفحات توافق‌شده معادل درست دارند و ارسال آزمایشی فرم در سامانه مقصد ثبت می‌شود».
همچنین ایرادها را دسته‌بندی کنید. ایراد مانع انتشار، مثل ازکارافتادن فرم اصلی، با فاصله‌ای نامرتب در پانویس یکی نیست. اگر پذیرش را مشروط می‌کنید، برای هر شرط مالک و موعد رفع بنویسید.
پیش از امضا، این مدارک را تحویل بگیرید:
نقشه نشانی‌های قدیم و جدید
واژه‌نامه اصطلاحات
گزارش آزمون
آموزش افزودن محتوا به هر زبان
دسترسی‌های لازم، از مسیری امن و نه در پیام‌رسان عمومی
نسخه پشتیبان و دستور بازگشت
مرز سه چیز را هم مکتوب کنید: رفع اشکال‌های همین دامنه، تغییر درخواستی جدید و نگهداری ترجمه‌ها پس از تحویل. این مرزها مهم‌اند، چون هرکدام منطق هزینه جداگانه‌ای دارد. عوامل آن را در هزینه سایت دو زبانه؛ برآورد توسعه تا نگهداری مرور کنید.
انتشار مرحله‌ای، پایش و برنامه بازگشت
در افزودن زبان به سایت، انتشار مرحله‌ای یعنی مجموعه‌ای کامل و آزموده از صفحات را منتشر کنید، نه ترجمه‌های نیمه‌کاره را. مثلاً اول صفحات خدمات و تماس، بعد کالاهای منتخب. در این مدت، نسخه اصلی تا حد ممکن دست‌نخورده می‌ماند.
پیش از انتشار، چهار چیز باید روشن باشد: مجری، تأییدکننده، زمان بررسی پس از انتشار و شرط توقف. پیشنهاد من این است که ازکارافتادن فرم اصلی را صریحاً محرک بازگشت تعریف کنید. در نتیجه اگر مشکلی پیش آمد، کسی وسط بحران سر تصمیم بازگشت بحث نمی‌کند.
مورد پایش | چه چیزی را نشان می‌دهد | مسئول پیشنهادی |
|---|---|---|
خطاهای سرور | مشکل فنی ناشی از تغییرات | توسعه‌دهنده |
صفحات پیدانشده (۴۰۴) | نشانی‌هایی که از نقشه جا مانده‌اند | مدیر پروژه |
دریافت فرم | سالم‌بودن مسیر تماس و سفارش | کارفرما |
تغییر زبان | باز شدن معادل درست هر صفحه | تیم آزمون |
وضعیت نمایه‌شدن | دیده‌شدن صفحات جدید در موتور جست‌وجو | مسئول سئو |
تناوب هر بررسی را با تیم توافق کنید. روزهای اول پس از انتشار معمولاً به نگاه نزدیک‌تری نیاز دارند؛ بنابراین بررسی‌های همان روزها را فشرده‌تر بچینید.
بازگشت هم صرفاً بازیابی کور پایگاه داده نیست. اگر پس از انتشار سفارش یا درخواستی ثبت شده باشد، بازگرداندن پشتیبان قبلی آن‌ها را پاک میکند. پس دستور بازگشت باید بگوید این داده‌ها چطور حفظ می‌شوند.
درباره رتبه هم صادق باشید؛ هیچ‌کس نمی‌تواند حفظ قطعی رتبه را وعده دهد. با این حال اثر را می‌شود سنجید: پیش از انتشار داده پایه، مثل ورودی صفحات اصلی، را ثبت کنید. بعد تغییرات ورودی هر زبان را کنار وضعیت فنی‌اش بررسی کنید.
نسخه پشتیبان قدیمی ممکن است سفارش‌ها یا درخواست‌های تازه را نداشته باشد. روش بازگشت کد و حفاظت از داده‌های پس از انتشار را جداگانه مشخص کنید.
پکیج‌هایPackages
ترجمه‌ی محتوای تخصصی در قیمت پایه نیست. اگر ترجمه با ما باشد، بر اساس تعداد کلمه و در پروپوزال جداگانه برآورد می‌شود.
برای درخواست برآورد چه اطلاعاتی بفرستیم؟
همین اطلاعات کوتاه برای برآورد اولیه سفارش چندزبانه کردن سایت کافی است:
نشانی سایت
فناوری سایت، اگر می‌دانید؛ مثلاً وردپرس یا کدنویسی اختصاصی
زبان و بازار مقصد
صفحات اولویت‌دار
اتصالها: CRM، درگاه، پیامک و موارد دیگر
وضعیت ترجمه: آماده، در حال تولید یا نیازمند مترجم
محدودیت زمانی، مثلاً یک نمایشگاه یا رویداد
هرچه را نمی‌دانید با «نیازمند بررسی» علامت بزنید؛ این کاملاً طبیعی است. اما در درخواست اولیه رمز مدیریت یا اطلاعات مشتریان را نفرستید. دسترسی را بعد از توافق و از مسیری امن بدهید.
وقتی پیشنهادها رسید، آن‌ها را با یک معیار مقایسه کنید. پیشنهاد خوب فرض‌ها، موارد خارج از دامنه، مسئول محتوا، نقاط تأیید، روش پذیرش و دوره پایش را روشن می‌نویسد. اولین چیزی که من در هر پیشنهاد دنبالش می‌گردم، بخش «خارج از دامنه» است. اما پیشنهادی که فقط یک عدد و یک تاریخ دارد، هنوز کامل نیست.
اگر برای تبدیل سایت تک زبانه به چندزبانه آماده‌اید، همین کاربرگ را برای ما بفرستید. در خدمات طراحی سایت چندزبانه نیاسا، اول سایت و دامنه را ارزیابی می‌کنیم و گزارش محدودیت‌ها را با شما مرور می‌کنیم. زمان و هزینه را بعد از همین ارزیابی پیشنهاد می‌دهیم، نه به‌صورت تضمین پیشاپیش.
نشانی سایت، زبان مقصد، صفحات اولویت‌دار و وضعیت ترجمه را برای بررسی دامنه چندزبانه‌سازی به نیاسا بفرستید.
پرسش‌های پرتکرار
۵آیا برای اضافه کردن زبان به سایت باید آن را از نو ساخت؟
نه، ابتدا باید امکان توسعه ساختار فعلی بررسی شود. اگر مدیریت ترجمه و نمایش زبان جدید با معماری موجود سازگار باشد، معمولاً می‌توان بخش‌های لازم را تغییر داد؛ بازسازی کامل نیاز به دلیل فنی مشخص دارد.
مدت زمان چندزبانه کردن سایت چقدر است؟
بدون شناخت قالبها، اتصالها و وضعیت ترجمه، زمان قابل اتکایی نمیتوان اعلام کرد. از مجری برنامهای بخواهید که زمان اجرای فنی را از انتظار برای محتوا و تأییدهای شما جدا نشان دهد.
آیا می‌توان فقط چند صفحه را انگلیسی کرد؟
بله، به شرطی که همان مجموعه یک مسیر کامل برای مخاطب بسازد. مثلاً صفحه خدمات انگلیسی باید به فرم قابل استفاده و پیام تأیید همان زبان برسد، نه به مسیری نیمه‌ترجمه.
آیا افزودن زبان جدید رتبه صفحات فارسی را پایین میآورد؟
افت رتبه پیامد اجتنابناپذیر این تغییر نیست، اما حفظ رتبه هم تضمینپذیر نیست. تغییر نادرست نشانیها یا تنظیمات نمایهسازی میتواند مشکل ایجاد کند؛ ثبت وضعیت قبلی و پایش پس از انتشار کمک میکند علت تغییرات بررسی شود.
ترجمه خودکار برای تحویل سایت کافی است؟
میتواند پیشنویس تهیه کند، اما معیار پذیرش متن نهایی نیست. محتوای حساس، اصطلاحات محصول و پیامهای مسیر خرید باید توسط فرد آشنا با زبان و کسبوکار بازبینی شوند.
