RapidStoreפתיחת חנות אונליין בעברית ובאנגלית יכולה להרחיב משמעותית את הקהל של העסק. לקוחות בישראל יכולים לקבל חוויה מלאה בעברית, ובמקביל לקוחות מחוץ לישראל או קהל דובר אנגלית יכולים לגלוש, להבין את המוצרים ולבצע רכישה בשפה שנוחה להם.
אבל חנות רב לשונית אינה רק כפתור שמחליף שפה. אם עמוד הבית מתורגם אבל המוצרים נשארים בעברית, אם checkout מופיע בשפה אחרת או אם קישורים מחזירים את המשתמש ל-slug שלא מתאים לשפה, החוויה מרגישה חלקית ולא מקצועית.
כדי לעשות את זה נכון צריך לחשוב על השפה כחלק מהמבנה של החנות - תוכן, URLs, SEO, כיוון תצוגה, navigation, checkout, אימיילים, מדיניות ושירות לקוחות.
מתי בכלל כדאי להוסיף אנגלית
לא כל חנות צריכה להתחיל עם שתי שפות. אם העסק מוכר רק לקהל מקומי והלקוחות כמעט כולם דוברי עברית, ייתכן שעדיף להשקיע קודם בחנות אחת מלאה ואיכותית.
מצד שני, אם יש ביקוש מחוץ לישראל, קהל תיירותי, לקוחות דוברי אנגלית, פעילות בינלאומית או תוכנית להתרחבות, אנגלית יכולה להיות חלק משמעותי מהאסטרטגיה.
- לקוחות מחוץ לישראל כבר פונים לעסק
- המוצרים מתאימים למשלוח בינלאומי
- יש חיפושים באנגלית סביב המוצרים
- העסק מפרסם לקהל דובר אנגלית
- יש שיתופי פעולה או לקוחות בינלאומיים
- המותג רוצה להיראות נגיש בשוק רחב יותר
לא מוסיפים שפה שאין יכולת לתחזק
כל שפה נוספת מכפילה חלק מהעבודה. מוצר חדש, קטגוריה חדשה, מאמר, מבצע, מדיניות או שינוי חשוב צריכים לקבל גרסה מתורגמת.
חנות עם עברית מצוינת ואנגלית מוזנחת יכולה ליצור רושם פחות מקצועי מחנות בעברית בלבד. לכן כדאי להוסיף שפה כאשר יש תהליך ברור לתחזוקה שלה.
תרגום ממשק אינו מספיק
כפתורים כמו הוספה לעגלה, תשלום וחזרה לחנות הם רק שכבת UI. התוכן המרכזי של החנות נמצא במוצרים, קטגוריות, עמודי תוכן ומדיניות.
חוויית אנגלית אמיתית צריכה לכלול גם שמות מוצרים, תיאורים, מאפיינים, כותרות SEO, קטגוריות, מאמרים ותוכן שיווקי.
כל מוצר צריך תרגום עצמאי
מוצר צריך לשמור על identity אחת במערכת, אבל להכיל translations נפרדים לכל locale.
כך inventory, price ו-variant הם אותם נתונים עסקיים, בזמן שהשם, התיאור ונתוני SEO יכולים להשתנות לפי השפה.
לא יוצרים מוצר כפול לכל שפה
יצירת מוצר עברי ומוצר אנגלי כשתי רשומות נפרדות גורמת לבעיות מלאי, הזמנות, analytics ותחזוקה.
המודל הנכון הוא product אחד עם translations נפרדים, כך שהעסק מנהל מלאי ומחיר במקום אחד.
גם קטגוריות צריכות translations
אם קטגוריה נקראת בעברית אביזרים ובאנגלית Accessories, שתיהן צריכות לייצג את אותה category עסקית ולא שתי קטגוריות שונות.
כך מוצר שמשויך לקטגוריה ממשיך להיות חלק ממנה בכל השפות, ורק התוכן הציבורי משתנה.
Slug צריך להיות מותאם לשפה
URL בעברית יכול להשתמש ב-slug עברי ועמוד אנגלי ב-slug אנגלי. לדוגמה, /he/products/מוצר-לדוגמה מול /en/products/example-product.
זה יוצר URLs טבעיים יותר למשתמשים ומאפשר לכל locale לקבל כתובת שמתאימה לתוכן שלו.
לא מתרגמים namespaces ללא צורך
אפשר לשמור namespaces טכניים יציבים כמו products, categories ו-articles בכל השפות, ורק לתרגם את ה-slug של הישות.
מבנה כזה מפשט routing, redirects ותחזוקה ועדיין נותן לכל מוצר כתובת מקומית ברורה.
Prefix של locale יוצר הפרדה ברורה
מבנה כמו /he ו-/en מאפשר למערכת ולמנועי חיפוש לדעת באיזו שפה כל עמוד נמצא.
הוא גם מונע מצב שבו אותו URL משתנה לפי cookie או browser language בלי כתובת יציבה שאפשר לשתף ולאנדקס.
URL צריך להיות יציב גם אחרי שינוי שם
אם בעל החנות משנה את שם המוצר, אין צורך לשנות אוטומטית את ה-slug. URL שכבר מופיע בגוגל וצבר קישורים עדיף לשמור יציב.
אם כן משנים slug, צריך לשמור redirect מהכתובת הישנה לחדשה.
Language switcher צריך לעבור לעמוד המקביל
אם המשתמש נמצא בעמוד מוצר בעברית ולוחץ English, הוא מצפה להגיע לאותו מוצר באנגלית, לא לעמוד הבית.
לכן כל עמוד צריך לדעת מהי הכתובת המקבילה שלו ב-locales האחרים.
לא ממציאים URL אם אין תרגום
אם מוצר קיים רק בעברית ולא פורסם באנגלית, language switcher לא צריך לבנות slug באנגלית שלא באמת קיים.
עדיף להשבית את השפה באותו עמוד או להשתמש בהתנהגות מוגדרת אחרת מאשר לשלוח את המשתמש ל-404.
Hebrew דורש RTL אמיתי
עברית אינה רק טקסט מיושר לימין. כל layout צריך להתחשב ב-direction: תפריטים, cards, tables, dialogs, dropdowns, icons, breadcrumbs וכפתורי navigation.
אם רק text-align משתנה אבל flex direction, icons או controls נשארים כמו באנגלית, התוצאה מרגישה לא טבעית.
English צריך להיות LTR אמיתי
מעבר לאנגלית צריך לשנות גם את direction הכללי של הממשק ל-LTR. רכיבים לא צריכים להישאר במבנה RTL רק משום שהחנות נבנתה קודם בעברית.
ערכים טכניים נשארים LTR גם בחנות עברית
URLs, SKUs, tracking numbers, email addresses, IDs וערכים טכניים אחרים בדרך כלל צריכים להופיע LTR גם בתוך layout עברי.
אחרת מספרים וסימנים יכולים להיראות בסדר שגוי ולהקשות על העתקה.
לא מתרגמים שמות מותג בכוח
אם למותג או למוצר יש שם רשמי באנגלית, אין צורך לייצר תרגום מילולי שלא נמצא בשימוש.
המטרה היא localization טבעי ולא החלפת כל מילה באופן אוטומטי.
Localization חשוב יותר מתרגום מילולי
טקסט שיווקי שעובד בעברית לא תמיד נשמע טבעי באנגלית כאשר מתרגמים אותו מילה במילה.
צריך לשמור את המשמעות, אבל להתאים ניסוח, sentence structure, מונחים וציפיות של הקהל המקומי.
גם מידות ויחידות יכולות לדרוש התאמה
עסק שפונה למדינות שונות יכול להידרש להציג centimeters לצד inches או kilograms לצד pounds.
זה אינו רק תרגום שפה אלא localization של המידע המסחרי.
מטבע אינו חייב להיות קשור לשפה
עברית אינה אומרת בהכרח ILS ואנגלית אינה אומרת בהכרח USD. שפה ומטבע הם שני concepts שונים.
חנות יכולה להיות באנגלית ועדיין למכור בשקלים, או בעברית ולמכור במטבע אחר בהתאם למודל העסקי.
אל תשנו מטבע אוטומטית רק בגלל language switch
מעבר locale לא צריך לשנות את המחיר או המטבע אלא אם החנות תומכת במפורש במודל multi-currency.
שינוי בלתי צפוי של מחיר בזמן מעבר שפה יכול לבלבל את הלקוח.
checkout חייב להיות מתורגם במלואו
אחד המקומות הגרועים ביותר לעבור פתאום לשפה אחרת הוא checkout. בדיוק בשלב שבו הלקוח מזין פרטים ומשלם, כל label והודעת שגיאה צריכים להיות ברורים.
- פרטי לקוח
- כתובת
- שיטת משלוח
- מחיר משלוח
- קופון
- סיכום הזמנה
- אמצעי תשלום
- validation messages
- כפתורי תשלום ואישור
Payment provider יכול להשפיע על השפה
אם התשלום עובר לדף חיצוני, כדאי לבדוק האם provider מאפשר לשלוח locale או להציג UI מתאים לשפת הלקוח.
מעבר מעמוד אנגלי למסך תשלום בעברית בלבד יכול לפגוע בחוויה של לקוח בינלאומי.
כתובת בינלאומית דורשת fields גמישים
טופס שנבנה רק לכתובת ישראלית לא תמיד מתאים ללקוחות בחוץ לארץ. State, province, postal code ומבנה כתובת משתנים בין מדינות.
אם החנות מוכרת בינלאומית, checkout צריך להיות מסוגל להתמודד עם המבנים הרלוונטיים.
טלפון צריך להתאים למדינה
לקוחות בינלאומיים צריכים להיות מסוגלים להזין country code ומספר תקין בלי validation שמניח שכל המספרים ישראליים.
משלוחים צריכים להתאים ל-locale אבל לא להיות תלויים בו
לקוח שגולש באנגלית עדיין יכול להיות בישראל, ולקוח בעברית יכול להזמין לחוץ לארץ אם החנות תומכת בכך.
זמינות shipping צריכה להיקבע לפי כתובת, אזור וכללי החנות ולא רק לפי השפה.
מדיניות החנות צריכה להיות זמינה בכל שפה פעילה
Returns, shipping, privacy ו-terms הם תוכן מרכזי בתהליך קנייה. אם החנות פונה ללקוחות באנגלית, לא נכון להשאיר את כל המדיניות בעברית בלבד.
במסמכים משפטיים חשוב במיוחד לוודא שהתרגום מדויק ומתאים לדרישות העסק והשוק, ולא להסתמך אוטומטית על תרגום מכונה ללא בדיקה.
אימיילים הם חלק מהחוויה הרב לשונית
לקוח שקנה באנגלית מצפה בדרך כלל לקבל אישור הזמנה באנגלית. confirmation, password reset, shipping update והודעות אחרות צריכים להשתמש ב-locale של הלקוח או ההזמנה.
שמרו locale על ההזמנה
כדאי לשמור snapshot של השפה שבה בוצעה הרכישה. כך גם אם המשתמש משנה העדפה אחר כך, אפשר לדעת באיזו שפה לשלוח הודעות שקשורות להזמנה המקורית.
גם שמות מוצרים בהזמנה צריכים snapshot
אם שם המוצר משתנה אחרי הרכישה, order history לא צריך להשתנות. שמירת title בזמן ההזמנה חשובה גם בשפה המתאימה.
SEO רב לשוני דורש עמוד נפרד לכל locale
גוגל צריך כתובת יציבה לכל גרסת שפה. עמוד אחד שמשנה טקסט לפי cookie בלבד מקשה על indexing ועל שיתוף.
URLs נפרדים מאפשרים לכל locale לקבל title, description, canonical ו-content מתאימים.
Canonical צריך להצביע לגרסת השפה עצמה
העמוד העברי צריך canonical לכתובת העברית והעמוד האנגלי לכתובת האנגלית שלו.
לא נכון בדרך כלל להגדיר את כל השפות canonical לגרסה אחת, כי אז מנוע החיפוש עלול להבין שהגרסאות האחרות הן duplicates שלא צריך לאנדקס.
hreflang מחבר בין הגרסאות
hreflang עוזר למנועי חיפוש להבין שעמוד עברי ועמוד אנגלי מייצגים את אותו מוצר או תוכן בשפות שונות.
כל URL צריך להפנות לגרסאות המקבילות הקיימות. אם locale מסוים אינו קיים, לא כדאי להמציא עבורו href.
x-default יכול לשמש fallback
כאשר יש גרסה כללית או שפת ברירת מחדל, x-default יכול להצביע לכתובת שהמערכת רוצה להציע כאשר אין התאמה טובה יותר.
יש לבחור אותו כחלק מאסטרטגיית locale ברורה ולא להוסיף אותו באופן שרירותי.
Sitemap צריך לכלול את כל הגרסאות הציבוריות
מוצר שפורסם בעברית ובאנגלית יכול להופיע בשתי כתובות נפרדות ב-sitemap בהתאם למבנה האתר.
אם התרגום האנגלי עדיין draft, הוא לא צריך להיכנס כאילו הוא עמוד ציבורי.
SEO title צריך להיכתב בכל שפה
אין טעם להשתמש בכותרת עברית בתוצאת חיפוש אנגלית. לכל translation צריך להיות title ו-description שמתאימים לביטויים ולניסוח של אותו קהל.
מחקר מילות מפתח צריך להתבצע מחדש באנגלית
מילת החיפוש הפופולרית בעברית אינה בהכרח translation ישיר של הביטוי הפופולרי באנגלית.
בכל שוק כדאי לבדוק כיצד אנשים באמת מחפשים ולא פשוט לתרגם keyword list.
תוכן מאמרים לא חייב להיות mirror מוחלט
אפשר לשמור אותו נושא בשתי שפות, אבל ייתכן שקהל אנגלי צריך דוגמאות, שאלות או הקשר שונים.
אם נדרש, localization יכול להיות עמוק יותר מתרגום אחד לאחד.
אל תשתמשו בתרגום אוטומטי ללא review
AI ו-machine translation יכולים לחסוך זמן, במיוחד בקטלוג גדול, אבל טעויות בשם מוצר, חומר, מידה או מדיניות יכולות להיות משמעותיות.
תוכן שמגיע ללקוח צריך לעבור review, במיוחד בעמודים מסחריים ומשפטיים.
AI יכול לעזור לייצר draft מהיר
אפשר להשתמש ב-AI כדי ליצור תרגום ראשוני של product description או article, ואז לערוך אותו כדי להתאים למותג ולמונחים של התחום.
כך חוסכים זמן בלי לוותר על בקרת איכות.
שמרו glossary של מונחים חשובים
אם העסק משתמש שוב ושוב במונחים מקצועיים, כדאי להחליט כיצד הם מתורגמים ולשמור על אותה בחירה בכל הקטלוג.
Glossary מונע מצב שבו אותו feature מקבל שלושה שמות שונים באנגלית.
שמות variants צריכים להיות עקביים
Color, Size, Material ושמות אפשרויות אחרות צריכים להופיע בצורה אחידה. אם Blue נקרא במקום אחד Blue ובמקום אחר Navy בלי סיבה, הלקוח יכול לחשוב שמדובר בשתי אפשרויות שונות.
SKU אינו צריך תרגום
SKU הוא identifier טכני וצריך להישאר יציב בין השפות. אותו variant צריך לשמור על אותו SKU גם אם display name משתנה.
Inventory משותף לכל השפות
הגרסה האנגלית והעברית מוכרות את אותו מלאי. אם נמכרה היחידה האחרונה דרך /en, גם /he צריך להציג שהמוצר אינו זמין.
זו סיבה נוספת לא ליצור product נפרד לכל translation.
Price צריך להגיע מאותו מקור
שפה לא צריכה ליצור pricing data כפול. אותו product ו-variant משתמשים באותו מחיר בסיס במסגרת המטבע של החנות.
מבצעים צריכים לעבוד באופן זהה בכל locale
אם מוצר נמצא במבצע, ה-discount צריך להיות זהה מבחינה עסקית בעברית ובאנגלית. רק הטקסט שמסביר את המבצע משתנה.
קופון אינו תלוי בשפה
Promotion eligibility צריכה להיות server-side לפי cart, customer וכללי המבצע. locale אינו צריך לשנות את המחיר אלא אם קיים כלל עסקי מפורש.
תצוגת מחיר יכולה להשתנות לפי locale
גם כאשר הערך זהה, formatting יכול להשתנות. מיקום currency symbol, separators וכתיבת המספר יכולים להיות locale-aware.
הערך הכספי עצמו נשאר אותו value עסקי.
תאריכים צריכים formatting מתאים
תאריך כמו 03/04/2026 יכול להתפרש אחרת בשווקים שונים. במקומות שבהם זה חשוב, כדאי להשתמש בפורמט locale-aware או בניסוח שמונע ambiguity.
שעות פעילות צריכות לכלול timezone כשצריך
עסק שמשרת לקוחות בינלאומיים צריך להבהיר באיזה timezone פועלות שעות שירות, cutoff למשלוח או מבצעים מוגבלי זמן.
WhatsApp links צריכים להישאר canonical לפי השפה
אם משתמש משתף מוצר מהעמוד האנגלי, הקישור צריך להיות לגרסה האנגלית של אותו מוצר. לא נכון לשלוח את המקבל אוטומטית לעברית.
Open Graph צריך להיות מתורגם
Title, description ו-image metadata שמשמשים לשיתוף צריכים להתאים ל-locale של העמוד.
כך preview באנגלית מציג מוצר באנגלית ולא תערובת שפות.
Structured data צריך להתאים לעמוד
Product structured data צריך להשתמש בשם וב-description שמוצגים באותו locale תוך שמירה על אותם price ו-availability עסקיים.
Breadcrumbs צריכים להיות localized
קטגוריה יכולה להציג שם עברי ב-/he ושם אנגלי ב-/en, למרות ששני ה-breadcrumbs מצביעים לאותה entity עסקית.
Header ו-footer צריכים להיות מלאים בכל שפה
תפריט שבו חלק מהפריטים בעברית וחלק באנגלית גורם לחנות להרגיש לא גמורה. navigation, footer וקישורי policy צריכים לקבל translations מלאים.
אל תתרגמו URLs טכניים
API endpoints, webhook URLs, tokens ו-admin paths אינם merchant-facing content ולא צריכים לעבור localization רק משום שה-dashboard מוצג בעברית.
Admin יכול להיות בשפה אחרת מה-storefront
בעל העסק יכול לנהל חנות בעברית בזמן שה-storefront תומך בעברית ובאנגלית. locale של dashboard ו-locales של החנות הם concepts נפרדים.
Default locale צריך להיות מוגדר לכל חנות
המערכת צריכה לדעת מהי שפת ברירת המחדל של storefront ואילו locales נתמכים.
השפה הראשית משפיעה על fallback, navigation וכניסה לכתובת הבסיס.
Supported locales צריכים להיות tenant-scoped
במערכת multi-tenant כל חנות מחליטה אילו שפות היא תומכת. חנות אחת יכולה להיות he בלבד ואחרת en בלבד או he ו-en.
אין לחשוף locale או translation של tenant אחר.
Fallback צריך להיות מוגדר ולא מקרי
אם translation חסר, המערכת צריכה להחליט האם להסתיר את הישות באותה שפה, להשתמש ב-fallback או להציג state אחר.
ב-storefront ציבורי, הצגת תערובת אוטומטית של שפות יכולה להיות בעייתית ולכן כדאי לבחור policy עקבית.
Draft translation לא צריך להפוך לציבורי בטעות
יכול להיות שמוצר published בעברית בזמן שהתרגום האנגלי עדיין בעבודה. publication state צריך לדעת להבחין בין הגרסאות ולא לחשוף תרגום חלקי.
שינוי תרגום לא צריך לשנות נתונים עסקיים
עריכת English title אינה אמורה להשפיע על price, inventory או Hebrew title. separation בין translation data ל-business data מונעת side effects.
Search צריך לעבוד בכל שפה
לקוח באנגלית צריך למצוא product לפי English title ולא להידרש לדעת את השם העברי.
Index החיפוש צריך לכלול translations בצורה tenant-scoped ובהתאם ל-locale הפעיל.
Filter labels צריכים להיות translated
Size, color, availability, price ו-labels אחרים צריכים להופיע בשפת storefront. values מסוימים יכולים להיות translations בעוד data underlying נשאר אחיד.
Customer account צריך להמשיך באותה שפה
Login, registration, order history, addresses ו-account settings הם חלק מה-storefront. מעבר פתאומי לעברית מתוך חנות אנגלית יוצר חוויה לא עקבית.
Order history יכול להציג snapshot בשפת הרכישה
אפשר לבחור להציג product title כפי שהיה בזמן ההזמנה או להשתמש בתרגום הנוכחי. מבחינת תיעוד, snapshot בשפת ההזמנה בדרך כלל שומר בצורה טובה יותר על ההיסטוריה.
שירות לקוחות צריך להבין את השפה שהעסק מבטיח
אם החנות מפרסמת תמיכה באנגלית, כדאי לוודא שמישהו באמת יכול לענות באנגלית או שקיים תהליך שמאפשר טיפול איכותי.
Storefront באנגלית יוצר ציפייה שגם תהליך השירות יהיה נגיש.
Refund ו-return communication צריכים להיות localized
לקוח שפונה לגבי refund צריך לקבל הסבר בשפה שבה הוא מבין את תנאי ההזמנה. template messages ו-status updates צריכים לתמוך בכך.
Analytics צריך לשמור locale dimension
כדאי לדעת איזו שפה מייצרת traffic, conversion ו-revenue. כך ניתן להבין האם הגרסה האנגלית באמת מביאה ערך עסקי.
בלי segmentation לפי locale, קשה לדעת האם ההשקעה בתרגום משתלמת.
בדקו Conversion Rate לפי שפה
אם אנגלית מביאה traffic אבל conversion נמוך משמעותית, ייתכן שהתוכן חלקי, המשלוח אינו מתאים לקהל או checkout אינו localized מספיק.
בדקו Revenue לפי locale
Traffic הוא לא המדד היחיד. ייתכן ששפה מסוימת מביאה פחות מבקרים אבל Average Order Value גבוה יותר.
בדקו אילו עמודים באנגלית מקבלים impressions
Search Console יכול להראות אילו queries ו-pages באנגלית מתחילים לקבל חשיפה. הנתונים האלה יכולים להנחות אילו קטגוריות ומאמרים לתרגם או לשפר קודם.
לא חייבים לתרגם את כל הקטלוג ביום הראשון
עסק עם אלפי מוצרים יכול להתחיל מהמוצרים והקטגוריות המרכזיים, בתנאי שהמערכת יודעת לא לחשוף pages לא שלמים.
גישה הדרגתית מאפשרת לבדוק האם השוק מגיב לפני השקעה גדולה בכל הקטלוג.
מתחילים מהעמודים עם הערך הגבוה ביותר
- עמוד הבית
- קטגוריות מרכזיות
- המוצרים הנמכרים ביותר
- Checkout
- Shipping policy
- Returns policy
- About
- Contact
- עמודי SEO חשובים
- מאמרים שמקבלים traffic
בונים workflow לתרגום מוצר חדש
כאשר merchant יוצר מוצר, כדאי שיהיה תהליך ברור: ליצור content בשפת המקור, להוסיף translation, לבצע review ורק אז לפרסם את locale הנוסף.
כך לא נוצרים עמודים חצי גמורים.
AI יכול להשתלב בתוך workflow ולא להחליף אותו
AI יכול להציע English title, description, SEO metadata ו-excerpt במהירות. merchant עדיין צריך לראות preview, לערוך ולאשר.
המערכת יכולה לחסוך עבודה בלי לאבד ownership על התוכן.
שמרו Translation Status
בקטלוג גדול כדאי לדעת אילו entities תורגמו, אילו ממתינים ל-review ואילו חסרים.
Status כזה מונע חיפוש ידני אחר products שלא קיבלו גרסה אנגלית.
עדכון תוכן בשפה אחת יכול לדרוש review בשנייה
אם תיאור המוצר בעברית השתנה מהותית, English translation עלול להפוך outdated.
אפשר לסמן אותו כ-needs review במקום לשנות אותו אוטומטית ולסכן תוכן שכבר נערך ידנית.
לא כל שינוי דורש תרגום מחדש
שינוי inventory או price אינו translation change. מערכת טובה יודעת להפריד בין fields עסקיים ל-content fields כדי לא לייצר עבודה מיותרת.
תמונות בדרך כלל משותפות לשפות
Product media אינו צריך להיות מועתק לכל locale. אותו MediaAsset יכול לשמש את כל translations.
אם תמונה עצמה מכילה טקסט, ייתכן שיהיה צורך בגרסה שונה לפי שפה, אבל זו החלטה תוכנית ולא סיבה לשכפל את כל gallery.
Alt text יכול להיות localized
אם המערכת מנהלת alt text כחלק מהתוכן, ניתן לתרגם אותו לפי locale תוך שימוש באותו asset.
Banner עם טקסט מוטמע בתמונה מקשה על localization
אם כל הכותרת נמצאת בתוך JPEG, צריך ליצור תמונה חדשה לכל שפה. עדיף במקרים רבים לשמור טקסט כ-HTML ולתת לתמונה להיות visual בלבד.
Storefront editor צריך לכבד RTL ו-LTR
עורך עמודים שמאפשר לבנות hero, grids ו-sections צריך להראות preview אמיתי לכל direction.
Section שעובד באנגלית עלול להישבר בעברית אם alignment או ordering נבנו בצורה קשיחה.
Design tokens צריכים להיות direction-aware
במקום להשתמש תמיד ב-left ו-right, רכיבים יכולים להשתמש ב-start ו-end כאשר זה מתאים. כך אותו component עובד בצורה טבעית בשתי השפות.
Icons directional צריכים להתהפך
חץ next, chevron ב-breadcrumb או icon של navigation יכול לדרוש mirror ב-RTL. אייקון שאין לו משמעות כיוונית לא צריך להתהפך סתם.
Tables דורשים בדיקה מיוחדת
Order history, variant tables ו-admin views צריכים לתמוך בשתי directions בלי לשבור columns, actions או technical values.
Dialogs ו-dropdowns צריכים להיפתח בכיוון מתאים
מיקום text, action buttons ו-menu alignment צריך להתאים ל-direction הפעיל כדי שהממשק ירגיש מקומי ולא תרגום על גבי UI באנגלית.
SEO של עברית ואנגלית צריך להימדד בנפרד
ייתכן שהאתר חזק בגוגל ישראל בעברית ועדיין חדש לחלוטין בחיפושים באנגלית. אין לצפות שה-authority והביצועים יהיו זהים מהיום הראשון.
תחרות באנגלית יכולה להיות גדולה יותר
ביטוי מסוים בעברית יכול להכיל מעט מתחרים, בעוד הגרסה האנגלית מתחרה מול אתרים מכל העולם.
לכן תוכן באנגלית צריך להיבחן מול השוק האמיתי ולא רק מול איכות הגרסה העברית.
International SEO אינו רק Translation SEO
אם העסק פונה למדינות שונות, ייתכן שצריך להתייחס גם למשלוחים, currency, taxes, policies, availability ו-market expectations.
שפה היא רק חלק מה-localization המסחרי.
לא פותחים שוק בינלאומי בלי לבדוק fulfillment
אין הרבה ערך ב-SEO באנגלית אם העסק לא יכול לשלוח את המוצר ללקוחות שמגיעים ממנו או אם עלויות המשלוח הופכות את ההצעה ללא תחרותית.
שקיפות סביב מכס חשובה
במשלוח בינלאומי לקוחות צריכים לדעת אם ייתכנו duties או taxes נוספים בעת קבלת החבילה.
המידע צריך להיות ברור ככל שניתן ולא להופיע רק לאחר הרכישה.
בדקו את כל מסלול הרכישה בכל שפה
- פתחו את עמוד הבית
- עברו לקטגוריה
- פתחו מוצר
- עברו בין variants
- הוסיפו לעגלה
- בדקו cart labels
- עברו ל-checkout
- הזינו כתובת
- בחרו shipping
- פתחו payment
- השלימו הזמנה
- בדקו confirmation page
- בדקו confirmation email
- פתחו order history
- בדקו return ו-shipping policies
- שתפו product link
- עברו לשפה השנייה מאותו product
בדקו שאין ערבוב שפות
אחת התקלות הנפוצות היא English page עם button בעברית, category שלא תורגמה או error message בשפת ברירת המחדל.
QA צריך לחפש בכוונה את המקומות הקטנים האלה.
בדקו empty states ו-errors
תרגום בדרך כלל מתמקד במסך הרגיל, אבל לקוח יכול לראות no results, out of stock, payment failed או invalid coupon. גם states כאלה צריכים localization מלא.
בדקו SEO source ולא רק את המסך
עמוד יכול להיראות באנגלית בזמן ש-title, canonical או hreflang עדיין שגויים. QA רב לשוני צריך לכלול גם metadata.
בדקו sitemap אחרי פרסום translations
כאשר מוסיפים locale חדש למוצרים או מאמרים, כדאי לוודא שהכתובות החדשות מופיעות ב-sitemap והישנות לא נעלמות בטעות.
בדקו redirects לכל locale
אם slug אנגלי משתנה, redirect צריך להישאר בתוך /en. slug עברי ישן צריך להפנות לגרסה העברית החדשה.
אסור redirect היסטורי של locale אחד לשלוח בטעות לשפה אחרת.
Tenant scope חשוב גם ב-SEO locale maps
במערכת SaaS שמנהלת חנויות רבות, route mapping של product צריך להיבנות רק מתוך translations של אותו tenant.
Slug זהה בשתי חנויות אינו בעיה כל עוד כל request נפתר תחת store context הנכון.
Slug uniqueness צריך להיות בתוך ה-scope הנכון
בדרך כלל צריך למנוע שני products מאותו tenant ובאותו locale לקבל אותו slug.
אין סיבה לדרוש ש-slug יהיה unique בין כל החנויות בפלטפורמה.
Reserved segments צריכים להיות חסומים
Slugs כמו checkout, account או namespace אחר שמשמש routing יכולים ליצור conflict ולכן כדאי לחסום אותם לפי כללי המערכת.
Normalization צריך להתאים ל-script
עברית יכולה לשמור אותיות עבריות ומקפים, בעוד אנגלית יכולה להשתמש באותיות לטיניות lowercase ומקפים.
העיקר הוא שתהליך יצירת slug יהיה server-authoritative, עקבי וצפוי.
אל תאפשרו ל-client להחליט לבד על uniqueness
שני משתמשים יכולים ליצור products במקביל. רק server/database יכולים להבטיח slug unique בצורה אמינה וליצור suffix כמו -2 כאשר נדרש.
תרגום title לא צריך להעתיק slug אוטומטית לאחר פרסום
ביצירת translation חדשה אפשר ליצור slug מה-title. לאחר שהעמוד public, שינוי title לא צריך להזיז URL אוטומטית.
Analytics צריך להשתמש ב-entity identity ולא רק URL
אם רוצים להשוות אותו product בין עברית לאנגלית, כדאי שיהיה identifier משותף מאחורי שתי הכתובות.
כך ניתן לראות performance לפי product ואז לפלח לפי locale.
האם כדאי להתחיל משתי שפות ביום הראשון
אם לקהל הבינלאומי יש חשיבות מהיום הראשון ויש יכולת לתחזק תוכן, אפשר להשיק שתי שפות יחד.
אם העסק עדיין בודק את המודל המקומי, לפעמים חכם יותר להשיק שפה אחת מלאה, לייצב מוצרים, תשלום ומשלוחים ורק אז להרחיב.
איך להחליט אם האנגלית משתלמת
- כמה traffic באנגלית מגיע או צפוי להגיע
- כמה פניות קיימות מלקוחות בינלאומיים
- האם המוצרים ניתנים למשלוח לשווקים האלה
- מה עלות התרגום והתחזוקה
- האם checkout וה-payment תומכים בלקוחות האלה
- האם קיימת יכולת שירות באנגלית
- מה conversion באנגלית לאחר ההשקה
- מה Revenue ו-Average Order Value של הקהל הזה
תהליך נכון להוספת אנגלית לחנות קיימת
- הגדירו en כ-locale נתמך
- החליטו על URL structure
- הכינו translations של navigation ו-system UI
- תרגמו קטגוריות מרכזיות
- תרגמו מוצרים מרכזיים
- הגדירו slugs אנגליים
- כתבו SEO title ו-description באנגלית
- תרגמו policy pages
- בדקו checkout ו-payment
- תרגמו emails
- הגדירו hreflang ו-canonical
- עדכנו sitemap
- בדקו RTL ו-LTR בכל המסלול
- בדקו language switcher
- בצעו test order באנגלית
- פרסמו בהדרגה
- עקבו אחרי Search Console ו-conversion
טעויות נפוצות בחנות רב לשונית
- לתרגם רק את עמוד הבית
- ליצור product נפרד לכל שפה
- להשתמש באותו slug לכל locale ללא צורך
- להחזיר language switcher לעמוד הבית במקום לעמוד המקביל
- ליצור URL לשפה שאין לה translation
- להשאיר checkout בשפת ברירת המחדל
- להתעלם מ-RTL
- לשנות currency אוטומטית עם השפה
- להשתמש באותו SEO title בשתי השפות
- לשכוח hreflang
- להגדיר canonical של כל השפות לעמוד אחד
- להשאיר policy pages untranslated
- לשלוח email confirmation בשפה הלא נכונה
- לתת AI לפרסם תרגום ללא review
- לשכוח לתרגם error states
- לערבב נתוני product עם translation data
צקליסט QA לפני שמפרסמים locale חדש
- כל navigation מתורגם
- כל העמודים המרכזיים קיימים
- Product titles ותיאורים תקינים
- Category names תקינים
- Slugs נכונים
- Direction נכון
- Technical values נשארים קריאים
- Cart מתורגם
- Checkout מתורגם
- Payment flow מתאים
- Shipping labels מתורגמים
- Policies קיימות
- Emails מתורגמים
- Canonical נכון
- hreflang reciprocal
- Sitemap כולל את ה-locale
- Language switcher מגיע לעמוד המקביל
- Share preview תקין
- Structured data מתאים
- Search עובד בשפה החדשה
- Test order עבר בהצלחה
לסיכום
חנות בעברית ובאנגלית יכולה לפתוח לעסק קהל חדש ולבנות נוכחות בינלאומית, אבל היא צריכה להרגיש כמו שתי גרסאות מלאות של אותה חנות ולא כמו אתר אחד עם שכבת תרגום חלקית.
הבסיס הוא data model שבו מוצר, מלאי ומחיר נשארים משותפים בזמן שהתוכן מתורגם לפי locale. מעליו צריך לבנות URLs מקומיים, RTL ו-LTR אמיתיים, checkout מלא, emails, SEO, canonical, hreflang ו-sitemap.
הגישה הטובה ביותר היא לא לתרגם הכל במהירות אלא לבנות workflow שאפשר לתחזק. כאשר כל product חדש, policy update ומאמר עוברים תהליך translation ו-review מסודר, החנות יכולה להתרחב לשפות נוספות בלי לאבד איכות, SEO או עקביות תפעולית.