מדוע לוקליזציה של משחק מובייל נשברת ברגע ההשקה
לוקליזציה של משחק מובייל כמעט אף פעם לא נשברת בשלב התרגום — היא נשברת בשלב הבנייה, כשהמחרוזות כבר התפזרו על פני המסכים, והבודק רואה לא את הפריסה המקורית אלא גרסה מעוותת שלה.
טקסט בגרמנית ארוך מאנגלית בשליש, ערבית הופכת את הפריסה מימין לשמאל, וסינית מסתדרת בלי רווחים — ושם, במקום שבו בפריסה עמד כפתור מסודר, בגרסת ההשקה מופיע «המשך…» חתוך.
זה לא עניין קוסמטי: כל כפתור כזה הוא שלב אבוד בתהליך ההיכרות, וההיכרות היא שקובעת אם השחקן יישאר או ימחק את האפליקציה כבר במסך הראשון.
בעיות לוקליזציה במשחקים לעיתים רחוקות מוגבלות לאורך המחרוזות. תבניות של תאריכים, מספרים ומטבעות נבנות מתבניות מערכת, ואם המחרוזת «12/03» בשוק אחד נקראת כדצמבר ובשוק אחר כמרץ — השחקן רואה תאריך שגוי של אירוע.
צורות ריבוי של שמות עצם בשפות סלאביות דורשות לא שני וריאנטים אלא שלושה, ולוגיקה מקודדת קשיח של «אחד/רבים» מפיקה «5 קריסטלים» במקום שבו השפה מצפה לצורה השלישית. שגיאות תרגום של הממשק כאן משניות — העיקריות הן ארכיטקטורת המחרוזות, שלא הניחה מראש גמישות.
קטגוריה נפרדת של תקלות — מחרוזות אבודות. הטקסטים חיים בטבלאות, חלקם נמשכים מקונפיגים בשרת, חלקם מקודדים קשיח בקוד, וחלקם מגיעים מחנות האפליקציות.
בעת השקת המשחק בשוק חדש, המקורות האלה מסונכרנים ידנית, וכל אי-סנכרון מפיק לוחיות ריקות, ממלאי מקום באנגלית באמצע מסך מלוקלז, או קריסה על מפתח חסר. השחקן לא מדווח על כך לתמיכה — הוא просто עוזב.
המחיר של הטעות נמדד לא בתיקונים אלא בהמרה: מסך ראשון חתוך, מחיר לא קריא בחנות בתוך המשחק או תבנית תאריך שבורה בפרס היומי מורידים את שיעור המגיעים לתשלום הראשון באופן ניכר יותר מכל עיכוב בהשקה. מפרקים כיצד זה נסגר ברמת התהליך, ולא בתיקונים הירואיים לפני הפרסום.
מה מספקת לוקליזציה טכנית של משחק מובייל
לוקליזציה טכנית של אפליקציות מתחילה לא בתרגום, אלא באופן שבו המחרוזות נכנסות לבנייה. אם הטקסטים נמצאים ישירות בקוד או בטבלאות מפוזרות, כל שפה הופכת לענף נפרד שצריך לאחד ידנית עם הענף הראשי.
צינור לוקליזציה בנוי נכון מסיר את העבודה הידנית הזו: המחרוזות מופרדות לקבצי משאבים, המפתחות יציבים, והתרגומים נטענים בשלב הבנייה.
הפרדת מחרוזות וניהול מפתחות
כל עוד הטקסט מוטבע בממשק, כל תיקון של העתק דורש מעורבות של מפתח. ניהול מחרוזות תרגום דרך קטלוג אחיד עם מפתחות בפורמט screen.button.confirm מפריד את הטקסט מהלוגיקה: תיקון העתק לא נוגע בקוד, ומחרוזת חדשה נכנסת לכל השפות בבת אחת. תופעת לוואי — הבנייה מפסיקה להישבר בגלל מרכאה לא סגורה בתרגום.
בדיקה אוטומטית של שלמות
סקריפט משווה את מערך המפתחות בין השפות ומפיל את הבנייה אם חסרה מחרוזת בשפה או נשאר placeholder לא מתורגם. זה תופס קטעים כמו {count} items בממשק בערבית לפני השחרור, ולא בביקורות. שיעור הפגמים האלה שמגיעים למשתמש יורד לאפס.
פסאודו-לוקליזציה ובדיקת פריסה
הרצת הממשק בשפת פסאודו "מוארכת" מראה היכן הכפתור לא מכיל טקסט בגרמנית או היכן המחרוזת גולשת מעבר לקצה. את הפריסה מתקנים פעם אחת בשלב הפיתוח, ולא אחרי כל שפה חדשה.
הקשר למתרגם
צילום מסך של המסך והערה למפתח מסירים ניחושים: המתרגם רואה ש-Post הוא כפתור פרסום, ולא דואר. החזרות לתיקון לפי משמעות מצטמצמות פי כמה.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| בנייה ידנית | 1-2 שפות, תוחלת חיים קצרה של המוצר | כל שפה — עבודה ידנית, הסיכון לאי-סנכרון גדל |
| צינור חצי-אוטומטי | 3-10 שפות, צוות פיתוח פנימי | דורש תמיכה בסקריפטים ומשמעת במפתחות |
| פלטפורמה חיצונית לניהול מחרוזות | שפות רבות, שחרורים תכופים, מתרגמים חיצוניים | תלות בשירות, נדרשת הגדרת סנכרון |
אנחנו בונים צינור כזה על בסיס תקני תעשייה להחלפת תרגומים — XLIFF נשאר פורמט ניטרלי שמבינות גם פלטפורמות וגם צוותי תרגום.
שלבי הטמעת לוקליזציה במחזור פיתוח המשחק
לוקליזציה לא מתחילה בתרגום — היא מתחילה במיפוי של מה שכבר קיים בפרויקט. מחרוזות לעיתים קרובות מפוזרות בין הקוד, סימון המסכים, תגובות השרת ותיאורי החנות, חלקן מוטבעות בגרפיקה, חלקן נבנות דינמית משברים.
עד שתמונה זו לא נאספת, כל תרגום נתקל בטקסט חתוך, כפתורים "שזזו" ומחרוזות שאיש לא מצליח למצוא בקוד המקור. להלן — כיצד אנו בונים את הטמעת הלוקליזציה כך שהיא תהפוך לחלק מהבנייה, ולא למבצע נפרד לפני השחרור.
- ביקורת מחרוזות ומשאבים. עוברים על הקוד, הסימון ותגובות השרת, אוספים את כל משאבי הטקסט לקטלוג אחיד, מסמנים מחרוזות "מתות" וכפולות. בפלט — מפה: היכן נמצאת כל מחרוזת ומי הבעלים שלה.
- תכנון סכמת הלוקליזציה. מגדירים מפתחות, פורמט קבצי החלפה, כללי ריבוי ונטיות, חלוקה לפי שפות ואזורים. קובעים מה מתורגם אוטומטית ומה דורש מעורבות של עורך.
- הגדרת הצינור. מחברים מערכת ניהול תרגומים למאגר: מחרוזות חדשות ומשתנות יוצאות לתרגום, מוכנות חוזרות לפרויקט בענף נפרד. הבנייה עצמה קולטת את קבצי השפה המעודכנים.
- בדיקה על בניות אמיתיות. מריצים את האפליקציה בכל שפה: אורך מחרוזות בכפתורים ובתפריטים, שבירת שורות, גופנים, פורמטים של תאריכים ומספרים, סדר מילים. תופסים הצפות לפני השחרור, ולא בביקורות.
- בדיקות אוטומטיות בבנייה. מוסיפים בקרה: מפתחות לא מתורגמים, מחרוזות שנשכחו, פערים בין שפות. הבנייה נופלת אם שפה מפגרת אחרי הגרסה הראשית.
- העברה לצוות. מנסחים תקנון: כיצד להוסיף מחרוזת, כיצד לבקש תיקון, מי אחראי על הגהה. הצוות עובד עם הלוקליזציה לפי אותם כללים כמו עם שאר הקוד.
- תמיכה לאחר השחרור. שפות חדשות ותיקוני טקסט נכנסים לאותו צינור — בלי לבנות מחדש את התהליך מאפס.
רצף כזה מסיר העברה ידנית של מחרוזות ושומר על כל השפות מסונכרנות: הוספת שפה חדשה מצטמצמת לחיבור סט קבצים נוסף, ולא לפרויקט נפרד. תארו את המשימה שלכם — נחזור עם הערכה ותוכנית הטמעה בהתאם לסטאק ולמחזור השחרור שלכם.
במה שונה לוקליזציה של משחק מובייל מתרגום רגיל?
תרגום עובד עם טקסט כזרם של תווים: לקחת מחרוזת, להחליף באחרת, להחזיר לקובץ. לוקליזציה של משחק מובייל עובדת עם טקסט כחלק מלוגיקה מבוצעת — המחרוזת חיה בתוך המשאבים, מוזרקת לתבניות, מוטה לפי מספרים ויחסות ומרונדרת בגופן מסוים על מסך מסוים.
לכן לוקליזציה מול תרגום — זה לא "תרגמנו באיכות גבוהה יותר", אלא סוג אחר של משימה: המתרגם מוסר טקסט, והלוקליזטור אחראי לכך שהמשחק בלוקל הזה לא יישבר.
לוקליזציה של ממשק המשחק מתחילה במיפוי מלאי המחרוזות. אנו מפרקים את המשאבים לפי סוגים: כתוביות סטטיות לכפתורים ולתפריטים, שורות דיבור עם השמת משתנים, טקסטים עם ריבוי וגם צורות מגדריות, מחרוזות שנבנות בזמן ריצה משברים.
הקטגוריה האחרונה — המקור העיקרי לבאגים: המתרגם רואה "קיבלת 3 מטבעות", אבל בקוד מדובר בשלוש מחרוזות נפרדות שמודבקות בשרשור, ובשפה עם סדר מילים אחר או מערכת ספרות אחרת הרכבה כזו מייצרת זבל.
מחרוזות דינמיות דורשות שהמתרגם יעבוד לא עם משפט מוכן, אלא עם תבנית והמשתנים שלה. אנו מסמנים כל פלייסהולדר, קובעים את סוגי ההשמה המותרים ובודקים שאחרי השמת הערך המקסימלי המחרוזת לא חורגת מהמכל.
בנפרד נעשית עיצוב נתונים: תאריכים, שעות, מפרידי ספרות, פורמטים של מספרים ומטבעות, יחידות מידה — כל אלה קשורים ללוקל של המכשיר, לא לשפת הממשק, ובהגדרה שגויה השחקן רואה תאריך בפורמט זר.
גופנים ופריסה סוגרים את המעגל. לא כל גופן מכיל את הגליפים הדרושים, וקירילית מורחבת, כתב ערבי או הירוגליפים משנים את מטריקות הטקסט: כתובית שבשפת המקור תפסה שורה אחת, בשפת היעד שוברת את הכפתור. אנו מריצים את המסכים המלוקלזים דרך בדיקה של גלישה וחיתוך, ולא מסתמכים על כך ש"התרגום קצר".
שורה תחתונה: תרגום רגיל מוסר קובץ עם מחרוזות, לוקליזציה של משחק מובייל מוסרת בילד עובד בלוקל היעד — עם השמות מאומתות, פורמטים תקינים ופריסה שלא מתפרקת.
מקרה בוחן: כיצד לוקליזציה האיצה את יציאת המשחק לשווקים חדשים
היה פרויקט על מנוע עם טבלאות מחרוזות נפרדות לפי שפות: כל לוקאל חדש נוסף ידנית, ועדכון עם שפה אחת ארך עד שלושה שבועות. הטקסטים חיו בטבלאות, הפריסה — בענף נפרד, וכל תיקון במחרוזת המקור שבר מסכים שכבר תורגמו. עד לשחרור הצטברו 12% מחרוזות חתוכות בממשק ופערים מתמידים בין הגרסאות.
מה שינו
הרכיבו קו ייצור אחיד: מחרוזות המקור מיוצאות לפורמט משותף, המתרגמים עובדים בו עצמו, ואריזת חבילת השפה מופעלת אוטומטית לפי תג. המפתחות הפסיקו להיות משוכפלים בין מסכים, הוספה בדיקת אורך מחרוזת לכל פריסה — חיתוך נתפס לפני האריזה, ולא במכשיר. עבור ערבית ועברית הופעלה שיקוף פריסה ברמת הסגנונות, ולא בתיקון ידני של הפריסה.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| הוצאת עדכון עם שפה חדשה | עד 3 שבועות | 3-4 ימים |
| מחרוזות חתוכות בממשק | 12% | פחות מ-1% |
| שגיאות פריסה בשפות חדשות | קבועות, נתפסו בבדיקה | בודדות, נחסמות באריזה |
| שימור בשווקים חדשים | בסיסי | צמיחה בשבועות הראשונים לאחר ההשקה |
האצת הוצאת השפות נתנה לא רק לוחות זמנים: הצוות החל להוסיף לוקאלים במקביל לפיתוח פיצ'רים, ולא אחריו. תוצאות הלוקליזציה נראו בשימור — שחקנים בשווקים חדשים הגיעו למכניקות המרכזיות לעתים קרובות יותר, כי הממשק הפסיק "להיקרע" בשפתם.
Unity Localization ומערכות דומות לניהול מחרוזות סוגרות חלק מהמשימות, אך אינן מבטלות בדיקה ידנית של הקשר ואורך — לכן בקו הייצור נשאר שלב סקירת תרגומים על ידי דובר שפת אם לפני האריזה.
ספקות לפני ההתחלה: תאימות, מיגרציה, rollback
תאימות לוקליזציה כמעט אף פעם לא נתקעת במנוע — היא נתקעת באופן שבו המחרוזות קשורות ללוגיקה. אם הטקסט מוטבע בקוד או נאסף לקובץ שטוח אחד, הוספת שפה שוברת את הבנייה: מפתחות משוכפלים, חלק מהמחרוזות נשארות ללא תרגום, ומייצגי פורמט כמו %1$s ו-{count} מתפזרים בין המיקומים.
לכן, כצעד ראשון אנו מפרידים בין תוכן לקוד: המחרוזות מועברות לטבלאות עם מפתחות יציבים, והתרגומים מחוברים כערכות נפרדות, ולא כעריכה של קוד המקור.
מה אם בפרויקט כבר קיימת לוקליזציה בפורמט אחר? מיגרציית המחרוזות מתבצעת דרך טבלת התאמה מתווכת: מפתחות ישנים מותאמים לחדשים, קונפליקטים ומחרוזות "יתומות" נכנסים לדוח נפרד, ולא הולכים לאיבוד בשקט. לאחר ההעברה אנו מריצים בנייה בכל השפות — פער במספר המפתחות בין הערכה המקורית לזו היעד נראה מיד.
כיצד מתבצע rollback של שפה כושלת? rollback של לוקליזציה הוא החזרת הערכה הקודמת של המחרוזות, ולא בנייה מחדש של האפליקציה: הערכות מנוהלות בגרסאות בנפרד מהקוד, ולכן השפה הבעייתית מוסרת בהחלפת הפניה, ללא מהדורה חדשה בחנות. פסאודו-לוקליזציה (הצבת מחרוזות מוארכות) מראה מראש היכן הפריסה לא תשרוד טקסט בגרמנית או בפינית.
מה אם יש לנו פורמט מחרוזות משלנו ואסור לשנות אותו?
אנו כותבים ממיר בין הפורמט שלכם לפורמט העבודה: בקלט מוזן הקובץ הנוכחי, בפלט — אותו פורמט עם ערכים מעודכנים. הצינור המקורי נשאר ללא שינוי, ואנו עובדים עם ייצוג מתווך. את הממיר ואת כללי ההתאמה של המפתחות אנו מוסרים יחד עם שאר התיעוד.
הצוות מוסר לידיים:
- קונפיגורציות בנייה לפי שפות ופלטפורמות;
- סכמת מפתחות עם כללי שמות ותחומי שימוש;
- מדיניות ניהול גרסאות של ערכות מחרוזות וסדר ה-rollback;
- דוח מיגרציה: התאמה בין מפתחות ישנים לחדשים, רשימת קונפליקטים;
- תיעוד לוקליזציה — תקנון הוספת שפה ועריכת טקסט;
- מערך בדיקות לפער במפתחות ובמייצגים בבנייה;
- הוראות לפסאודו-לוקליזציה לבדיקת פריסה.
תארו את המשימה — נחזור עם הערכה ותוכנית: נראה אילו צעדים נדרשים בדיוק לפרויקט שלכם ומה מזה כבר מכוסה בצינור הנוכחי.