למה קובצי לוקליזציה מתורגמים שוברים אפליקציות (ומה חייב להישאר ללא שינוי)

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

קובצי שפה בפורמטים PO, YAML, .properties, RESX, XLIFF ו-JSON נראים כמו רשימות של משפטים, אבל רק הערכים הם טקסט. המפתחות הם מזהים שהקוד מחפש; מצייני המיקום הם משבצות שהקוד ממלא בזמן ריצה; רצפי הבריחה והתגיות הם תחביר שהמנתח (parser) תלוי בו. מתרגם שמתייחס לכל השורה כטקסט ייצור קובץ שנקרא נהדר ולא נטען, או נטען ואז קורס בפעם הראשונה שמסך כלשהו מעצב מספר. התקלה בדרך כלל מופיעה בשפה אחת בלבד, ולכן זה סוג הבאג הקשה ביותר לתפוס בסקירה.

חמישה דברים שחייבים לשרוד את התרגום ללא שינוי

• מפתחות ושמות משאבים — הקוד מחפש מחרוזות לפי מפתח, כך שמפתח מתורגם הוא פשוט מחרוזת חסרה.
• מצייני מיקום — %s, %1$d, {0}, {name} וארגומנטים של ICU מתמלאים על ידי הקוד; שינוי שם של אחד מהם או השמטתו שוברים את העיצוב או זורקים חריגה בזמן ריצה.
• רצפי בריחה וכללי קידוד — קובץ .properties שנקרא בשיטה הקלאסית Properties.load(InputStream) מטופל כ-Latin-1, ותווים אחרים נכתבים כרצפי בריחה \uXXXX, כך שטקסט לא לטיני גולמי עלול להפוך לג׳יבריש (mojibake).
• תגיות בתוך מחרוזות — תגי HTML, קודים מוטבעים של XLIFF ו-Markdown חייבים להישאר מאוזנים, אחרת המחרוזת המוצגת שוברת את הדף שסביבה.
• מבנה הקובץ — הזחה ב-YAML, סקלרים של בלוק, עוגנים וכינויים (aliases), וקינון XML הם תחביר; הזחה שזזה או שם עוגן מתורגם משנים את משמעות הקובץ.

רבים זה לא יחיד ועוד "s"

באנגלית יש שתי צורות ריבוי, ולכן מפתה לחשוב שכך בכל שפה. המדריך של GNU gettext מראה למה זה נכשל: כל שפה מצהירה על כלל Plural-Forms משלה, האנגלית משתמשת ב-nplurals=2, והרוסית צריכה שלוש צורות שנבחרות לפי הספרות האחרונות של המספר. קובץ PO שתורגם לרוסית ובו מולאו רק שתי צורות עובר קומפילציה, רץ ומדפיס דקדוק שגוי לכל כמות שמסתיימת ב-2, 3 או 4. טיפול נכון בריבוי פירושו לייצר את מספר רשומות msgstr שדורשת שפת היעד, ולא את המספר שבמקרה היה לשפת המקור.

לפעמים מצייני מיקום צריכים לזוז

סדר המילים שונה בין שפות, ולכן משפט עם שני ערכים צריך לעיתים קרובות למקם אותם בסדר הפוך. מצייני מיקום לפי מיקום כמו %1$s ו-%2$s, או מצייני מיקום בעלי שם כמו {count} ו-{user}, קיימים בדיוק בשביל זה: התרגום רשאי לשנות את סדרם, אבל כל אחד מהם חייב עדיין להופיע בדיוק פעם אחת. מצייני מיקום אנונימיים, כמו %s חשוף, אי אפשר לסדר מחדש בבטחה — וזו בעיה שכדאי לתקן במחרוזות המקור לפני התרגום ולא אחריו.

כללי פורמט שכדאי להכיר לפני שמתרגמים

לכל פורמט יש מלכודות משלו. ב-YAML, המפרט מעניק לבלוק מילולי (|) ולבלוק מקופל (>) התנהגות שונה של שבירת שורות, ועוגנים (&) וכינויים (*) מאפשרים לצומת אחד להשתמש מחדש באחר, ולכן שניהם חייבים לעבור ללא שינוי. XLIFF 2.1 עוטף את העיצוב המקורי ברכיבים מוטבעים כמו <ph> ו-<pc>, שהתרגום חייב לשמור במקומם סביב המילים הנכונות. ב-.NET, משאבי RESX נמצאים לפי שם בזמן ריצה עבור תרבות ממשק המשתמש הנוכחית, כך שרכיב data ששמו שונה חוזר בשקט לשפת ברירת המחדל. וקובץ .properties של Java מתייחס לתו =, : או לרווח הראשון שאינו מוברח כמפריד המפתח, כך שנקודתיים תועות במפתח מתורגם מפצלות אותו לשניים.

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

1. ספרו את מצייני המיקום בכל מחרוזת מקור ויעד — המולטי-קבוצה חייבת להתאים, גם כשהסדר לא.
2. השוו את המפתחות, לא את הערכים — כל מפתח שקיים במקור וחסר או ששמו שונה ביעד הוא באג.
3. טענו את הקובץ המתורגם עם המנתח האמיתי (msgfmt, טוען YAML, ResXResourceReader) לפני שמשחררים אותו.
4. בדקו את רשומות הריבוי מול הכלל של שפת היעד, לא מול שפת המקור.
5. הציגו את התרגום הארוך ביותר ברכיב הממשק הצר ביותר — טקסט בשפות אחרות ארוך לעיתים קרובות מהאנגלית.