תרגום בכלל, ותרגום של ממשק משתמש בפרט, הוא אתגר לא פשוט. פערי תרבות, חוסר הבנה, שיטות תרגום מוזרות ולפעמים גם סתם חוסר מקצועיות, גורמים לתופעות מפתיעות. כמה אנקדוטות מצחיקות, וחלומות על שינוי. אופטימי, אמרנו?
עברית קשה שפה
אירופאית של מכשירי ביתיים
הבטחתי אנקדוטות מצחיקות, אז הנה אחת די ותיקה. לפני 15 שנים בערך, הורי קנו תנור של חברת De Dietrich הגרמנית. אני לא יודע איך זה אצלכם, אבל אצלי במשפחה יש כבוד גדול למוצרים תוצרת גרמניה. אולי אלה השורשים היקיים שלנו, או סתם עבודת תדמית טובה של הגרמנים.
בכל מקרה, נחזור לתנור, או ליתר דיוק, לחוברת ההפעלה שלו. את החוברת תרגם, ככה שיערנו אז, סטודנט גרוע במיוחד לעברית באוניברסיטת ברלין (אין להשערה הזו שום בסיס, לפחות לחלק של ברלין בסיפור). התרגום היה, איך לומר בעדינות, זוועה. מימין השער של החוברת. שימו לב לסלוגן של דה דיטריך – "אירופאית של מכשירי ביתיים". שלא לדבר על ה"כיריים עם תנור רב פעלי קטאליטי".
החוברת בפנים רק משתפרת. תחת הכותרת "אי-סדרים קטנים שתוכל לתקן בעצמך" כתוב "סיבת הקלקול היא לעתים תכופות קטן-ערך. קודם לקרא לשירות לאחר מכירה וודא שאינך יכול לעביר את ה"דופי" בעצמך. לדוגמא, התנור והפלטה המתכננת אינם פועלים: וודא שהמתכנת מכוונת על מצב ידני". מסתבר שהתנור הספציפי הזה מגיע עם מתכנת! דיל די מוצלח, לא? אולי הוא יבין את ההוראות. ויש עוד: "לתנור רב פעלי יש חמש אופני פעולה שלמים. מצד אחד, שלש אופני אפיה טרדיציונלים: נזיפה פיזור החום, נזיפה מזגית, תת אדום. בצד השני: שני האופני אפיה שגרתים: טורבו גריל, אופיה משולבת." מבולבלים? גם אנחנו…
תרגום אוטומאטי
אם הייתי מקבל את החוברת של דה דיטריך היום, הייתי אומר שהיא תורגמה במנוע התירגום האוטומאטי של גוגל. אבל נעשה בעידן אחר, כשסרגיי ברין ולארי פייג' עדיין לא חלמו איך ישלטו בעולם. אני חושב. בכל מקרה, בשביל הקטע, נתתי לשירותי התרגום של גוגל לתרגם את הפיסקה הראשונה בפוסט הזה. באופן מפתיע, חלק מהתרגום נשמע ממש הגיוני. חלק אחר – ממש לא.
General translation, a translation of the user interface in particular, is not just a challenge. Cultural gaps, language, translation strange ways sometimes just a lack of professionalism,
phenomena do not cause very unpleasant. Some joke funny, and dreams of the change. Optimistic, we said?
לא שור ולא בור, Pit Bull
שימו לב למשפט האחרון – הוא ממש קיבל משמעות הפוכה!
והנה מגיעה אנקדוטה שניה. בימים שעוד ראיתי טלוויזיה על בסיס קבוע, היתה סידרה בערוץ שלוש שבה הגיבור התלונן, באותו פרק שראיתי, על הכלב של השכנים. הוא אמר "The pit bull was barking all night! I just couldn't sleep". בתרגום לעברית היה כתוב… תחזיקו חזק… "השור שבבור נבח כל הלילה, לא יכולתי לישון!"
הקושי שבתרגום
על-פי ויקיפדיה, תרגום מתבצע בשני צעדים:
- פענוח המשמעות של הטקסט שבשפת המקור.
- הפיכת משמעות זו לטקסט בשפת היעד.
בדוגמא הראשונה שנתתי, עם התנור, ברור שהיתה בעיה בשלב השני: אין לי ספק שהמתרגם הבין גרמנית, אבל המשמעות לא תורגמה נכון.
בדוגמא השניה, עם הפיטבּוּל, המתרגם הבין את המשמעות בצורה שגויה, אבל תרגם אותה נכון לעברית. כנראה שאף פעם לא נשך אותו פיטבּוּל… וטוב שכך. אז הנה סוג אחד של קושי. היכרות לקויה עם שפת המקור או שפת היעד.
מניח הרעפים הנוצרי, Christian Slater
אבל היכרות עם השפה לא מספיקה. כלומר, לא מספיק להכיר את המילים שבשפה. דרוש קונטקסט תרבותי כדי להבין את המשמעות של המילים בהקשר שלהן בשפת המקור ובשפת היעד. הנה דוגמא מעולה, גם מערוץ 3, שמובאת בויקיפדיה. המשפט "I had to chase Christian Slater down the street" תורגם ל"הייתי צריכה לרדוף אחרי מניח רעפים נוצרי". "מניח רעפים נוצרי" הוא תרגום מילולי של שמו של השחקן כריסטיאן סלייטר. :-)
ואם זה לא מספיק, אז יש שימושים מיוחדים בשפה, כמו שירה, שבהם יש גם עניין של משקל, חריזה, כפל משמעות ועוד, שהופכים את מלאכת התרגום לבלתי אפשרית כמעט. נתקלתי באתגר הזה בעצמי כשנעזרתי במתרגמת לתרגם את השירה של מיה הוד, באתר המשותף שלנו – קצת על אהבה, לאנגלית. על שיבושי תירגום אחרים אפשר להרחיב את הקריאה בויקיפדיה.
תירגום של ממשק משתמש
אני בדרך כלל לא נוהג להשתמש בממשק משתמש עברי של תוכנות. מעבר לזה שזה גורם לי לקשיי התמצאות קשים – למצוא את התפריט בצד השני, כפתור ה"Start" בצד השני אם זה חלונות בעברית, וכו', התרגום לעברית של ממשקי משתמש הוא בדרך כלל לא מהטובים שיש. נופלים בו גם הגדולים ביותר, כמו מייקרוסופט וגוגל. אני לא יודע איך זה בשפות אחרות, אבל בעברית המצב ממש מחפיר, לפעמים.
אחת הפעמים הראשונות שנתקלתי בזה, היתה ב-Access 2000 או אולי 97', שם מייקרוסופט תרגמו את "Delete Query" ל"מחיקת שאילתה", "Select Query" לבחירת שאילתה, וכו'. למי מכם שלא מתמצא בבסיסי נתונים, המשמעות של "Delete Query" היא לא מחיקת שאילתה, אלא "שאילתת מחיקה". המושג הזה כל-כך יסודי בבסיסי נתונים, וכל-כך מרכזי בממשק המשתמש, שפשוט לא האמנתי למראה עיני כשהשתמשתי בממשק העברי בפעם הראשונה. אז איך זה קורה?
למתכנתים שבקהל זה בטח ברור, אז אתם יכולים לעבור לכותרת הבאה. כשכותבים תוכנה שאמורה לעבור תירגום, שמים את כל הטקסטים שמופיעים בממשק המשתמש בצד, במה שנקרא resource file, או קובץ משאבים. הטקסטים בקובץ המקורי שבונים המתכנתים כתוב בדרך-כלל בשפת האם של המתכנתים, או השפה הבסיסית של המוצר.
שיטת abc בפעולה
את הקובץ הזה, כמו שהוא, לוקחים ומעבירים למתרגם. למתרגם אין שום מושג מאיפה בממשק הטקסטים הגיעו. במקרה הטוב, למתרגם יש הבנה כלשהיא לגבי המוצר ומה הוא עושה (עולם הבעיה של המוצר), אבל גם זה לא תמיד קורה. התוצאה – "מחיקת שאילתה" במקום "שאילתת מחיקה". הטכנולוגיה הרגה את התרגום. הוא גם לא רואה את התרגום מופעל בתוך התוכנה, לפחות לא מייד. הוא קודם מתרגם את כל הקובץ, מעביר אותו למתכנתים, ורק אחרי כמה ימים הוא מקבל את הגירסה המתורגמת, אחרי שכבר שכח את המקומות שלגביהם התלבט עם התרגום.
אז למה לא לתת למתרגמים לעבוד עם התוכנה כך שיבינו אותה לפני שהם מתרגמים? בדרך-כלל המתרגמים הם לא עובדים בחברה שמייצרת את התוכנה, וגם אם כן, הם לא נמצאים באותו מקום שמפתחי התוכנה נמצאים, וגם אם כן, הם עמוסים מכדי לטרוח ולהבין. בקיצור – זו בעייה של תקציב. הגישה ברוב המקומות שעבדתי בהם היא – הלקוחות כבר יסתדרו עם מה שניתן להם. זה כנראה מה שקרה לסוני אריקסון, שקראו לאנגלית בסלולרי שלי "שיטת abc".
צר לי
לתהליך התרגום של ממשק המשתמש קוראים לוקליזציה, localization, וההכנה ללוקליזציה שכוללת, בין השאר, את הכנת קובץ המשאבים (resources) שהזכרתי קודם, נקראת… internationalization. זה כל-כך ארוך, שאפשר לטעות ולחשוב שזו מילה בגרמנית. באחת החברות שעבדתי כתבו את זה בקיצור i18n, כי בין ה-i ל-n יש 18 אותיות. אני יודע, גם אני לא האמנתי, תספרו. תרגום לעברית של תוכנה נקרא לפעמים בסלנג "גיור".
בעיה נוספת שיש בלוקליזציה היא המקום במסך. זה בולט במיוחד באפליקציות חלונאיות קלאסיות (לא כאלה שמבוססות על WPF ושות' או אפליקציות באינטרנט), שבהן לכל טקסט יש מקום מוגדר ומוגבל על המסך. ניקח למשל את המסך הזה ממערכת ההפעלה Windows:
נניח, לצורך העניין, שהמתרגם החליט לתרגם את "slow" ל"זוחל כמו צב". איפה היינו מכניסים את המילים האלה כאן? היה צריך, כנראה, לשנות את התוכנה כדי שיהיה מקום לטקסטים ארוכים יותר, או למצוא קיצור הולם ל"זוחל כמו צב". בבעיות האלה נתקלים בתרגום תוכנה כל הזמן. מגיע קובץ משאבים (resource file) מתורגם, ואז צריך לבדוק בכל מקום שיש בו טקסט שהמתרגם לא כתב משהוא ארוך מדי שלא נכנס, ושהיישור של הטקסט עדיין נכון גם כשהטקסט מתקצר או מתארך קצת. בקיצור – לא קל!
I Have a Dream
ובחלומי, המתרגמים יושבים עם צוות הפיתוח או צוות המוצר, לומדים איך להשתמש בתוכנה על כל פרטיה הקטנים, ורק אז מתחילים לתרגם את הממשק. את התרגום עושים על גבי המסכים, ולא בקובץ נפרד מהתוכנה, כדי שלא יהיו טעויות של תרגום שגוי, ארוך מדי, מיושר לצד הלא נכון. בחלום שלי גם אין פיטבולים. וגם לא את כריסטיאן סלייטר…
נושא מאד מעניין
עוד בעיתיות בתרגום היא ב"קופי" של המוצר,
לפעמים באתרים אפשר במילה אחת לסכם קטגוריה שלמה, וזה לא עובר יפה כל כך בין השפות
בגלל שעצם האיחוד של כל התת קטגוריות תחת מילה אחת שיש לה משמעויות רבות ומדוייקות כל כך. ברגע שמתרגמים אותה המושג כבר לא עובד בתור קטגוריה ראשית, כי אין לו את אותה האיכות של ההסברה, מה עומד מאחורי הקטגוריה הזו
אני נתקל בכך רבות שאני עובד על אתרים שיש להם תרגומים לכמה שפות.
אבירן,
זו באמת בעיה קשה. זהו עוד פן של ההקשר התרבותי. לפעמים צריך משפט שלם בשפה אחת, בשביל להעביר את כל מה שעובר במילה אחת בשפה אחרת. מאחורי המילים "חוצפה" או "פראייר" בעברית יש המון משקל תרבותי שאי אפשר להעביר לשפה אחרת, אנגלית, למשל. "sucker" לא ממש מעביר את הבוז החברתי של "פראייר". באנגלית פשוט אומרים "chutzpah", פשוט כי אין דרך אחרת להגיד את זה. המילון של ה-Firefox אפילו מכיר את המילה הזאת, מסתבר. זה במיוחד כואב בממשק שצריך לתרגם אותו לשפה אחרת, כשבממשק יש מקום רק למילה אחת – כמו Slow בדוגמא שנתתי בפוסט.
זה הזכיר לי אנקדוטה אחרת. באחד מבתי התוכנה שעבדתי בהם התוכנה תורגמה לגרמנית. ישבתי עם המתרגמת, והסתכלתי בפעם הראשונה על הממשק המתורגם, כשלפתע קראתי "Schnellsuchen Model" בתפריט. נחרדתי לראות את המילה "Schnell", שהכרתי בעיקר מערוצים מסויימים בכבלים, משעות מסויימות בלילה, ואמרתי לה בלחש – "תגידי, אין פה טעות?" היא צחקה ושאלה, "למה?", אז שאלתי,"המילה הזאת, Schnell, זה לא גס?", כאן היא כבר התפוצצה מצחוק, ואמרה "לא, Schnell זה מהר, מה אתה חשבת שזה?" "שום דבר, שום דבר", והלכתי לקחת כוס מים מהמטבח :-)
אתה משעשע אותי מאוד עם כל האנקדוטות שלך. אני זוכרת כמובן את הלהבה
המצטטטת של התנור היקי ואני גם זוכרת שראיתי איתך את התוכנית עם השור שבחור…
היה מצחיק אש ואני גם מזכירה את זה מידיי פעם בשיחות…
לגבי אורך מילים וטקסט בכלל, ההבדל בין שפות שונות יכול להיות 30% לכאן או לכאן. בסינית ויפנית למשל מדובר במספר תווים קטן מאוד למילה לעומת גרמנית. אנו מתמודדים בקרוב עם תרגום מערכת קיימת באנגלית לגרמנית ואני כבר צופה לא מעט בעיות :) נקודה מעניינת לגבי תרגום טקסטים ליפנית אגב היא שביפנית, בניגוד לשפות מערביות כמו אנגלית, משפט המפתח בפסקה הוא האחרון ולא הראשון. מההיבט הזה, תרגום "יבש" של מילים ואפילו משפטים מחוץ להקשר הרחב יותר של הטקסט לא יעיל ותרגום נכון דורש במקרה כזה השקעה ניכרת בניסוח הטקסט.
מצד שני….
בצעירותי למדתי קצת תרגום, היה אצלנו 7" יחידות אנגלית",
למורה היתה מילה שבה היתה מתארת תרגום מדוייק מאד,
מן מילה שאף אחד בכיתה לא חשב עליה, שמסכמת הכל במושג שיותר טוב אפילו מהמילה המקורית.
היא היתה אומרת "או, הנה לכם FLARE ! "
אמיר,
הנקודה שאתה מעלה לגבי סדר המשפטים בפסקה מעניין גם בהקשר של הממשק. אתה יודע האם זה בא לידי ביטוי בהודעות שגיאה? בהודעות שגיאה, בדרך כלל ההודעה העיקרית מופיעה למעלה בקצרה, משפט אחד, ואחר-כך הפירוט שלה מופיע מתחת. זה קורה הפוך ביפאנית? כלומר הפירוט למעלה והסיכום למטה?
אני לא יודע. אני מכיר את זה בהקשר של פסקאות אבל אולי אפשר לברר. עוד אנקדוטה מעניינת לגבי ממשקים ויפנית – מבנה התפריטים הקלאסי שאנו מכירים אינטואטיבי יותר ליפנים מכיוון שביפנית קודם מציינים את שם העצם ואחריו את הפועל כך שהצירוף File -> Open או Window -> Maximize תואם את תבניות החשיבה שמעוצבות על ידי השפה. באנגלית ובעברית לעומת זאת אנו חושבים Open -> File וכשמחפשים פעולה בממשק, בייחוד אם מדובר בממשק חדש, זה יכול להשפיע.
שלוש דוגמאות אנקדוטיות שאני זוכר מתרגומים של סרטים (ויש אינספור אנקדוטות כאלה):
הראשונה (לא זוכר מאיזה סרט), שני ילדים שנפרדו במטבע לשון מקובלת לילדים דוברי אנגלית:
– See you later, alligator,
– In a while, crocodile
שתורגם, באופן בלתי מפתיע בעליל, ל:
– להתראות, תנין.
– אחר כך, תמסח.
השנייה היא מעידן הקרח (Ice Age), אני לא זוכר את המשפט המדויק, אבל זה היה כשהממותה הלכה נגד התנועה, מרירה, בתחילת הסרט, ואוכל הנמלים, או חיה דומה כלשהי התעצבנה שהממותה מפריעה וצעקה עליה משהו. התשובה של הממותה היתה משהו כמו:
– I wouldn't make such a noise if I had such a small trunk.
והתרגום היה:
– אני לא הייתי עושה כל כך הרבה רעש אם היה לי תא מטען קטן כל כך
הדוגמא השלישית היא סיפורו של וויל האנטינג, שזה בדיוק הדוגמה ההופכית לכריסטיאן "מניח הרעפים" סלייטר, כאן שמו של הגיבור אמור היה להביע את משמעותו "Good Will Hunting" המרדף/החיפוש אחר כוח הרצון, או הרצון הטוב. התרגום איבד לחלוטין את משחק המילים הזה.
בנושא תרגומי תוכנה, עוד נישה קטנה היא תרגום של רשימות ממוינות לקסיקוגרפית. אם המיון לא נעשה "אונליין" בזמן הצגת הדיאלוג, אלא פשוט הרשימה נכתבת פעם אחת בצורה קשיחה, לפי הסדר באנגלית (כמו במרבית המקרים…) אחרי התרגום המיון הזה הולך לכל הרוחות…
תופעה שנייה היא תרגום מוגזם של מושגים שלא אמורים להיות מתורגמים (בדיוק כמו "Hutzpa") אני זוכר את "עיצוב כונן" מהגירסאות הראשונות של ווינדוס. למי שלא זוכר, דובר על Format Disk. ונשאלת השאלה, למה לתרגם מושג כמו "פורמט"…?
ועוד משהו זה חוסר הקפדה על עקביות. כאשר אותו מושג מתורגם בצורות שונות במיקומים שונים, בלי לשמור על קישור ביניהם (עוד פועל יוצא של שיטת תרגום "קובץ המשאבים" במקום לתרגם אחרי הבנת התוכנה ומסכיה). זה כל כך מעיק על המשתמש, שמוטב היה לא לתרגם כלל!
ולסיום, הערה ששמעתי פעם לגבי הקשר בין תרבות לשפה ומתקשרת לתחילת הפוסט הזה לגבי הייקים והתרבות הגרמנית. בגרמנית, מילת השלילה באה בסוף המשפט. למשל "אני לא יודע" זה "איך וויס נישט" (איך = אני , וויס = יודע, נישט = לא). מה שיוצא זה שפה שמכריחה להיות מנומסים. אי אפשר לקפוץ באמצע משפט, כי אולי הדובר יגיד "נישט" בסוף וישלול את כל ההצהרה! בעברית זה אף פעם לא יעבוד. או יעבוד תמיד לא… :)
צביקה, עיצוב כונן זה באמת נוראי. אני חושב שהדברים האלה כבר לא קורים עם מייקרוסופט בשנים האחרונות, מהמעט שיצא לי להציץ על התוכנות שלהם בעברית. כולי תקווה שהשגיאות הצורמות האלה הן נחלת העבר.
בענייני תרגום בתחום הבידור, שכחתי את אחת הדוגמאות החזקות מהקולנוע, הסרט "Lost in Translation" תורגם בעברית ל"אבודים בטוקיו". המתרגם באמת איבד את המשמעות בתרגום, ממש כמו שם הסרט…
קודם כל אי אפשר בלה קישור למגה-דיון (יכול להיות שזה הדיון הפעיל כי ארוך ברשת הישראלית) על מניח הרעפים הנוצרי:
http://www.fisheye.co.il/story?id=234 (מומלץ לפנות איזה שעתיים או שלוש לפני שלוחצים…)
וגם שווה להזכיר localization == l10n מאותן סיבות שכתובות למעלה…
אני מסכים מאוד שמי שמגייר את התוכנה חייב להכיר אותה על בוריה – לפחות כמשתמש, וחס ושלום לא לנסות לתרגם אותה סתם ככה כאוסף של משפטים ומילים תלושים.
מצד שני, אני מאמין שגיור אמיתי צריך לחרוג בהרבה מעבר לתרגום עצמו ולבעיות דיקדוקיות ואפילו עיצוביות, כפי שכבר הוזכר פה, כל תוכנה או אתר כוללות תובנות תרבותיות, וכמעט תמיד כדאי לנסות להבין האם יש מאפיינים עמוקים יותר שכדאי לשנות שמעבירים ישום מקונטקסט תרבותי אחד לקונטקסט אחר. האם במדינה אחת המשתמשים מעדיפים יותר תמונות על פני טקסט? האם משמעות הצבעים והסמלים זהה בתרבות זו? האם פיצ'ר מסוים כלל לא אקטואלי לתושבים במדינות מסוימות? האם צריך לשאול את המשתמש גם לגבי שם אביו או שלא מנומס לשאול אם הוא זכר או נקבה?
אני בטוח שזה רק קצה הקרחון…
אודי
בחמש השנים האחרונות לימדתי קורס בשם Cultural Perspective שעסק בלוקליזציה של ממשקים והיבטים תרבותיים והנושא לדעתי מרתק ומאוד עשיר.
"אם במדינה אחת המשתמשים מעדיפים יותר תמונות על פני טקסט? " – בהחלט. בתרבויות המזרח (יפן כדוגמא קלאסית) יש עדיפות לסמלים ותמונות היות ואותיות השפה יותר פיקטוריליות וממשקים במזרח הרחוק נוטים להיות מרובי אייקונים, צלצולים ודברים שבמערב לא יעזו לעשות. אפשר לראות את זה אגב גם באמוטיקונים המורכבים שמשתמשים בהם ביפן http://club.pep.ne.jp/~hiroette/en/facemarks
"האם משמעות הצבעים והסמלים זהה בתרבות זו?" – המשמעות של צבעים היא תלויית תרבות וכך למשל לבן במזרח הוא צבע אבל לעומת שחור במערב. המשמעות של אדום בסין ורוסיה שונה מזאת שאנו מכירים מהמערב בגלל הקומוניזם. http://webdesign.about.com/od/color/a/bl_colorculture.htm
"האם פיצ'ר מסוים כלל לא אקטואלי לתושבים במדינות מסוימות?" – ישנם הרבה מקרים בהם מטעמים טכנולוגים, תרבותיים, סוציו-אקונומים, חוקיים וכו' פי'צרים מסויימים לא אקטואלים או חוקיים במדינה מסויימת. לפני מספר שנים היה מקרה שעורר הדים אחרי שבגרמניה חסמו את האפשרות להסיר את ה-safe mode בפליקר כי לפי החוק הגרמני פליקר לא הצליח לוודא בצורה טובה את גיל המשתמש. דוגמא טובה לפיצ'רים על פי תרבות אפשר לראות בתפריט של יאהו! כאשר משווים אותו בין הגרסאות המקומיות לצד פי'צרים אחרים. דוגמא אחת – במדינות ערביות לא תמצאו את איזור הדייטינג וההכרויות שתמצאו במדינות במערב.
"האם צריך לשאול את המשתמש גם לגבי שם אביו או שלא מנומס לשאול אם הוא זכר או נקבה?" – אם כבר בנושא שמות, קל מאוד להתעלם מהעובדה שבהרבה מדינות השמות של האנשים הם לא שם פרטי ושם משפחה עם מקסימום תוספת של שם אמצעי. בסין הסדר והמרכיבים של השם שונים ובספרד למשל השם מורכב לפעמים משם פרטי ועוד שלושה שמות אמצעיים. האם הטופס מאפשר להכניס את השמות הללו? ועוד ועוד ועוד.
למי שמתעניין ועוסק בתחום שלה לוקאליזציה אני ממליץ בחום על הספר http://www.amirdotan.com/blog/?p=73
לפני שנתיים כמעט כתבתי על אתרי אונירסיטאות בישראל, אנגליה ויפן היכן שלדעתי ניתן לראות בבירור הבדלים וסממנים תרבותיים
http://www.amirdotan.com/blog/?p=77
http://www.amirdotan.com/blog/?p=78
אכן, יש הרבה אספקטים ללוקליזציה של ממשק המשתמש. בפוסט שלי הכוונה היתה להתייחס בעיקר לאספקט המילולי של אפליקציות, ולא למובן הרחב של לוקליזציה.
אודי, אמיר, תודה על הכיוונים הנוספים והמעניינים שהעליתם כאן בהקשר של לוקליזציה. בפרוייקט שניהלתי לא מזמן התחבטתי עם סוגיות דומות. הפרוייקט כלל, בין השאר, מאגר של צילומים לשימוש בחומרים שיווקיים. קהל היעד היה מעצבים ואנשי פרסום ברחבי העולם. כשהיינו צריכים להוסיף למאגר תמונות עבור יפאן וסין, לא ניסינו בכלל לאתר תמונות לבד, לפני שקיבלנו הנחיות ממעצבים מקומיים לגבי מה אסור ומה מותר בתמונות בפרסום.
חלק מההנחיות שקיבלנו נשמעו לנו מוזרות. היו ביניהן גם דברים כפי שציינתם – צבעים והמשמעויות שלהם, שימוש בשפה ויזואלית שונה (טיפוגרפיה מול פיקטוגרמות, צילומים). היו גם דברים שקשורים בטרנד עיצובי עכשווי. ביפאן, למשל, המליצו לנו להראות דווקא צילומים של חנויות עם טיפוגרפיה באנגלית וקונים עם מראה מערבי, ולא יפאניים כפי שחשבנו בתחילה להראות. הנחיות מהסוג הזה הן על הגבול העדין בין עיצוב לממשק, נושא ראוי לכמה פוסטים בפני עצמו.
אפילו בדברים טריוויאליים כמו כתובת (או שם, כפי שאמיר העלה פה), שום דבר לא ברור מאליו. הרי מה צריך בסך הכל – שורה או שתיים לכתובת, עוד שורה לעיר ומיקוד, מדינה – וגמרנו, לא? בארה"ב לא, כי צריך גם לרשום מדינה, אבל לא באירופה. גם הבדיקות שעושים למיקוד שונות ממדינה למדינה. בישראל אלה 5 מספרים, באנגליה וקנדה יש 6 אותיות ומספרים. גם התצוגה משתנה: בגרמניה נהוג להציג את המיקוד לפני העיר, בישראל אחרי. מסובך!
נו, אז אולי שווה לכתוב פוסט נפרד על לוקצליזציה :-)
לוקליזציה של טפסים דורשת קורס שלם :) אחת הדוגמאות המוכרות ביותר הן גם כתיבת התאריך מפני שבאתרים אמריקאים הפורמט הוא 13.25.09 (חודש, יום, שנה) לעומת 25.13.09 (בכל מקום אחר) ויש גם הבדלים בשימוש בנקודות לעומת פסיקים במחירים והיכן בכלל שמים נקודה או פסיק אך אנחנו בהחלט גולשים לנושא מעבר לתרגום הממשק אליו התייחסת בפוסט. אגב, בנושא יפן והמערב ישנם לא מעט מקרים בהם היפנים יצפו למילים אנגליות בממשק של אתר כמו new! לדוגמא. זאת דוגמא טובה לדעתי כיצד בלוקליזציה צריך לקחת בחשבון גם גלובליזציה ולא לשאוף לתרגם כל מילה כי ישנן מילים לועזיות שאנשים יצפו להן.
"מניח רעפים נוצרי" הפך כבר ממש למיתוס בענף התרגום, והמילה "מר"ן" הפך להיות מושג כללי המתאר את התופעה: כמו במשפט: "ספרתי ארבעה מר"נים בסדרה שהוקרנה אתמול ב-20:00 בערוץ N…"
היי מיכל, וברוכה הבאה לבלוג :-)
אני תוהה מה המתרגם/ת של מר"ן עושה עכשיו, אם אחרי כל ההד ברשת הוא/היא עדיין מתרגמים. אולי זה דווקא טוב כיחסי ציבור, שנאמר any publicity is good publicity…
נושא הלוקליזציה והבינאום (internationalization בעברית צחה) הוא נושא רחב מאוד שחברות תוכנה ובניית אתרים רבות אינן מכירות, וחבל. אין ממש צורך שהמתרגמים והמתכנתים יישבו יחד, אלא לבנות את הממשק בצורה נכונה שמותאמת ללוקליזציה.
סיכום קצר בנושא הזה תוכל לקרוא בפוסט "לוקליזציה ובינאום על קצה המזלג" בבלוג שלי בדה-מרקר
http://cafe.themarker.com/view.php?t=1082011
תודה, יוסי. פוסט מצויין.
אני חייב לחלוק עליך – הבניה של הממשק בצורה שמותאמת ללוקליזציה היא תנאי הכרחי (אחרת טכנית פשוט אי אפשר לתרגם), אבל לא מספיק. כשלמתרגם אין הבנה עמוקה בעולם הבעיה של האפליקציה שהוא מתרגם, בשתי השפות, אין לו שום סיכוי לתרגם נכון. כך בדיוק "Delete Query" ב-Access הפך בעברית ל"מחיקת שאילתה" במקום "שאילתת מחיקה". למתרגם חייב להיות קונטקסט – לא רק תרבותי, אלא גם אפליקטיבי.
הכישורים של המתרגמים הם נושא נפרד ודי כאוב, ואני מכיר זאת באופן אישי כמי שמבצע הרבה בדיקות איכות עבור מיקרוסופט וחברות אחרות וגם בתור אחד שלעתים נאלץ להוציא תרגומים לקבלני משנה. יש כיום פולמוס שלם באגודת המתרגמים סביב נושא ההסמכה למתרגמים. המצב נכון להיום הוא שכל אחד יכול להכריז על עצמו כמתרגם בכל שפה ובכל תחום.
לגבי הדוגמה שהבאת ב- Access (מעניין, זו דוגמה שגם אני "אוהב" להביא), אחד המרכיבים החשובים בבניית ממשק מותאם ללוקליזציה הוא הוספת הערת הקשר לכל פריט תפריט, או לפחות לכאלה שיכולים להיות בעייתיים (לשם כך המתכנתים צריכים הכשרה לשונית). בשנים האחרונות מיקרוסופט דווקא די מקפידים בעניין הזה, אם כי לא מספיק לטעמי.
יוסי,
העברת האחריות על תיעוד המשמעות של פעולות בממשק למתכנתים היא בחירה מעניינת, אם כי לא מעשית ולא הגיונית לדעתי, משתי סיבות.
ראשית, שפה היא תחום המומחיות של המתרגמים, לא של המתכנתים. נדרשת פה עירנות שהיא מחוץ לתחום המומחיות של המתכנתים. שנית, בבתי תוכנה רבים מתכנתים לא הם שקובעים את התוויות של התפריט. קובע אותם מומחה/מעצב ממשק משתמש. האם להעביר את אנשי הממשק הכשרה לשונית? זה יכול להיות רעיון טוב. אבל עדיין, הבנה של עולם הבעיה שהמוצר עוסק בו, והכרת המונחים המתאימים בשפה אליה מתרגמים, היא קריטית עבור מתרגמים. אני אסביר.
קח למשל את המונח Browser. אם לא היית מכיר את עולם ה-Web, היית עשוי לתרגם אותו לעברית ל"עלעלן" ולא ל"דפדפן". רק שאת המילה "עלעלן" אף משתמש לא יבין. הדוגמא של Access היא דומה. אף מתכנת או איש ממשק ברי-דעת שמכירים SQL לא היו מדמיינים ש"Delete Query" יתורגם ל"מחיקת שאילתה" ולא "שאילתת מחיקה". זו טעות שרק מי שלא מכיר את עולם הבעיה של בסיסי נתונים יכול לעשות. באותו אופן שלא היית נותן לתוכנה לתרגם תרגום אוטומטי של שירה, כך מתרגם לא יכול לעשות את עבודתו כהלכה בלי להבין את הקונטקסט והמשמעות של התוכן שהוא עוסק בו. הדבר בולט במיוחד במוצרים שנועדו לקהל מצומצם ומקצועי, כמו Access.
נדמה לי שפספסת את הכוונה שלי
קודם כל נסגור את עניין המתרגם. מתרגם חייב להבין את הנושא שהוא מתרגם, לפחות באופן כללי. אם יש משהו שלא ברור לו, הוא חייב לבדוק בחומר מקצועי או להתייעץ עם אנשי מקצוע. זה נוגע למקצועיות של המתרגם, בין אם הוא מתרגם ממשק של תוכנה, סרט טלוויזיה או שירה. אז הבנו שאנחנו מסכימים כאן.
דבר נוסף חשוב מאוד, תרגום צריך לעבור עריכה ותרגום ממשק חייב לעבור אבטחת איכות (QA), דבר שלמרבה הצער לא כולם מקפידים עליו.
לגבי תיעוד המשמעות, אני לא מצפה מהאדם שקובע את הפונקציונליות והכיתוב של ממשק המשתמש (בין אם זה מתכנת, מעצב ממשק או כל איש מקצוע אחר) לדעת את שפת היעד, כי יכולות להיות עשרות ומאות שפות יעד (המוצרים של מיקרוסופט מתורגמים למאות שפות). אני לא מצפה שידע איך אומרים Browser ב- 250 שפות. אני כן מצפה שידע את שפת המקור כמו שצריך ושידע לכתוב תיאור פונקציונלי קצר בשפת המקור.
לדוגמה, נאמר שיש לי מחרוזת "Open". זה יכול להיות תפריט שפותח תיבת דו-שיח לפתיחת קובץ, זה יכול להיות לחצן באותה תיבת דו-שיח שממש פותח את הקובץ שנבחר, או זה יכול להיות בכלל סטטוס של קובץ, בהתאם התרגום לעברית יהיה:
פתיחה
פתח
פתוח
כמתרגם, הייתי רוצה לקבל תיאור קצר ליד המחרוזת:
menu item for accessing the Open dialog box
a button that opens the selected file
a label describing the file status
דבר נוסף שהייתי מצפה הוא שהאנשים שקובעים את הפונקציונליות והכיתוב של ממשק המשתמש יקבלו הכשרה בסיסית בנוגע לשפות. שיבינו דברים כמו שלשפות שונות יש מבנה משפט שונה (ותתפלא, מסתבר שלא כולם מבינים את זה).
כמובן שהמצב האידיאלי הוא שבצוות הפיתוח יהיה גם מתרגם/לשונאי שייתן את ה- input שלו לגבי נקודות שעשויות להיות בעייתיות. בכלל, כיום המגמה היא שלוקליזציה של מוצר מתבצעת במקביל לפיתוח שלו כדי לקצר למינימום את הזמן בין שחרור הגרסה המקורית לשחרור הגרסאות המקומיות (על הנושא הזה אני מתכוון לכתוב בקרוב) דבר שמחייב עבודה צמודה עם צוות הלוקליזציה.
תודה, יוסי. עכשיו הכוונה הובהרה. מעולם לא ראיתי צוות פיתוח שכותב הסברים ליד המחרוזות לתרגום כמו שהצגת ("menu item for accessing the Open dialog box"), אבל יכול להיות שזה פשוט המזל הגרוע שלי… נראה שזה בהחלט יכול לעזור למתרגם לעשות את העבודה שלו כמו שצריך. תחושת הבטן שלי היא שבד"כ הזמנים כל-כך לחוצים, שלא מגיעים לזה. אני יכול בקלות לשמוע את מנהל הפיתוח אומר "העיקר שיעבוד, הם כבר יסתדרו"…
לגבי הכשרה בסיסית לשפות, אני מסכים איתך לגמרי. בוודאי שזה נכון כשמדברים על מוצר שמיועד לקהל רב-לשוני. קשיים רבים מתעוררים בלוקליזציה: מבנה משפט אחר שמשפיע במיוחד על הודעות דינאמיות, שנבנות מכמה מחרוזות; טקסט באורך משתנה; שמות שמקבלים משמעות אחרת כמו pajero, הג'יפ, בסלנג בספרדית יש לו משמעות אחרת, או למשל iPlotz (מוצר לעיצוב ממשק)- תנסה לכתוב את זה בעברית :-) ויש גם דברים שלא קשורים ישירות בשפה, כמו תרבות שונה שמשפיעה על העיצוב הגרפי. אני בטוח שיש עוד.
אשמח לראות את המאמרים הבאים שלך בבלוג, הוספתי אותך לרשימת ה-RSS שלי ("ריססתי אותך").
ומשהו אחר, תרגיש חופשי לקחת את הדוגמה הזו אם וכאשר תכתוב פוסט על לוקליזציה:
ראיתי דוגמה מצויינת לתרגום דיבוב בסרט "צ'רלי והשוקולדה", כשג'וני דפ אומר כווילי וונקה:
(כבר שכחתי את ההקשר, אבל מצאתי בגוגל):
No, I wouldn't allow it. The taste would be terrible. Can you imagine Augustus-flavoured chocolate-coated Gloop? Ew. No-one would buy it.
בעברית דרור קרן מדבב: "…(בלה בלה בלה)………אוווו. לא אצלי בבית!"
עבודת תרגום מצויינת המתאימה עצמה לתנועות השפתיים של השחקן בסיום המשפט.
היו עוד כמה כאלו בסרט הזה אבל זו הכי בלטה לעיני ואני זוכר אותה… אפילו כששכחתי את ההקשר, כאמור :-)
תודה, מוטי, זה מזכיר את סידרת המשפטים שעוזרים ללמוד עברית שמישהו שלח לי במייל פעם (להקריא בקול אם זה לא ברור)
This is a nice house, I think I'll buy it
Oh hell, we forgot the tent
The fork fell on ma's leg
והיו עוד כמה דביליים כאלה :-)
אמנם כבר קראתי את המאמר פעם אבל יצא לי להכנס אליו שוב עכשיו.
יצא לי לאחרונה לדון עם מישהו על "מה יותר נח לקריאה" בקוד:
window.open מול open(window) (מבחינת קריאה, לא מבחינת המחשב)
בנוסף יש: "חתול.ילל" מול "חתול.שטוף" – נושא.נשוא מול מושא.נשוא.
לדעתי בכל מקרה עדיף קודם את האובייקט ואז את הפעולה.
אבל נגיד בwindow.open יש שאלה האם הכוונה לפתוח את החלון או לגרום לחלון לפתוח משהו (בדרך כלל זה מובן מצורת הכתיבה – יהיה כתוב את מה לפתוח).
לדעתכם, האם לאנשים שדוברים שפה מסויימת יש העדפה לשיטה מסויימת?
[ שלח תגובה או תגובה, שלח! ]
=תגובה מבולגנת על פוסט ישן=