רב-לשוניות ב-Drupal: היכן נשברת מבנה האתר
רב-לשוניות ב-Drupal נשברת לא בשלב הפעלת השפות, אלא מאוחר יותר — כאשר התוכן מתחיל לחיות חיים משל עצמו. התמונה האופיינית: החומר תורגם, אך הגרסה הלשונית שלו קיבלה כתובת נפרדת במקום להיות מקושרת לצומת המקורי.
מנוע החיפוש רואה שני מסמכים עצמאיים בעלי משמעות זהה, ושתי העמודים נחלשים בתוצאות החיפוש — כפילויות תוכן מדללות את המשקל בין הגרסאות.
המקור השני לבעיות — אי-סנכרון התרגומים. חלק מהשדות תורגמו, חלק נותרו בשפת המקור, ומחרוזות הממשק נשאבות ממערכת נפרדת וחיות לפי לוח זמנים משלהן. בסופו של דבר המשתמש רואה תערובת של שפות באותו עמוד, והעורך אינו מבין איזו גרסה הוא מתקן והאם השמירה תדרוס תרגום של מישהו אחר.
השכבה השלישית — שגיאות hreflang. אם בסימון מצוינות כתובות שאינן קיימות, קודי אזורים מבולבלים או שחסר קישור חוזר, מנוע החיפוש פשוט מתעלם מהרמזים. אז הגרסאות הלשוניות מתחרות ביניהן, והקהל הנכון מגיע לעמוד הלא נכון. עבור התמיכה הדבר מתבטא בכך שכל תיקון דורש בדיקה ידנית של כתובות וקשרים בין הגרסאות.
בנפרד יש להתייחס למבנה הגרסאות הלשוניות: הבחירה בין תרגום צמתים, חומרים נפרדים לכל שפה וסכמת דומיינים קובעת את כל ההמשך — מעלות התיקונים ועד ההתנהגות בחיפוש. מנתחים כיצד לבנות רב-לשוניות ב-Drupal ללא כפילויות, עם hreflang תקין ותמיכה צפויה.
מה מספקת ארכיטקטורת שפה תקינה
ארכיטקטורת שפה תקינה מתחילה בכך שהתוכן קיים בעותק אחד, והגרסאות הלשוניות הן הייצוגים שלו. ב-Drupal על כך אחראיות ישויות עם תרגום שדות מופעל וקישור דרך langcode: עריכת העמוד המקורי אינה מחייבת לחזור עליה בכל שפה, והתרגומים נמשכים למבנה המעודכן. אם הארכיטקטורה בנויה נכון, פרסום גרסה לשונית חדשה אורך דקות ולא שעות של העתקה ידנית.
האפקט השני — אינדוקס צפוי. כאשר לכל גרסה יש כתובת משלה, hreflang תקין ותג קנוני, מנועי החיפוש רואים עמודים לשוניים שונים ולא כפילויות של אותו טקסט. שיעור העמודים ללא כפילויות עולה, ואיתו גם הנראות בתוצאות המקומיות: מבקר מהאזור המתאים מגיע לגרסה שלו ולא לדף אנגלי ריק מתוכן.
האפקט השלישי — עמידות בפני עריכות. כאשר משתנה מבנה הקטלוג או תבנית הכרטיס, השינויים מיושמים בכל השפות בבת אחת, כי מקור התוכן אחד. אין צורך להשוות עשרות עמודים ידנית ולתפוס אי-התאמות שבדרך כלל צפות רק לאחר השחרור.
מהירות פרסום התרגומים, שיעור העמודים ללא כפילויות וצפיות העריכות — אלו אינן משאלות מופשטות, אלא מדדים מדידים שנקבעים בארכיטקטורה כבר בהתחלה. בדיוק משום כך אנו מנתחים את מודל השפה לפני תחילת הבנייה, ולא מתקנים אותו לאחר ההשקה.
דרכים לארגון תרגומים: השוואת גישות
ב-Drupal תרגום תוכן ותרגום ממשק הם שני מנגנונים בלתי תלויים, ובלבול ביניהם יקר: מחרוזות ממשק נמצאות בקבצי תרגום ומתעדכנות בנפרד מהישויות, והישויות עצמן (תכנים, טקסונומיה, תפריטים, שדות) מקבלות תרגומים ברמת מסד הנתונים.
אם בוחרים שיטה לא נכונה למשימה, מקבלים либо כפילויות של תכנים, либо תוויות לא מתורגמות בטפסים ובהודעות.
השכבה השנייה של הבחירה היא כיצד השפות נראות בכתובות. קידומות שפה (/en/, /de/) פשוטות יותר להגדרה ואינן דורשות אישורים נפרדים, דומיינים לשוניים נותנים כתובות נקיות ומתאימים יותר כאשר לשפה יש קהל משלה ותוצאות חיפוש משלה. שינוי ההחלטה הזו לאחר ההשקה הוא מעבר של כל הכתובות, ולכן קובעים אותו לפני אכלוס התוכן.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| תרגום ישויות (מובנה) | תוכן וטקסונומיה, שבהם התרגומים מקושרים זה לזה | ככל שמספר השפות והשדות גדל — גדל נפח מסד הנתונים; יש לתחזק קשרים בין התרגומים |
| תרגום ממשק באמצעות קבצים | מחרוזות של תבניות, טפסים, הודעות, תוויות מערכת | אינו מכסה תוכן; עדכון מודול עלול לדרוס מחרוזת |
| תוכן אחיד עם שדות לשוניים | סוגים פשוטים, שבהם תרגום הוא שדה אחד או שניים | אינו מתרחב לנפחים גדולים, שובר חיפוש ומסננים |
| דומיינים לשוניים | תוצאות חיפוש ומותג נפרדים לכל שפה | דורש אישורים, הגדרה נפרדת של הפניות וכתובות קנוניות |
| קידומות שפה | התחלה מהירה, דומיין אחד | הפרדה חלשה יותר בין שפות בחיפוש, מורכב יותר עם גרסאות אזוריות |
בפועל כמעט תמיד משלבים: ישויות מתרגמים במנגנון המובנה, ממשק — בקבצים, ואת שיטת הכתובות בוחרים לפי מספר השפות ודרישות החיפוש.
המגבלה שעולה מאוחר מכול היא תוכן משותף כמו מחירים או מאפיינים: או שמכפילים אותו לפי שפות, או שמוציאים אותו לישות נפרדת עם קשרים, וגם את ההחלטה הזו עדיף לקבל לפני אכלוס התוכן.
שלבי הגדרת אתר רב-לשוני
רב-לשוניות ב-Drupal אינה התקנת מודול, אלא תכנון מבנה: ממנו תלוי כיצד מנועי החיפוש יראו גרסאות של דפים וכיצד עורכים יעבדו איתם. סדר העבודות נבנה כך שכפילויות כתובות ואי-סנכרון תרגומים לא ייווצרו בשלב הזנת התוכן, ולא יטופלו בדיעבד באמצעות הפניות.
- ביקורת מבנה לשוני. בוחנים חומרים קיימים, טקסונומיות, תפריטים ותבניות: מה מתורגם במלואו, מה נשאר משותף, היכן התוכן כבר משוכפל. קובעים שפות יעד ווריאציות אזוריות, כדי לא ליצור יישויות מיותרות.
- סכימת שפות וכללי תרגום. מגדירים אילו סוגי תוכן ושדות מתורגמים, מה עובר בירושה ללא תרגום, כיצד מתבצעת הצמדה לשונית של מונחים. בשלב זה קובעים מצב תרגום — ידני, עם מקור משותף או משולב.
- הגדרת תרגומים. מפעילים שפות נדרשות, מגדירים סוגי תוכן, שדות וטקסונומיות, מחברים מודולים לתרגום ממשק ותוכן. בנפרד בודקים שהעורך רואה רק לשוניות שפה רלוונטיות ואינו יוצר עותקים מיותרים.
- בדיקת כתובות ותגיות. מגדירים תבניות נתיבים עם קידומת שפה, מוציאים כפילויות, בודקים כתובות קנוניות ותקינות תגיות שפה. מריצים מפת אתר ומוודאים שכל גרסה מפנה לחלופות.
- בדיקת תרחישים. בודקים החלפת שפות, התנהגות בהיעדר תרגום, פעולת חיפוש וטפסים, הפניות מכתובות ישנות. בנפרד בוחנים כיצד האתר מתנהג בעת הוספת שפה חדשה.
- מסירת תיעוד. מוסרים תקנון: אילו שדות לתרגם, כיצד להוסיף שפה, כיצד לבדוק כתובות לפני פרסום. בנוסף מפת המבנה הנוכחי ורשימת מגבלות ידועות.
סדר עבודה זה מסיר את הכאב העיקרי של פרויקטים רב-לשוניים — פער בין גרסאות וכפילויות בתוצאות החיפוש. עורכים עובדים לפי כללים ברורים, ומנועי החיפוש מקבלים תמונה חד-משמעית של גרסאות השפה.
ארטיפקטים ותיעוד לאחר ההטמעה
לאחר הטמעת הרב-לשוניות ב-Drupal, הלקוח מקבל לא "אוסף הגדרות", אלא ערכה שלמה שלפיה הצוות יוכל לעבוד בלעדינו: קונפיגורציות, סכימות כתובות, נהלים וכללי הפניות. להלן מה בדיוק אנחנו מוסרים לידיים ולשם מה כל ארטיפקט נחוץ בעבודה היומיומית.
- ייצוא קונפיגורציית השפות — אילו שפות מופעלות, איזו מהן בסיסית, כיצד מוגדרים הקידומות וזיהוי השפה לפי כתובת. מאפשר לפרוס את אותה קונפיגורציה בסביבת בדיקה ובפרודקשן ללא הרכבה ידנית.
- סכימת כתובות ותרגומים — טבלת "שפה → תבנית כתובת → מקור תרגום", כדי שתוכן חדש יקבל כתובת תקינה ולא ייווצר כפילות.
- כללי הפניות וכתובות קנוניות — מפת הפניות מכתובות ישנות לחדשות והגדרות המונעות איחוד גרסאות שפה במנוע החיפוש.
- נוהל פרסום — סדר הפעולות של העורך: איזו שפה ממולאת ראשונה, כיצד מקשרים תרגומים, מה נבדק לפני הפרסום.
- תיעוד תרגומים — מילון מונחים וכללי ניסוח, כדי שעורכים שונים לא ייפלו בסתירות בניסוחים.
- הוראות hreflang — אילו צירופי שפות מוגדרים אוטומטית ואילו מוגדרים ידנית ומדוע.
- צ'ק-ליסט קבלה — סט בדיקות: תקינות כתובות, היעדר כפילויות, פעילות מחליף השפה, אינדוקס של כל גרסה.
- יומן שינויים בקונפיגורציה — מה ומתי השתנה בהגדרות השפות, כדי שבמקרה של תקלה ניתן לחזור במהירות למצב תקין.
כל ארטיפקט מכסה סיכון מוגדר: כפילויות במנוע החיפוש, תרגומים שאבדו, כתובות שבורות לאחר שחרור. תארו את המשימה — נחזור עם הערכה ותוכנית למסירת התיעוד.
מקרה בוחן: ביטול כפילויות וחוסר סנכרון בתרגומים
אתר ארגוני ב-Drupal עם ארבע גרסאות שפה: עורכי התוכן התלוננו שתרגומים "הולכים לאיבוד", ותוצאות החיפוש הציגו כתובות שונות לאותו עמוד.
הביקורת אישרה את החשש הגרוע ביותר: 38% מהכתובות שאונדקסו היו כפילויות — חומר בעברית נפתח גם בנתיב הראשי וגם בנתיב שירותי עם קידומת שפה, ותגי שפה בחלק מהעמודים הפנו לעצמם במקום לחלופות.
מה היה לפני
התרגומים התקיימו כחומרים נפרדים, המקושרים ביניהם ידנית. העורך פרסם את הגרסה בעברית, ואז העתיק אותה ותרגם — הקישורים בין ההעתקים ניתקו בכל עדכון של המקור. הזמן הממוצע מפרסום המקור ועד להופעת התרגום — 6 ימי עבודה, מכיוון שחצי מהשלבים נעשו ידנית ונבדקו בעין.
מה שינו
העבירו את מודל התוכן למנגנון התרגומים המובנה: חומר אחד עם גרסאות שפה במקום אוסף העתקים. את הקישורים בין הגרסאות מנהלת כעת המערכת, ולא העורך — בעת עדכון החומר המקורי התרגום מסומן כמיושן ונכנס לתור לעדכון.
תגי השפה נאספים אוטומטית מקבוצת התרגומים המפורסמים, הכתובות השירותיות חסומות לאינדוקס, והכתובת הקנונית מצביעה על גרסת השפה ולא על תבנית כללית.
מה נהיה
שיעור העמודים הכפולים באינדקס ירד מ-38% ל-2% — נותרו רק חריגים מודעים לחומרים דומים. זמן פרסום התרגום הצטמצם מ-6 ימים לכמה שעות: העורך עובד עם טופס אחד, ולא עם העתקים. תגי השפה תקינים ב-100% מהעמודים שנבדקו, והקישורים ההדדיים בין הגרסאות כבר אינם הולכים לאיבוד בעת עדכונים.
אפקט נפרד — צפיות. בעבר איש לא יכול היה לומר כמה חומרים באמת תורגמו: ההעתקים התפצלו, וחלקם התקיימו ללא קשר למקור. כעת הסיכום לפי שפות נבנה מתוך המערכת עצמה, ופערים בתרגומים נראים מיד, ולא צפים בתלונות מצוותים אזוריים.
במה שונה תרגום של יישויות מתרגום של ממשק?
ב-Drupal מדובר בשני רבדים בלתי תלויים של לוקליזציה, ואסור לבלבל ביניהם. תרגום ממשק הוא המחרוזות שהמערכת עצמה והמודולים מייצרים: תוויות של שדות, כפתורים, הודעות דואר, טקסטים של שגיאות. הם נשמרים בנפרד מהתוכן ונטענים בשלב הצגת העמוד.
תרגום יישויות הוא כבר נתונים: תכנים, טקסונומיה, תפריטים, בלוקים, שדות מותאמים אישית. כאן לכל גרסה לשונית יש סט ערכים משלה, תאריך פרסום משלה וסטטוס משלה.
ההבדל בגישות משפיע ישירות על המבנה. מחרוזות ממשק אינן יוצרות צמתים חדשים — רשומה אחת משרתת את כל השפות, ולכן הוספת שפה אינה מנפחת את מסד הנתונים.
יישויות לעומת זאת, כאשר התרגום מופעל, מקבלות רוויזיה נפרדת לכל שפה: לגרסה האנגלית של המאמר יש URL-כינוי משלה, מטא-תגים משלה, קבצים משויכים משלה.
אם מתבלבלים בין הרבדים — למשל, פותחים "גרסה אנגלית" כחומר חדש במקום כתרגום — תקבלו כפילויות במפת האתר, קישורים שהתפצלו וחוסר סנכרון בעת עדכון.
בפועל משמעות הדבר היא טקטיקת תחזוקה שונה. מחרוזות ממשק מתעדכנות באופן מרוכז: מתקנים אחת — משתנה בכל מקום שבו היא מוצגת. תרגומי תוכן מתוקנים בנפרד, וכאן חשוב שהעורך יראה איזו גרסה התיישנה לאחר תיקון המקור.
אנחנו בשלב ההתחלה קובעים מה בדיוק מתורגם כיישות ומה כמחרוזת — זה מסיר מחצית מהשאלות העתידיות "למה בעמוד אחד יש טקסט ישן".
בנפרד יש להתייחס לסנכרון שדות. ערכים משותפים לכל השפות — למשל מק"ט או תמונה — מוציאים לשדות שאינם מתורגמים, כדי לא לשכפל אותם בכל גרסה. אז המבנה נשאר שטוח, והעורך אינו מבזבז זמן על הזנה חוזרת.
ספקות טכניים נפוצים בנוגע לריבוי שפות
ריבוי שפות מיושם כמעט תמיד על אתר פעיל ולא על אתר ריק: התוכן כבר מאונדקס, קישורים התפשטו למקורות חיצוניים, ונתוני אנליטיקה נצברו. לכן השאלה הראשונה היא לא "איך להפעיל שפה שנייה", אלא "איך לא לאבד את מה שכבר מדורג".
מה עושים אם האתר כבר פרוס ומביא תנועה?
מוסיפים שפות מעל המבנה הקיים, בלי לגעת בכתובות של השפה הבסיסית. השפה הבסיסית נשארת בנתיבים הקודמים, והחדשות מקבלות קידומת — כך קישורים חיצוניים ואותות שנצברו נשמרים.
לאחר מכן סוגרים את החלק הטכני: מגדירים קישור בין תרגומים של חומרים, מפעילים זיהוי שפת דפדפן עם אפשרות מעבר ידני, ובודקים שהמתג מוביל לאותו חומר ולא לדף הבית. בנפרד עוקבים אחר מפת האתר: עליה להכיל את כל הגרסאות הלשוניות עם תגיות תקינות.
איך להימנע מכפילויות ולא לאבד מיקומים?
כפילות נוצרת כאשר גרסאות לשוניות מחזירות תוכן זהה, או כאשר קיים תרגום אך הוא אינו מקושר למקור. זה מטופל באמצעות קישור בין תרגומים ברמת החומרים ותגיות שפה תקינות: כל גרסה מפנה לעצמה ולכל האחרות, כולל הבסיסית.
אם התרגום עדיין לא מוכן, הדף לא צריך להיפתח עם תוכן ריק — עדיף להחזיר את הגרסה הבסיסית עם ציון השפה, מאשר ליצור כתובות ריקות שמנוע החיפוש יראה ככפילויות.
איך בודקים תגיות שפה והעברת תרגומים?
בדיקת תגיות שפה היא процедура קבועה ולא הגדרה חד-פעמית: מוודאים שכל גרסה מפנה למערך מלא של חלופות, שהתגיות אינן מובילות לכתובות לא קיימות, ושהשפה הבסיסית מצוינת כראוי.
בהעברת תרגומים מעבירים לא רק את הטקסטים אלא גם את הקישורים בין הגרסאות — אחרת לאחר המעבר החומרים מתפרקים לדפים עצמאיים, ותגיות השפה יש להרכיב מחדש. מריצים בדיקה לפני ואחרי ההעברה, ומשווים את מספר הזוגות המקושרים.
אם הספק לא נסגר — תארו את המבנה שלכם ואת מצב השפות הנוכחי, ונחזור עם הערכה ותוכנית עבודה.
נדון במשימת הרב-לשוניות ב-Drupal
כדי לחזור עם הערכה ותוכנית, ולא עם מילים כלליות, עלינו להבין את מצב הפרויקט הנוכחי. שלחו גישה למאגר ולקונפיגורציה (ייצוא קונפיגורציה, קבצי תרגום, הגדרות זיהוי שפה) — לפיהם נבצע ביקורת רב-לשוניות ונראה היכן התוכן משוכפל, כיצד בנויים קשרי התרגום ומה מצב ה-hreflang.
- כתובות האתר ורשימת השפות: אילו לוקאלים פעילים, האם יש דומיינים לשוניים או תת-תיקיות, וכיצד מזוהה שפת המבקר.
- כיצד בנוי התוכן כעת: תרגומים דרך קשרי ישויות, חומרים נפרדים לכל שפה או תבנית משותפת עם שדות תרגום.
- מקורות התרגום: הזנה ידנית, קבצי ייבוא, שירות חיצוני — ומי אחראי על הסנכרון.
- בעיות נוכחיות: כפילויות עמודים בתוצאות החיפוש, שפה "קופצת", מחליפים שבורים, אי-התאמות בתגי מטא.
- דרישות SEO: האם נדרשות כתובות נפרדות לכל שפה, וכיצד צריכים להיראות canonical ו-hreflang.
- מגבלות: לוחות זמנים, מדורים מושפעים, אינטגרציות עם מערכות חיצוניות וקטלוגים.
לאחר הביקורת נחזור עם הערכה ותוכנית: נפרק את העבודות לשלבים, נציין לוחות זמנים ליישום וסיכוני מיגרציה. אם חלק מהתוכן כבר מתורגם, נראה כיצד להעביר אותו ללא אובדן קשרים ומיקומים. תארו את המשימה — נדון בפרטים ונציע פתרון המותאם לפרויקט שלכם.
