ביצוע לוקליזציה של אפליקציית מובייל לאנגלית

לוקליזציה של אפליקציה לנייד: היכן הגרסה האנגלית נשברת

לוקליזציה של אפליקציה לנייד נשברת לרוב לא בתרגום המחרוזות, אלא בהנחות שמוטבעות בקוד. המפתח בונה מסך עבור טקסט ברוסית, שבו "Оформить заказ" תופס 15 תווים, בעוד "Proceed to checkout" באנגלית תופס 19.

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

כך גם בפורמטים של תאריכים: dd.MM.yyyy בגרסה האנגלית נקרא כ-MM/dd/yyyy, ו-"03.04" הופך משלושה באפריל לארבעה במרץ — בדוחות, בהזמנות ובתזכורות זו שגיאה קריטית.

סוג נפרד של בעיות בלוקליזציה — נטיות וצורות רבים. ברוסית "1 товар, 2 товара, 5 товаров" — שלוש צורות, באנגלית — שתיים (1 item, 2 items). אם בקוד מוטבעת הלוגיקה if (count === 1), הגרסה האנגלית או תציג "1 items", או תשבור את המונה באפס.

בדומה לכך עם יחסות בתבניות של מכתבים והתראות push: הצבת שם בתוך משפט ברוסית עובדת, ובמשפט באנגלית — נותנת "Hello, Ivan Ivanov!" במקום "Hi, Ivan".

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

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

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

מה נותנת לוקליזציה נכונה לאנגלית

המרה בכניסה יורדת פחות

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

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

נשירה לאחר ההפעלה הראשונה פוחתת

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

תיקונים חוזרים בממשק כבר אינם נדרשים

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

השוק דובר האנגלית נעשה ניתן לניהול

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

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

גישות ללוקליזציה: ידנית, אוטומטית, היברידית

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

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

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

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

איך אנחנו מבצעים לוקליזציה: מביקורת ועד מסירה

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

1. ביקורת מחרוזות. אנחנו אוספים את כל משאבי הטקסט מהקוד ומהסימון, כולל תוויות שמוטבעות בלוגיקה, פורמטים של תאריכים ומספרים, טקסטים של שגיאות והתראות push. בתוצר — מרשם מחרוזות עם סימונים מה מתורגם, מה נשאר קבוע, ומה דורש עיבוד מחדש: חיבור ביטויים באמצעות קונקטנציה ויחסות קבועות מראש נשברים ראשונים בלוקליזציה.
2. תכנון מילון. אנחנו יוצרים גלוסר של מונחים וסגנון אחיד לגרסה האנגלית, כדי שאותו מונח לא יתורגם בשלוש דרכים במסכים שונים. במקביל אנחנו מקצים מרווח באורך המחרוזות: תוויות באנגלית ארוכות בממוצע ברבע מהמקור, וזה משפיע ישירות על הפריסה של כפתורים וטאבים.
3. הגדרת צינור הלוקליזציה. אנחנו מחברים את קובצי התרגום למערכת ניהול התרגומים ולמערכת הבילד כך שעדכון מחרוזות לא ידרוש עריכה ידנית של הקוד. לאחר מכן מחרוזות חדשות נכנסות למילון אוטומטית, והבילד קולט את הגרסה העדכנית — לא נוצרות אי-התאמות בין ענפים.
4. בדיקת פריסה. אנחנו מריצים את המסכים עם מחרוזות באנגלית ובודקים היכן הטקסט נחתך, נשבר באופן לא אסתטי או מתנגש באלמנטים. את התיקונים מבצעים בסימון, ולא על ידי התאמת התרגום לאורך המקורי.
5. בדיקה על מכשירים. אנחנו בודקים תרחישים על מכשירים אמיתיים: החלפת שפה בזמן אמת, פורמטים של תאריכים ומספרים, מיון רשימות, חיפוש, התראות. בנפרד אנחנו בוחנים מקרי קצה — שמות ארוכים, מחרוזות חסרות, התנהגות בעת החלפת שפה בזמן שהאפליקציה פועלת.
6. מסירה. אנחנו מוסרים את המילון, את הצינור המוגדר והוראות כיצד להוסיף שפות חדשות בלי לבנות מחדש את הלוגיקה. לאחר מכן צוות הלקוח מרחיב את הלוקליזציה בעצמו.

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

מה הלקוח מקבל לאחר לוקליזציה של האפליקציה

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

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

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

מקרה בוחן: איך הגרסה האנגלית הפסיקה לשבור את הפריסה

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

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

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

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

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

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

Duolingo

במה שונה לוקליזציה מאינטרנציונליזציה?

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

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

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

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

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

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

ספקות טכניים נפוצים בעת לוקליזציה לאנגלית

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

האם יש לחבר גופן נפרד עבור הלטינית?

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

מדוע אי אפשר פשוט למסור את המחרוזות למתרגם ולהדביק בחזרה?

מכיוון שחלק מהמחרוזות הן לא טקסט אלא לוגיקה: נטיות, סדר מילים במשפט, פורמטים של מספרים ותאריכים. האנגלית דורשת סדר ומפרידים אחרים — "1,234.56" במקום "1 234,56", חודש לפני יום בתאריכים.

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

כיצד אתם עובדים עם תיקונים מדוברי שפת אם?

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

נדון במשימת הלוקליזציה של אפליקציית המובייל שלכם

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

מה כדאי להכין לשיחה

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

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