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

בדיקת לוקליזציה של אפליקציית מובייל: תקלות אופייניות

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

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

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

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

תבניות של תאריכים, מספרים ויחידות — סוג התקלות השני. 03/12 נקרא כמרץ או כדצמבר בהתאם ללוקאל, פסיק מול נקודה בשברים עשרוניים שובר קלט בשדות, וכללי ריבוי עבור רוסית (צורות שונות ל-1, 2 ו-5) לא נסגרים בהצבה פשוטה של מספר. ערבית ועברית מוסיפות פריסה מראה: אייקונים, חצים ופסי התקדמות צריכים להתהפך יחד עם הטקסט.

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

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

אודיט לוקליזציה קבוע מעביר פגמי שפה מהקטגוריה "המשתמש מצא" לקטגוריה "הבדיקה מצאה".

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

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

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

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

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

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

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

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

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

שלבי הטמעה: מאודיט ועד מסירה לצוות

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

איך בנוי הרצף

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

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

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

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

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

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

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

חבילת מסירה: קונפיגורציות, תרשימים, מדיניות גישה

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

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

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

מקרה בוחן: אודיט לוקליזציה צמצם תקלות אחרי עדכון

מה היה לפני האודיט

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

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

מה שינו

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

מדדים לפני ואחרי

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

במה שונה בדיקת תרגום מהרצות קבלה?

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

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

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

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

בילדים ופורמטים: שאלות נפוצות לפני התחלה

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

חלק מהטקסטים מגיעים מהשרת — גם אותם אתם מכסים?

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

באיזה סדר מתבצעות ההרצות?

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

בוצעו תיקונים — לבדוק הכול מחדש?

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

נדבר על המשימה: מה צריך להערכה ולתוכנית

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

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

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