מדוע לוקליזציה של אתר לבלארוסית שוברת את הפריסה ואת החיפוש
בלארוסית מוסיפים כ«עוד שפה אחת» — ומקבלים מקבץ תקלות שאינן נראות בנתוני בדיקה. הקירילית בבלארוסית דורשת תווים נוספים (ў, і), שאינם קיימים בתת-קבוצות לטיניות של הגופן: הדפדפן משלים fallback מערכתי, מדדי השורה משתנים, והטקסט בכפתור או בעמודת טבלה נחתך עם שלוש נקודות.
אם קידוד העמוד או מסד הנתונים לא הועבר כולו ל-UTF-8, טופס עם השדה «Імя» מחזיר סימני שאלה, והאימות בשרת דוחה קלט תקין.
כפילויות עמודים — הבעיה השנייה בשכיחותה. הגרסה המתורגמת נפתחת בכתובת נפרדת ללא תגי מטא לשוניים וללא קישורים קנוניים, ומנוע החיפוש רואה שני עמודים מתחרים במקום אחד עם שני וריאנטים לשוניים.
הפניות לפי מיקום גיאוגרפי מחמירות את המצב: מבקר עם בלארוסית בדפדפן מגיע לתרגום, ואילו רובוט החיפוש — לגרסה המקורית, והסריקה מסתיימת באינדוקס של העמוד הלא נכון.
ריבוי צורות שובר טפסים אחרת. בבלארוסית יש שלוש צורות רבים, והכלל «צורה אחת להכול» נותן «5 тавараў» במקום שבו נדרש «5 тавараў», אבל «2 тавары». מחרוזות התפורות בתבניות ובסקריפטים נשארות בשפת המקור בעת החלפת שפה — הממשק הופך למתורגם חלקית, והלקוח נודע על כך מהמשתמשים.
המחיר של כל תקלה — לא קוסמטיקה: טקסט חתוך מפחית את ההמרה של הטופס, כפילויות מטשטשות מיקומים, הפניה שגויה מוסרת לרובוט החיפוש תוכן לא נכון. מפרקים כיצד זה נסגר ברמת התצורה, ולא בעריכה ידנית של עמודים.
מה נותנת גרסה בלארוסית תקינה: מהירות, כיסוי, אמינות
גידול בחלק התנועה האורגנית מבלארוס
מנועי החיפוש משווים את שפת העמוד לשפת השאילתה, ולכן גרסה בלארוסית תקינה מתחילה להופיע בשאילתות שבהן האתר פשוט לא השתתף קודם לכן. אם שפת הממשק מוגדרת בסימון העמוד ומאושרת במפת האתר, מנוע החיפוש מגיש את הגרסה הבלארוסית בדיוק לאותם משתמשים שמחפשים בבלארוסית. חלק הביקורים מבלארוס גדל לא על חשבון פרסום, אלא על חשבון שאילתות שקודם לכן עברו למתחרים.
ירידה בנטישה וגידול בהמרה
אדם שהגיע לעמוד בשפת האם שלו מוצא מהר יותר את המדור הדרוש ופחות עוזב מיד. טפסים, כפתורים ורמזים מתורגמים פועלים באותה צורה בכל השלבים — מהסל ועד אישור ההזמנה, ולכן המבקר לא נוטש את המילוי באמצע.
בנפרד אנו בודקים נטיית מספרים ויחסות: «1 тавар», «2 тавары», «5 тавараў» — בלי זה הטקסט נראה מכוני ופוגע באמון.
היעדר כפילויות וקנסות בגינן
הגרסה הבלארוסית והרוסית מתקיימות בכתובות שונות ומקושרות בקישורים צולבים עם ציון השפה. זה מסיר את הסיבה העיקרית לכפילויות: מנוע החיפוש מבין שלפניו שני לוקאלים של אתר אחד, ולא עותקים, ואינו מוריד את המיקומים. כתובות קנוניות ותגיות שפה תקינות משמרות את המשקל המצטבר של העמודים.
מהירות טעינה וכיסוי קהל
גופנים עם תמיכה בתווים בלארוסיים אנו מחברים עם סט מצומצם של עוביים ובאופן מקומי — העמוד לא ממתין לשירותים חיצוניים ולא «קופץ» בזמן הרינדור. בסופו של דבר האתר נפתח באותה מהירות בשתי השפות, והכיסוי מתרחב לקהל שבוחר באופן עקרוני ממשק בלארוסי.
גישות ללוקליזציה: סימון ידני, קובצי תרגום, שירותים חיצוניים
הבחירה באופן אחסון המחרוזות קובעת עד כמה מהר הצוות יוכל להוסיף שפות ועד כמה צפויה תהיה התנהגות הממשק בעת הטיית מספרים. להלן שלוש אפשרויות מעשיות שביניהן באמת בוחרים בתחילת הפרויקט.
| גישה | מתי מתאימה | מגבלות |
|---|---|---|
| סימון ידני בתבניות | שפה אחת, לוח זמנים קצר, תוכן סטטי | הטקסטים מפוזרים על פני הסימון, שפה שנייה דורשת עריכות בכל קובץ, ריבוי נכתב ידנית |
| קובצי תרגום | מוצר רב-לשוני, צוות עם עורכים, מהדורות סדירות | נדרשת משמעת מפתחות, עם גדילת הפרויקט — בנייה ובדיקה לאיתור חסרים |
| שירותים חיצוניים | שפות רבות, מתרגמים מחוץ לצוות, עריכות טקסט תכופות | תלות בשירות חיצוני, השהיה בטעינה, קשה יותר לנהל גרסאות יחד עם הקוד |
סימון ידני מעניק שליטה מלאה בניסוח, אך כבר בשפה השנייה הוא הופך לחוב: כל עריכת טקסט היא חיפוש בכל התבניות, וצורות הריבוי יש לכתוב באמצעות תנאים. אפשרות זו מוצדקת רק עבור דף נחיתה עם מערך קבוע של בלוקים.
קובצי תרגום — תרחיש בסיסי עבור i18n: המחרוזות מופרדות למשאבים נפרדים לפי לוקאלים, המפתחות מנוהלים בגרסאות יחד עם הקוד, והעורך מתקן טקסט ללא גישה לסימון. הריבוי מתואר לפי כללי השפה, ולא באמצעות הסתעפויות בתבנית, ולכן צורות המספרים מתאימות באופן תקין לכל כמות.
שירותים חיצוניים מסירים מהצוות את סנכרון התרגומים ומתאימים כאשר יש שפות רבות והטקסט משתנה לעיתים קרובות. המחיר — תלות חיצונית והשהיה בטעינת המחרוזות, ולכן טקסטים קריטיים לרינדור נשמרים בדרך כלל באופן מקומי, והשירות משמש לשאר.
שלבי יישום הלוקליזציה הבלארוסית: מביקורת ועד מסירה
לוקליזציה אינה תרגום של מחרוזות בקובץ, אלא שינוי של סכימת הנתונים, התבניות והבנייה. מתחילים בביקורת: בודקים היכן הטקסט מוטבע בתבניות, היכן הוא מגיע ממסד הנתונים, היכן הוא נוצר בצד השרת, ואילו מקומות כבר תלויים בשפה.
התוצר — מפת מחרוזות עם סימון סיכון: כתוביות דינמיות, חיבור ביטויים, פורמטים של תאריכים ומספרים, שנשברים ראשונים עם החלפת השפה.
בהמשך מתכננים את סכימת המפתחות ומגדירים i18n. את המפתחות עושים היררכיים ויציבים, כך שהתרגום לא יהיה תלוי בפריסה, והריבוי והיחסות יתוארו בכללי השפה ולא בתנאים בקוד. את המחרוזות מוציאים לקטלוגים נפרדים, ואת הגופנים מחברים עם סגנונות הנדרשים ומלאי גליפים מספק.
- ביקורת לוקליזציה. מלאי מחרוזות, איתור טקסט מוטבע, הערכת היקף ונקודות סיכון.
- סכימת מפתחות. פורמט אחיד לשמות, קבוצות לפי מדורים, כללים למשתנים ולקינון.
- הגדרת i18n. חיבור הספרייה, קטלוגי תרגומים, ריבוי, פורמטים של תאריכים, מספרים ומטבעות.
- גופנים ופריסה. בחירת סגנונות עם סט תווים מלא, בדיקת מעברי שורה ומתיחת בלוקים.
- בדיקות. הרצת תרחישים בבלארוסית, בדיקת מחרוזות ארוכות, פסאודו-לוקליזציה, רגרסיה בשאר השפות.
- תיעוד. תקנון להוספת מחרוזות, מילון מונחים, הנחיות למנהל התוכן.
- מסירה. הדגמת התהליך, גישות לקטלוגי תרגומים, רשימת בדיקה לעמודים חדשים.
סדר זה מסיר את הסיבה העיקרית לתקלות — עריכות בפריסה לאחר שהתרגום כבר מוכן. המחרוזות והכללים נק�עים לפני האכלוס, ולכן השפה החדשה מתווספת בהעתקת קטלוג ולא בבנייה מחדש של תבניות. תארו את המשימה שלכם — נחזור עם הערכת היקף ותוכנית עבודה.
חפצי לוקליזציה: קובצי תרגום, סכמות מפתחות, נהלים
לוקליזציה היא לא רק מחרוזות מתורגמות, אלא גם אוסף של חפצים שלפיהם הצוות ממשיך לעבוד בלעדינו. להלן — מה בדיוק נשאר בידי הלקוח לאחר השלמת הגרסה הבלארוסית.
- קובצי תרגום — ספריות מחרוזות מקור בפורמט שהפלטפורמה שלכם קוראת (JSON, YAML או PO), עם חלוקה לפי מרחבי שמות: ממשק, הודעות דואר, שגיאות, טקסטים משפטיים. כל קובץ מנוהל בגרסאות במאגר, כך�היסטוריית העריכות והחזרה לאחור זמינות בדיוק כמו עבור קוד.
- מפת מפתחות — טבלת התאמה: מפתח, ערך בבלארוסית, הקשר שימוש, מסך או תבנית שבהם המחרוזת מוצגת. לפיה עורך ללא גישה לקוד מבין מה ואיפה לשנות, והמפתח רואה אילו מפתחות טרם הופעלו.
- נוהל עדכון — סדר הפעולות בעת הוספת מחרוזת חדשה: מי יוצר את המפתח, כיצד הוא נכנס לספרייה, אילו בדיקות עוברים התרגומים לפני פרסום. בלי זה הלוקליזציה מתפזרת כבר בגרסה השנייה.
- מדיניויות גישה — תפקידים למתרגמים, לעורכים ולמפתחים: מי רשאי לערוך טקסטים, מי רק מציע שינויים, מי מאשר. ההרשאות מופרדות כך שעריכת מחרוזות לא תפתח גישה לשאר המערכת.
- הנחיות לעורכים — כיצד לעבוד עם ריבוי וצורות יחסה בבלארוסית, אילו מונחים נחשבים מאושרים, היכן לעיין במילון המונחים. בנפרד מתעדים כללים למספרים, לתאריכים ולמטבעות.
- סכמת חיבור גופנים ופריסות — אילו עובי גופן משמשים לתווים בלארוסיים, כיצד נבדקה תקינות התצוגה במכשירים שונים ובדפדפנים שונים.
- רשימת בדיקה לקבלה — אוסף בדיקות לפני שחרור: שלמות התרגום, היעדר מחרוזות חתוכות בממשק, פעולה תקינה של מחליף השפות, שמירת בחירת המשתמש.
את החפצים הללו מוסרים במאגר שלכם ובצורת תיעוד קריא — כדי שניתן יהיה לנהל את התמיכה בכוחות עצמכם או להעביר לצוות אחר בלי לשחזר את ההקשר מאפס.
מקרה בוחן: כיצד הגרסה הבלארוסית האיצה את הטעינה והסירה כפילויות
הלקוח — יצרן ציוד תעשייתי — נכנס לשוק הבלארוסי עם אתר מוכן בשפה הרוסית: השתילו את התרגום בתבנית, הוסיפו תת-דומיין נפרד והשיקו. כעבור חודש, במנוע החיפוש היו מאונדקסות שתי גרסאות של כל עמוד עם טקסט כמעט זהה, ובמובייל עמוד הקטלוג נטען לאט noticeably יותר מהגרסה הרוסית. מנתחים מקרה בוחן של לוקליזציה לפי מדדים לפני ואחרי.
מה היה לפני
הכפילויות נוצרו מפני שהגרסה הבלארוסית הוגשה ללא מטא-נתוני שפה תקינים, וה-canonical הצביע על עצמו בשתי הגרסאות. מנוע החיפוש לא הבין איזה עמוד יש לראות כעמוד הראשי, ומשך לאינדקס את שניהם — שיעור הכפילויות המאונדקסות הגיע עד 40% מכלל הכתובות.
שיעור הנטישות בגרסה הבלארוסית היה גבוה יותר: הגופנים חוברו כמערכת קבצים נפרדת, והטקסט הספיק להבהב כבלתי נראה עד לטעינתם.
מה שינו
העברנו את הלוקליזציה למנגנון אחיד של החלפת מחרוזות עם קבצי תרגום נפרדים ו-pluralization תקין — צורות עבור פריט אחד, שניים וחמישה כבר לא נאספו ידנית בתבנית. עבור כל גרסת שפה הצבנו קישורי שפה הדדיים ו-canonical, ואת תת-הדומיין עצמו סגרנו מפני אינדוקס במקומות שבהם התוכן חפף.
גופנים עם צורות קיריליות ולטיניות אוחדו למערכת אחת עם הגבלה על התווים בשימוש — הדפדפן הפסיק למשוך קבצים מיותרים.
מה קרה בסופו של דבר
מספר הכפילויות המאונדקסות ירד מ-40% לאפס — באינדקס נשארה גרסה אחת של כל עמוד. זמן טעינת הקטלוג במובייל התקצר בכשליש בערך, ושיעור הנטישות בגרסה הבלארוסית ירד לרמה של הגרסה הרוסית. בנפרד נציין: עריכות בתרגומים מוזנות כעת לקובץ אחד ונטענות בכל העמודים, ללא עריכה ידנית של תבניות.
Яндекс ומנועי חיפוש אחרים מתחשבים באותות כאלה באופן זהה — מטא-נתוני שפה תקינים מסירים את התחרות בין הגרסאות זו בזו.
במה שונה לוקליזציה מתרגום ומתי נדרשת פלורליזציה
תרגום הוא החלפה של מחרוזות בממשק. לוקליזציה היא כשהאתר מתנהג כמו מקומי: מספרים, תאריכים, פורמטים של כתובות, סדר השם הפרטי ושם המשפחה, מפרידי ספרות, מטבע, יחידות מידה וכללי הטיה מוצבים לפי כללי השפה, ולא לפי שאריות. תרגמת כפתור — קיבלת תרגום. הגדרת i18n — קיבלת מוצר שלא נשבר בעת החלפת שפה.
ההבדל המרכזי מתגלה בנתונים דינמיים. המחרוזת "5 פריטים" בתרגום הופכת לשתי צורות, ובבלארוסית יש יותר: "1 тавар", "2 тавары", "5 тавараў". אם בקוד מוטבעת צורה אחת, בכל כמות תוצג "тавараў" — וכל דובר יבחין בכך. לכן פלורליזציה היא לא קישוט, אלא שכבה חובה מעל המילון.
כללי ההטיה בבלארוסית נשענים על שלוש קטגוריות: יחיד, מעט (2, 3, 4) ורבים (5 ומעלה, וכן 11–14). ספרות כמו 21, 22, 25 יורשות את הצורה של הספרה האחרונה, אך 11–14 תמיד הולכות לפי רבים.
זה מתואר בכללי ICU-פלורליזציה, והמנוע עצמו בוחר את הצורה הנדרשת לפי המספר — המתכנת לא צריך לכתוב תנאים ידנית.
סיפור נפרד — יחסות. "1 тавар у кошыку", "2 тавары ў кошыку", "5 тавараў у кошыку" — מילת היחס והסיומת משתנות יחד עם המספר. אם מחרוזות נבנות בשרשור, סדר המילים והיחסות יתפרקו בשינוי הראשון של הביטוי. לכן לוקליזציה דורשת תבניות שלמות עם הצבה, ולא הדבקה של חלקים.
לוקליזציה נדרשת כאשר הקהל קורא את הממשק בבלארוסית ומצפה לניסוחים טבעיים: חנות מקוונת עם סל קניות, אזור אישי, טופס הזמנה, התראות. אם האתר הוא רק חלון ראווה של עמודים סטטיים, תרגום יספיק. ברגע שמופיעים מספרים, תאריכים וישויות מוטות — בלי פלורליזציה וכללי השפה אי אפשר להסתדר.
ספקות טכניים נפוצים בנוגע ללוקליזציה לבלארוסית
לוקליזציה לבלארוסית לעתים רחוקות נעשית "מאפס" — לרוב משתילים אותה באתר פעיל, שבו כבר קיימים ניתוב, תגי מטא ותוצאות חיפוש מצטברות. לכן הספקות המרכזיים של הלקוח נוגעים לא לתרגום עצמו, אלא לאופן שבו הגרסה הלשונית החדשה תסתדר עם התשתית הקיימת והאם התעבורה תיפגע. אנו מנתחים את שלוש השאלות הטכניות הנפוצות ביותר.
יש לנו אתר כבר פרוס — האם נצטרך לבנות הכול מחדש?
לא. אנו מוסיפים שכבת שפה מעל הקיים: את הטקסטים מוציאים לקבצי תרגום נפרדים, הנתיבים מקבלים קידומת שפה, והתבניות נשארות משותפות. הכתובות הישנות ממשיכות לעבוד דרך הפניות מחדש, ולכן עמודים שכבר אינדקסו לא מאבדים מיקום. אין צורך לכתוב מחדש את הפרונטאנד כולו — משתנה רק שכבת הצגת התוכן.
כיצד לתחזק תרגומים כאשר התוכן משתנה מדי שבוע?
המחרוזות נשמרות בקבצים מובנים, ולא "תקועות" בתוך הסימון — את התיקון מבצע עורך ללא מפתח. עבור טקסטים עם הצבות אנו מגדירים כללי הטיה: בלארוסית נדרשות שלוש צורות רבים, וזה מתואר בקונפיגורציית הפלורליזציה, ולא מקודד קשיח בתבניות. בעת הוספת עמוד חדש, מפתחות שלא תורגמו מודגשים אוטומטית, כך ש"חורים" לא מגיעים לפרודקשן.
מה עם SEO — האם לא נאבד מיקומים בחיפוש?
כל גרסה לשונית מקבלת כתובת משלה ותגי מטא תקינים, והקשר בין הגרסאות מתואר דרך סימון alternate — מנוע החיפוש מבין שמדובר באתר אחד בשתי שפות, ולא בכפילות.
בנפרד אנו בודקים קידוד ופונטים: תווים בלארוסיים צריכים להיות מוצגים באופן זהה בכל המכשירים, ללא "ריבועים" והחלפת גליפים. לאחר ההשקה אנו עוקבים אחר האינדוקס של שתי הגרסאות ובמידת הצורך מתקנים את מפת האתר.
אם המקרה שלכם לא נכלל בשלושת אלה — תארו את המשימה, ונחזור עם הערכה ותוכנית עבודה.
נדון במשימה שלכם של לוקליזציה של האתר לבלארוסית
כדי שהערכה של לוקליזציה לבלארוסית תהיה מדויקת ולא "בעין", אנחנו צריכים גישה לקבצי המקור או לעותק עבודה של הפרויקט.
לאחר מכן אנחנו בוחנים כיצד בנויה פלטת הטקסט: מחרוזות סטטיות בתבניות, מחרוזות ממסד הנתונים, טקסטים בסקריפטים ובמכתבים — לכל מקור יש דרך חיבור משלו של מילונים. מכך תלוי גם היקף העבודה, וגם היכן רבים/יחיד ויחסות ידרשו כללים ידניים והיכן יסתפקו בתצורה סטנדרטית.
חלק נפרד של ההערכה — הפריסה והגופנים. האותיות הבלארוסיות "ў" ו-"і" שוברות פריסות המחושבות לקירילית ללא סימנים אלה: שורות נעשות ארוכות יותר, כפתורים נשברים, כותרות נחתכות.
אנחנו בודקים מראש אם הגופנים המחוברים תומכים בגליפים הנדרשים, ומכניסים לתוכנית החלפת גופן או הגדרת סגנונות חלופיים.
לאחר הניתוח אתם מקבלים תוכנית עבודה עם שלבים, סדר העלאה ונקודות בדיקה בסביבות ביניים. לתוכנית נכללת גם תמיכה לאחר ההשקה: המילונים מתווספים בהתאם לעריכות התוכן, עמודים חדשים מתחברים לסכימה שכבר הוגדרה, ולא נכתבים מחדש מאפס.
מה ייכלל בעבודה:
- ספירת מלאי של כל מקורות הטקסט והערכת היקף התרגום;
- הגדרת מילונים ומחליף שפות ללא אובדן כתובות העמודים הנוכחיות;
- כללי רבים/יחיד ויחסות עבור בלארוסית;
- בדיקת גופנים ותיקון פריסה להתארכות שורות;
- לוקליזציה של מכתבי שירות, התראות והודעות מערכת;
- סביבת בדיקה עם שתי השפות וצ'ק-ליסט קבלה;
- נוהל תמיכה וסדר הוספת מחרוזות חדשות.
תארו את המשימה — מה הפרויקט שלכם, באיזה שלב הלוקליזציה ומה כבר נעשה בתרגום. נחזור עם הערכת לוחות זמנים ותוכנית עבודה מפורטת לפי שלבים.
