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

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

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

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

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

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

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

מה נותנת לוקליזציה: תוצאה מדידה למוצר

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

מהירות שחרור ויכולת חיזוי של הפריסה

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

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

פחות תיקונים ופניות לתמיכה

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

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

דרכים למימוש תרגום ממשק: השוואת אפשרויות

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

איך לבחור אפשרות למוצר

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

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

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

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

קבלת הלוקליזציה

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

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

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

קבצים, סכמות ופרופילים

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

נהלים ותיעוד

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

מקרה בוחן: איך הסרנו פערי טקסטים בין הפלטפורמות

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

הפערים נמצאו ב-96 מסכים מתוך 240 — כ-1,800 מחרוזות: בפלטפורמה אחת הכפתור נקרא «Buyurtma berish», באחרת — «Buyurtma», ובממשק הווב הטקסט פיגר בשבועיים.

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

מה בדיוק הועבר

המלאי נערך לא לפי קבצים, אלא לפי מסכים — כך רואים חסרים וכפילויות:

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

אחרי חודשיים פניות לתמיכה עם תלונות על טקסט לא מובן או לא תואם ירדו מ-250–270 ל-60–70 בחודש. זמן שחרור עדכון עם ניסוחים חדשים הצטמצם מ-18–20 יום ל-2–3, ונעלם סוג שלם של שגיאות: אי אפשר יותר לבצע תיקון במקום אחד ולא לשים לב לשניים אחרים.

מה לעשות אם המוצר כבר שוחרר, והתרגום נדרש עכשיו?

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

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

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

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

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

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

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

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

ספקות נפוצים: אורך מחרוזות, גופנים, תבניות תאריך

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

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

להלן השאלות שהכי часто עולות לפני תחילת העבודה.

מה לעשות עם טקסטים שמגיעים מהשרת?

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

איך לבדוק איכות אם אין דובר שפת אם בצוות?

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

צריך לתמוך גם בכתיב הלטיני וגם בקירילי?

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

אפשר לתקן תרגום אחרי שחרור?

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

נדון במשימה: מה לשלוח להערכת נפח התרגום

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

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

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