אתר רב לשוני: איך בונים ומתחזקים אתר בעברית, בערבית, באנגלית וברוסית

רוב האתרים הרב לשוניים בישראל נראים טוב בעמוד הבית ומתפרקים בעמוד השלישי. הכפתור "العربية" מוביל לעמוד אודות מתורגם, אבל הטופס עדיין בעברית, הודעת השגיאה בעברית, האישור שנשלח בדואר בעברית, והמוקד שעונה לטלפון לא מדבר ערבית. מי שמנהל דיגיטל בגוף ציבורי, ברשות מקומית או בחברה שמפעילה שירות עבור משרד ממשלתי, צריך לדעת שתי אמיתות לפני שהוא כותב מפרט: תרגום הוא החלק הקטן של הפרויקט, ואתר בכמה שפות הוא התחייבות שוטפת ולא משימה חד פעמית. המדריך הזה עובר על כל ההחלטות, מהשאלה המשפטית ועד מבנה הכתובות, הטיפוגרפיה, הטפסים, הנגישות והתחזוקה, כך שתוכלו להגן על כל אחת מהן מול הרכש, המשפטית וההנהלה.

מתי צריך אתר רב לשוני, ומה החוק אומר

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

חוק יסוד: ישראל מדינת הלאום של העם היהודי קובע בסעיף 4 שעברית היא שפת המדינה, שלשפה הערבית מעמד מיוחד, ושהסדרת השימוש בערבית במוסדות המדינה או בפנייה אליהם תיקבע בחוק. החוק גם קובע שאין בו כדי לפגוע במעמד שניתן לערבית בפועל לפני כניסתו לתוקף. מסמך של מרכז המחקר והמידע של הכנסת מדצמבר 2018 מציין שאין חוק שמסדיר הנגשה של אתרים ממשלתיים או ציבוריים בערבית, ושמדריך הסטנדרטים של יחידת ממשל זמין משנת 2012 כולל הנחיות לתוכן בערבית באתרי משרדי הממשלה, בלי סמכות לאכוף אותן.

מאז הונחו בכנסת ה-25 הצעות חוק פרטיות בנושא, למשל הצעת חוק חובת הנגשה לשונית של אתרי אינטרנט ושירותים ממשלתיים מקוונים, התשפ"ג-2023, שמציעה לחייב גופים ציבוריים לתרגם את הפלטפורמות הדיגיטליות שלהם לערבית, לרוסית ולאמהרית. הצעת חוק היא לא חוק. נכון לאוקטובר 2026 לא מצאנו חוק כללי כזה שנכנס לתוקף, ואת המצב העדכני מאמת היועץ המשפטי.

במקביל יש תחומים שבהם הרגולטור כבר קבע דרישה. הדוגמה המתועדת היא מערכת הבריאות: לפי סקירת מרכז המחקר של הכנסת משנת 2018, חוזר מנכ"ל משרד הבריאות 7/11 מפברואר 2011 קובע שאתרי ארגוני הבריאות יהיו זמינים בערבית, ברוסית ובאנגלית, לפחות במידע על זכויות, על שירותי ליבה ועל דרכי יצירת קשר. אם אתם ספק של גוף כזה, הדרישה עוברת אליכם דרך ההסכם.

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

אילו שפות, ובאיזה עומק

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

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

שלוש רמות עומק

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

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

מבנה כתובות: תיקייה, תת-דומיין או דומיין

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

גוגל מציגה ארבע אפשרויות: דומיין ארצי נפרד, תת-דומיין, תת-תיקייה ופרמטר בכתובת, ומסמנת את הפרמטר כלא מומלץ. אתר של גוף ישראלי שמשרת כמה שפות באותה מדינה לא צריך דומיין לכל מדינה, כי השפות לא מייצגות מדינות. ברוב המקרים התשובה היא תיקייה: example.org.il/ar/, example.org.il/ru/, example.org.il/en/, והעברית בשורש או ב-/he/.

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

ומה עם שם התיקייה? השתמשו בקוד השפה הבינלאומי ולא בתרגום חופשי. /ar/ ולא /arabic/, וגם לא מילה בערבית בכתובת של התיקייה. בתוך כל שפה, הכתובות של העמודים יכולות להיות בשפה עצמה או באנגלית, וזו החלטה שכדאי לקבל פעם אחת ולתעד אותה, כי שינוי שלה בהמשך מחייב הפניות לכל העמודים.

hreflang: איך אומרים לגוגל מה מקביל למה

hreflang הוא סימון שאומר לגוגל: "העמוד הזה בעברית, והנה הכתובות של אותו עמוד בערבית, ברוסית ובאנגלית". בזכותו מי שמחפש בערבית יקבל את הגרסה הערבית בתוצאות, ולא את העברית. התיעוד של גוגל על גרסאות מקומיות של עמודים מתאר שלוש דרכים שקולות לסמן: תגיות link בראש העמוד, כותרות HTTP, או מפת האתר. גוגל כותבת שהשיטות שקולות מבחינתה, ושאין תועלת בשימוש בכמה מהן יחד. בחרו אחת.

בתגיות בראש העמוד זה נראה כך, בכל אחת מארבע הגרסאות, באותו סט בדיוק:

<link rel="alternate" hreflang="he" href="https://example.org.il/services/permit/" />
<link rel="alternate" hreflang="ar" href="https://example.org.il/ar/services/permit/" />
<link rel="alternate" hreflang="ru" href="https://example.org.il/ru/services/permit/" />
<link rel="alternate" hreflang="en" href="https://example.org.il/en/services/permit/" />
<link rel="alternate" hreflang="x-default" href="https://example.org.il/services/permit/" />

ארבעה כללים שאי אפשר לדלג עליהם

נקודה עדינה אחת: גוגל כותבת שגרסאות שפה של אותו עמוד נחשבות כפילות רק אם התוכן העיקרי לא תורגם. כלומר, עמוד שבו רק התפריט והכותרת התחתונה בערבית והגוף בעברית, הוא מבחינת גוגל העתק של העמוד העברי. זו עוד סיבה לתרגם עמודים שלמים או לא לפרסם אותם בשפה בכלל.

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

ימין לשמאל ושמאל לימין באותה מערכת

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

ההנחיות של W3C ברורות. המאמר של קבוצת הבינאום של W3C על כיווניות ממליץ לשים dir="rtl" על אלמנט ה-html של כל עמוד שכיוונו הכללי מימין לשמאל, לא לקבוע כיווניות דרך CSS, ולהשתמש במאפייני פריסה לוגיים של התחלה וסוף במקום שמאל וימין, כדי שהפריסה תתהפך מעצמה. הצהרת השפה נעשית בנפרד, במאפיין lang, כי שפה לא קובעת כיווניות ולהפך.

מה מתהפך ומה לא

הבעיה הקשה באמת היא טקסט מעורב. משפט בערבית עם שם מוצר באנגלית ומספר תיק, או שם משתמש ברוסית בתוך הודעה בעברית, יכולים להופיע בסדר הפוך אם לא מבודדים אותם. W3C ממליצה על dir="auto" בשדות קלט ובטקסט שמוכנס מבחוץ, ועל אלמנט bdi לבידוד מקטעים קצרים. בשדות טופס היא מציינת גם את המאפיין dirname, ששולח לשרת את כיוון הטקסט שהוקלד.

ואל תשכחו את כל מה שמחוץ לדפדפן: תבניות דואר, הודעות SMS, קובצי PDF שנוצרים מהמערכת, וקבלות. שם הכיווניות נשברת הכי הרבה, כי אף אחד לא בודק אותם בשפה השנייה עד שתושב שולח צילום מסך.

גופנים וטיפוגרפיה לערבית, לעברית ולרוסית

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

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

ההמלצה המעשית: לפני שמאשרים עיצוב, מבקשים מהמעצב מסך אחד בכל שפה עם תוכן אמיתי, לא טקסט דמה. כותרת אמיתית ברוסית ופסקה אמיתית בערבית יגלו בעיות שאף טקסט דמה לא יגלה.

תהליך תרגום: מקצועי, מכונה ובדיקה, מילון מונחים

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

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

מילון המונחים הוא המסמך החשוב ביותר

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

שתי החלטות נוספות שכדאי לקבל בכתב: באיזה משלב לשוני כותבים בכל שפה, למשל ערבית ספרותית לתוכן רשמי, ומה עושים עם שמות של מקומות ומוסדות שיש להם שם רשמי בשפה. שפה פשוטה חשובה בכל שפה, לא רק בעברית, והרחבנו עליה במדריך כתיבה בשפה פשוטה.

טפסים ואימות שדות בכל שפה

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

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

נגישות בכל שפה, לא רק בעברית

הדרישות של התקן הישראלי לנגישות אתרים לא נעצרות בגרסה העברית. אם העמוד קיים בערבית, הוא צריך להיות נגיש בערבית: ניגודיות, מבנה כותרות, תוויות טפסים, ניווט במקלדת וטקסט חלופי לתמונות, כולם בשפה של העמוד. הפירוט המלא של מה שהתקן דורש נמצא במדריך נגישות אתרים.

יש דרישה אחת שהיא ספציפית לאתרים רב לשוניים, והיא נשכחת כמעט תמיד: הצהרת השפה. הנחיות WCAG כוללות את קריטריון 3.1.1, שפת העמוד, ואת קריטריון 3.1.2, שפת חלקים, ברמת התאמה AA. הראשון דורש שהשפה של העמוד תהיה מוגדרת בקוד, והשני דורש שגם קטע בשפה אחרת בתוך העמוד יסומן. ההסבר של W3C פשוט: תוכנת הקראה משתמשת בכללי ההגייה של השפה שמוגדרת. עמוד בערבית שמוגדר בקוד כעברית יוקרא בקול עברי, וזה לא מובן למשתמש.

ובורר השפות עצמו: כתבו כל שפה בשמה שלה, "עברית", "العربية", "English", "Русский", ולא בשם בעברית. מי שלא קורא עברית לא ימצא את הכפתור "ערבית". והימנעו מדגלים: שפה אינה מדינה, ודגל לא אומר למשתמש באיזו שפה ייפתח העמוד.

קידום אתרים בכל שפה בנפרד

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

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

איך שומרים על השפות מסונכרנות

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

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

מה מעדכנים מיד ומה יכול לחכות

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

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

כמה זה עולה בזמן: התחזוקה שאף אחד לא מתקצב

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

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

הדרך להחזיק את זה לאורך זמן היא לכתוב את התחזוקה בהסכם מהיום הראשון: מה כלול, באיזה קצב, ותוך כמה זמן עדכון קריטי יוצא בכל השפות. אם המפרט שלכם נכתב עכשיו, המדריך אפיון אתר ומערכת עוזר לכתוב את הסעיפים האלה כך שספק יוכל לתמחר אותם.

מה כותבים במפרט לספק

זו רשימה שאפשר להעתיק כמו שהיא למפרט או לבקשת הצעות מחיר. היא לא מחליפה את הדרישות המשפטיות שהיועץ המשפטי יוסיף, אבל היא מוציאה את השיחה עם ספקים מתחום ההבטחות והופכת את ההצעות לברות השוואה.

ואם אתם בשלב של בחירת פלטפורמה, השאלה אם המערכת תומכת ברב לשוניות כמו שצריך היא שאלה מרכזית ולא סעיף שולי. השוואנו בין האפשרויות במדריך וורדפרס או פיתוח מותאם.

מה עושים עכשיו

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

אם אתם לפני פרויקט, התחילו מהשאלות בפרק הראשון מול היועץ המשפטי ומול המוקד, ורק אחר כך עברו לעיצוב ולטכנולוגיה. ואם תרצו מבט מבחוץ על האתר הקיים, האבחון הדיגיטלי החינמי שלנו בודק ביצועים, נגישות ו-SEO, ונשמח לעבור איתכם על התוצאות. את הצד של בניית האתרים והמערכות תמצאו בעמוד אתרים ודפי נחיתה.