הגדרת לוקליזציה לאנגלית: i18n, Hreflang, SEO

אתר Laravel מציג לפתע ממשק משתמש ברוסית למשתמש אמריקאי, מכיוון שה-middleware מפענח בצורה שגויה את Accept-Language. או שה-hreflang מוגדר בצורה שגויה, מה שגורם ל-Google לסמן את הגרסה האנגלית כשכפולה. לקוח מבריטניה לא הצליח לבצע הזמנה — התאריכים הוצגו בפורמט אמריקאי והמטבע בדולרים במקום בלירות שטרלינג. אלה הם כאבי גלובליזציה אופייניים, הניתנים לפתרון באמצעות לוקליזציה נכונה.

אנו מגדירים לוקליזציה אנגלית עבור SaaS ומסחר אלקטרוני כבר שנים. הניסיון שלנו כולל למעלה מ-15 פרויקטים עם לוגיקת תרגום מורכבת. אנו מבטיחים שלאחר ההתקנה האתר שלך יזוהה כראוי על ידי דפדפנים, ו-Google יאינדקס כראוי גרסאות רב-לשוניות. צור קשר לייעוץ להערכת היקף העבודה עבור הפרויקט שלך.

כיצד לקבוע את שפת המשתמש בשרת?

בשרת, השפה נקבעת על ידי כותרת Accept-Language. עם זאת, הסתמכות עליה בלבד היא מסוכנת: ייתכן שהמשתמש מצפה לשפה אחרת. השיטה המומלצת היא עדיפות: פרמטר מפורש ב-URL (lang), עוגיה/סשן, ולאחר מכן Accept-Language.

Middleware ב-Laravel הוא הגישה הסטנדרטית:

// App\Http\Middleware\SetLocale
public function handle(Request $request, Closure $next): mixed
{
    $locale = $request->get('lang') ?? $request->session()->get('locale') ?? $this->parseAcceptLanguage($request->header('Accept-Language'));
    $locale = in_array($locale, $this->available) ? $locale : 'en';
    App::setLocale($locale);
    return $next($request);
}

פירוש Accept-Language עם איכות (q-factor):

private function parseAcceptLanguage(?string $header): string {
    if (!$header) return 'en';
    preg_match_all('/([a-z]{2})(?:-[A-Z]{2})?(?:;q=([0-9.]+))?/', $header, $m);
    $langs = array_combine($m[1], array_map(
        fn($q) => $q === '' ? 1.0 : (float) $q,
        $m[2]
    ));
    arsort($langs);
    foreach (array_keys($langs) as $lang) {
        if (in_array($lang, $this->available)) return $lang;
    }
    return 'en';
}

מדוע hreflang הוא קריטי ל-SEO בינלאומי?

ללא hreflang, מנועי חיפוש עלולים להציג את הגרסה השגויה או לקנוס על תוכן כפול. יש לציין במפורש את הגרסה האנגלית עבור אזורים en-US, en-GB, en-AU. הקפד לכלול x-default — דף עבור שפות שאינן ברשימה. לפי תיעוד Google, הגדרת hreflang נכונה מגדילה את החשיפה ב-30-50%. מידע נוסף על התקן ניתן למצוא בויקיפדיה.

<link rel="alternate" hreflang="en" href="https://example.com/en/" />
<link rel="alternate" hreflang="en-US" href="https://example.com/en-us/" />
<link rel="alternate" hreflang="ru" href="https://example.com/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />

עיצוב נתונים: Intl API לעומת המרה ידנית

Intl API הוא התקן לבינאום ב-JavaScript. הוא טוב פי 10 מהמרה ידנית: הוא מטפל בכל הניואנסים האזוריים ללא קוד נוסף. הIntl API חיוני ללוקליזציה מודרנית.

דוגמה ב-TypeScript:

const date = new Date('2024-03-28');
new Intl.DateTimeFormat('en-US', { dateStyle: 'long' }).format(date); // "March 28, 2024"
new Intl.DateTimeFormat('en-GB', { dateStyle: 'long' }).format(date); // "28 March 2024"

עבור מטבע, השתמש ב-// App\Http\Middleware\SetLocale public function handle(Request $request, Closure $next): mixed { $locale = $request->get('lang') ?? $request->session()->get('locale') ?? $this->parseAcceptLanguage($request->header('Accept-Language')); $locale = in_array($locale, $this->available) ? $locale : 'en'; App::setLocale($locale); return $next($request); } :

new Intl.NumberFormat('en-US', { style: 'currency', currency: 'USD' }).format(99.99); // "$99.99" 

מדוע ריבוי (Pluralization) הוא צוואר בקבוק בלוקליזציה?

לשמות עצם באנגלית יש שני מספרים: יחיד ורבים. עם זאת, לשפות רבות (רוסית, ערבית) יש יותר כללים. Laravel משתמש ב-private function parseAcceptLanguage(?string $header): string { if (!$header) return 'en'; preg_match_all('/([a-z]{2})(?:-[A-Z]{2})?(?:;q=([0-9.]+))?/', $header, $m); $langs = array_combine($m[1], array_map( fn($q) => $q === '' ? 1.0 : (float) $q, $m[2] )); arsort($langs); foreach (array_keys($langs) as $lang) { if (in_array($lang, $this->available)) return $lang; } return 'en'; } עם אינדקסים, אך בפרונטאנד Intl.PluralRules מטפל בזה בצורה גמישה יותר. ללא ריבוי נכון, מתרחשות שגיאות כמו "1 items" במקום "1 item". אנו תמיד בודקים צורות ריבוי עבור כל התרגומים.

כיצד אנו בוחרים אחסון תרגומים?

הבחירה בין קבצים, מסד נתונים ושירותי ענן תלויה בפרויקט. קבצים (PHP, JSON) מהירים ופשוטים אך קשים לסקלציה עבור צוותים גדולים. מסד נתונים נוח לתרגומים דינמיים אך מוסיף זמן השהייה. פתרונות ענן (Lokalise, Crowdin) מיועדים לארגונים עם לוקליזציה מתמשכת.

מה כלול בעבודה

• בדיקת לוקליזציה נוכחית: זיהוי שגיאות ב-middleware, hreflang, פורמטים.
• הגדרת Middleware לזיהוי שפה עם עדיפות נכונה.
• הגדרת hreflang עבור אזורים עיקריים ו-x-default.
• התאמת פורמטים של תאריך, מספר ומטבע באמצעות Intl API.
• כתיבת בדיקות לאימות לוקליזציה בדפדפנים שונים.
• תיעוד על מבנה התרגום ותהליך הוספת שפות חדשות.
• הכשרת הצוות לשימוש במערכת התרגום.

תהליך העבודה

1. אנליטיקה — בדיקת הקוד הנוכחי, זיהוי בעיות לוקליזציה.
2. עיצוב — בחירת אחסון תרגומים (קבצים, מסד נתונים או ענן).
3. יישום — כתיבת middleware, שילוב תרגומים, hreflang.
4. בדיקות — אימות בדפדפנים, מכשירים ואזורים שונים.
5. פריסה — שחרור לייצור, ניטור שגיאות.

לוחות זמנים ועלות

לוח זמנים — בין יום ל-3 ימי עסקים לאתר טיפוסי. עבור פרויקטים מורכבים עם תרגומים מותאמים אישית או אינטגרציות, עד 5 ימים. העלות מחושבת באופן אישי — צור קשר להערכה.

שגיאות לוקליזציה אופייניות

• סדר שגוי של מקורות שפה (Accept-Language לא אחרון).
• חוסר ב-x-default ב-hreflang.
• שימוש בעיצוב תאריכים ידני במקום Intl API.
• שכחת צורות ריבוי בתרגומים.

הימנעות מאלה תעניק לך לוקליזציה יציבה שמשרתת כראוי משתמשים דוברי אנגלית ומשפרת דירוגים בינלאומיים במנועי חיפוש.

הזמן הגדרת לוקליזציה אנגלית וקבל פתרון סוהר עם אחריות לאיכות. צור קשר לייעוץ.