جابجایی کامل زبان گریزان

Summarize this content to 400 words in Persian Lang
بسیاری از وب سایت ها در تلاش برای ارائه زبان انتخابی به کاربران دچار مشکل می شوند. اما چند مرحله ساده می تواند تضمین کند که کاربران شما دقیقاً به زبان مورد نظر خود دست پیدا می کنند.

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

ما می‌توانیم این شکست‌های تغییر زبان را تقریباً به سه دسته دسته‌بندی کنیم: مفروضات بد، برچسب‌گذاری ضعیف، و تداوم غیر شهودی. بیایید به این موارد بپردازیم و سپس یک چک لیست از شیوه های خوب برای تغییر زبان ها در نظر بگیریم (و همچنین ایده هایی برای نحوه استفاده از محاسبات لبه برای آسان تر کردن این کار!).

فرضیات بد: رایج ترین اشتباهات

برچسب گذاری ضعیف: اجتناب از پرچم قرمز!

ماندگاری شکسته: چه چیزی را نباید فراموش کرد

محاسبات لبه برای نجات! (خیلی قابل پیش بینی است اما من شغلم را دوست دارم و غیره)

فرضیات بد

مکان فیزیکی کاربر بهترین نشانگر زبانی نیست که می فهمد. این همبستگی دارد: مطمئناً درست است که کاربر مستقر در مکزیک به احتمال بسیار بیشتری به زبان اسپانیایی صحبت می کند تا کاربر در فنلاند. اما این منطق منجر به یک تجربه واقعا ضعیف در زمانی که مردم در حال سفر به خارج از کشور خود هستند. با استفاده از Accept-Language هدر (که با منطقه سیستم دستگاه کاربر ارتباط برقرار می کند) راه بسیار بهتری برای تشخیص زبان انتخابی است.

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

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

Google Flights برای انجام صحیح این کار یک کلاس اصلی ارائه می‌دهد – اولویت زبان از روی زبان مرورگر، موقعیت مکانی از آدرس IP شما و ارز همگام‌سازی شده با مکان شناسایی می‌شود – اما همه به طور مستقل قابل تنظیم هستند:

به طور خلاصه:

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

برچسب گذاری ضعیف

پرچم ها روشی بحث برانگیز برای نشان دادن انتخاب زبان هستند. Neilsen، یک مشاور UX، متوجه شد که کاربران پرچم کشورشان را با زبان خود مرتبط می‌کنند، اما جایی که یک زبان در چندین کشور صحبت می‌شود، این می‌تواند یک میدان مین کاملاً سیاسی باشد.

نمونه مورد علاقه من از یک تغییر زبان با برچسب عجیب و غریب از یک شرکت مبل آلمانی.

ارتباط دادن زبان ها با مکان ها کاملاً اشتباه نیست. انگلیسی صحبت شده در بریتانیا به وضوح (کاملاً) با آنچه در ایالات متحده صحبت می شود یکسان نیست، و استاندارد برچسب های زبانی که معمولاً مورد استفاده قرار می گیرد IETF از این به عنوان پایه ای برای طبقه بندی انواع زبان استفاده می کند: en-GB، و en-US، مثلا.

مانند بسیاری از استانداردها که سعی در طبقه بندی و گروه بندی رفتار انسان دارند، برخی مصالحه لازم است. به درستی ممکن است این را بگویید en-IN این “گویش زبان انگلیسی است که مرکز ثقل فرهنگی خود را در هند دارد” اما اینکه دقیقاً چگونه آن لهجه را تعریف می کنید و چه کسی این کار را انجام می دهد بسیار قابل بحث است و بدیهی است که هر گونه از هر زبانی را می توان در هر مکان فیزیکی صحبت کرد. جهان.

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

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

Booking.com سایت‌های منطقه‌ای ندارد و از پرچم‌ها برای انتخاب زبان استفاده می‌کند، اما می‌تواند انواع منطقه‌ای صحیح زبان‌هایی را ارائه دهد که با پرچم‌ها مطابقت دارند (انواع چندگانه انگلیسی، اسپانیایی و پرتغالی را در اینجا بررسی کنید):

کار عالی تیم Booking.com!

اکنون IKEA را در نظر بگیرید که برخلاف Booking.com محصولات فیزیکی را می فروشد که بین کشورها متفاوت است و بنابراین سایت های منطقه ای دارند که هر کدام به زبان های مختلف ارائه می شوند.

برای مثال، ایکیا پرتغال، پرتغالی و انگلیسی را ارائه می‌کند، اما مشخص نمی‌کند که کدام یک از آن‌ها را استفاده می‌کنند («pt/en» به معنای «نوعی از انگلیسی که در پرتغال صحبت می‌شود» نیست، بلکه به معنای «پرتغال» است. وب سایت، ارائه شده به زبان انگلیسی”):

این یک الگوی بسیار متداول برای سایت‌هایی است که ارائه محصولات آنها بین کشورها متفاوت است. در اینجا سایت Storytel's Brazil است که فقط به زبان پرتغالی در دسترس است (احتمالاً pt-BR?):

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

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

پروژه Language Icon به مدت 15 سال در تلاش است تا این را استاندارد کند، و امروزه از کشش چندانی برخوردار نیست، در حالی که به نظر می‌رسد اکثر سایت‌های بزرگ جهانی یک کره را پذیرفته‌اند. مزیت رویکرد فهرست بزرگ زبان‌ها (معمولاً در پاورقی) این است که اگر دیواری از متن را ببینم که متوجه نمی‌شوم، می‌توانم CMD+F را فشار داده و کلمه «English» را در صفحه جستجو کنم و پیدا کنم. لینک نسخه انگلیسی

بدترین تخلف در اینجا داشتن یک گزینه منو در جایی به نام “تغییر زبان” است. هر انگلیسی زبانی که تا به حال توسط دوستانی که رابط کاربری تلفن خود را به کره ای تغییر داده اند مورد شوخی قرار گرفته باشد، با چالش هایی که این ارائه می دهد آشنا خواهد بود.

برچسب زدن واقعا مهم است. چند نکته را باید در نظر داشت:

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

پایداری غیر شهودی

آخرین سوارکار آخرالزمان زبان، چالش تداوم انتخاب زبان و زمان انجام این کار است. کاربران تمایل آزاردهنده ای برای خروج از سیستم، استفاده از بیش از یک دستگاه، و حتی ارسال لینک به دوستان و خانواده هایی که ممکن است زبان های مختلف را ترجیح دهند، دارند!

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

در ظاهر عجیب به نظر می رسد زیرا در اصل نحوه کار وب به این صورت است که URL یکسان باید به چندین زبان در دسترس باشد و سرور آدرسی را به شما می دهد که مطابق با شما باشد. Accept-Language ترجیح. با این حال، این ایده ایده آل «مذاکره محتوا» به ندرت در خالص ترین شکل خود در وب استفاده می شود، نه فقط به دلیل سردردهای فنی، بلکه به این دلیل که گاهی اوقات واقعاً تجربه درستی نیست.

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

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

اینجاست که ما باید تصمیمات هوشمندانه ای در مورد چگونگی تداوم انتخاب زبان و سلسله مراتب اولویت برای سیگنال های زبان مختلف بگیریم. من اصول زیر را ترجیح می دهم:

“اولویت کاربر” یک انتخاب صریح است که در حساب شما ذخیره شده است Accept-Language هدر اگر هیچ اولویت ذخیره شده ای وجود ندارد.
یک URL خاص زبان اولویت کاربر را لغو می کند، اما ناسازگاری بین این دو باید به کاربر علامت داده شود.

به عنوان مثال، اگر یکی از دوستان برای من لینکی به www.example.com و من قبلاً هرگز آنجا نرفته ام، دوستم ممکن است آن را به زبان فرانسوی دیده باشد، اما من آن را به زبان انگلیسی دریافت می کنم، زیرا Accept-Language.

با این حال، اگر آنها برای من یک لینک به www.example.com/fr/products/123، سپس صفحه را به زبان فرانسوی می بینم، با هشداری که از من می پرسد (به زبان انگلیسی) آیا می خواهم به انگلیسی سوئیچ کنم.

محاسبات لبه برای نجات

بدیهی است که اکنون می خواهم به شما بگویم که چگونه Fastly به همه چالش های زبان شما پاسخ می دهد، درست است؟ خوب، در واقع مدیریت جنبه های انتخاب زبان در لبه بسیار منطقی است. یکی از مهمترین کارهایی که باید انجام دهید، عادی سازی آن است Accept-Language ارزش. در Fastly VCL می توانید این کار را به صورت زیر انجام دهید:

set req.http.Accept-Language = accept.language_lookup(“en:de:fr:nl”, “de”, req.http.Accept-Language);

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

این مقداری مانند en-GB,en-US;q=0.9,en;q=0.8 به enو به این معنی است که می توانید نسخه های بسیار کمتری از صفحات خود را ذخیره کنید.

همچنین وقتی کاربران به صفحه اصلی شما می‌رسند، آنها را به یک URL خاص زبان هدایت کنید. یک زیر روال سفارشی VCL در اینجا این کار را انجام می دهد:

sub locale_redirect {
declare local var.urlLocale STRING;
declare local var.prefLocale STRING;
set var.urlLocale = if (req.url.path ~ “^/(en|de|fr|nl)/”, re.group.1, “”);
set var.prefLocale = if (
req.http.cookie:lang,
req.http.cookie:lang,
req.http.Accept-Language
);
if (var.urlLocale == “” && var.prefLocale != “”) {
error 600 var.prefLocale;
}
}

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

هر کاری که در لبه انجام می دهید، امیدوارم برخی از این موارد به شما کمک کند تا تجربیات حساس تر و شهودی تری برای کاربران خود ایجاد کنید!

همچنین به ما بگویید چه چیزی می‌سازید، در community.fastly.com.

set req.http.Accept-Language = accept.language_lookup("en:de:fr:nl", "de", req.http.Accept-Language);

sub locale_redirect {
  declare local var.urlLocale STRING;
  declare local var.prefLocale STRING;
  set var.urlLocale = if (req.url.path ~ "^/(en|de|fr|nl)/", re.group.1, "");
  set var.prefLocale = if (
    req.http.cookie:lang, 
    req.http.cookie:lang, 
    req.http.Accept-Language
  );
  if (var.urlLocale == "" && var.prefLocale != "") {
    error 600 var.prefLocale;
  }
}