לוקליזציה ובינאום

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

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

לוקליזציה:

לוקליזציה (Localization , או בעברית הַמְקָמָה), משמעה להפוך למקומי, לדבר בשפת המקום, להיראות ולהתנהג בהתאם. ארגון GALA (Globalization and Localization Association) מגדיר לוקליזציה כתהליך התאמת מוצר או תוכן לשפה או שוק מסוימים (GALA Globalization & Localization Association. “What is Localization?” 2017. Web. 2017). בתעשיית התרגום, ניתן לחלק את התהליך לארבעה שלבים בסיסיים:

שלב ראשון: הכנת הטקסטים לתרגום

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

שלב שני: תרגום ועריכת הטקסטים

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

שלב שלישי: הטמעת הטקסטים המתורגמים במערכת

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

שלב רביעי: בדיקת התרגומים המוטמעים

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

ארגון GALA מונה היבטים נוספים הכוללים:

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

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

בינאום:

בִּנְאוּם, או בלעז Internationalization, משמעו להפוך לבין-לאומי, להיות מסוגל לדבר במגוון שפות ולהתאים ארצות שונות. ארגון GALA מגדיר בינאום כתהליך המבטיח שמוצר (לרוב תוכנה) יוכל להתאים למגוון שפות ואזורים מבלי לשנות את קוד המקור (GALA Globalization & Localization Association. “What is Internationalization?” 2017. Web. 2017). חשבו על בינאום כהכנה ללוקליזציה. בינאום יכול לחסוך המון הוצאות, זמן וכאבי ראש לכל המעורבים. תהליך הבינאום נולד מהדרישה הגוברת למוצרים ותוכנות רב-לשוניים. התהליך דורש התחשבות בכל השווקים אליהם מכוון המוצר, והכנסת ההתאמות הדרושות כבר בשלבי עיצוב המוצר ופיתוחו.

לבינאום יתרונות רבים, ביניהם:

התאמה קלה יותר של תוכנות (או כל תוכן אחר) לשפות מרובות

קיצור הזמנים והפחתת העלויות של לוקליזציה

קוד מקור אחד, מוכן ללוקליזציה, לכל גרסאות המוצר

תחזוקה פשוטה יותר

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

אי-תלות בקידוד שפה/תווים מסוימים

אי-תלות במוסכמות תרבויות מסוימות

העדר טקסט שמקודד בקוד מקור (hard-coded)

צמצום, עד כדי ביטול כליל של מחרוזות טקסט משורשרות

שימוש נבון במשתנים כחלק מהטקסט

תאימות טובה יותר לתוספים ותוכנות אחרות

תאימות יוניקוד לתצוגת טקסט בינלאומית

התאמה לשפות סיבית-כפולה (double-byte) כגון יפנית

קל לראות כמה קשה ורצוף בעיות יהיה תהליך לוקליזציה אם היבטי בינאום אלו לא ייושמו כהלכה.

לוקליזציה, בינאום וחוויית המשתמש:

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

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

במחקר שערכה חברת Common Sense Advisory, שכלל למעלה מ-2,000 משתמשים בשמונה מדינות שונות ובחן כיצד שפה משפיעה על התנהגויות הרכישה שלהם, הממצאים היו מוחצים (Donald A. DePalma, Benjamin B. Sargent, Renato S. Beninatto. “Can't Read, Won't Buy: Why Language Matters on Global Websites” Common Sense):

• 72.4% מהמשתמשים השיבו שהם יעדיפו לרכוש מוצר עם מידע בשפתם
• 72.1% מהמשתמשים מבלים את רוב או את כל זמנם באתרים בשפתם
• 56.2% מהמשתמשים השיבו שהיכולת להשיג מידע בשפתם חשובה יותר מהמחיר
• סקר שביצעה גאלופ, ושנערך בין משתמשים ב-23 מדינות האיחוד האירופי הציג תוצאות דומות להפליא (The Gallup Organization. “User language preferences online”. European Commission. May 2011. Web. 2017):
• תשעה מתוך עשרה משתמשים השיבו שכאשר יש בחירה בין שפות באתר, הם תמיד יעדיפו לבקר באתר הדובר את שפתם
• 42% מהמשתמשים השיבו שהם לעולם לא ירכשו מוצרים ושירותים בשפות אחרות
• כמעט אחד מתוך חמישה משתמשים (19%) השיבו שהם לעולם לא גולשים לאתרים שאינם בשפתם

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

האם אי פעם פתחתם את האתר של המתחרה הכי גדול שלכם ובדקתם כמה שפות יש להם באתר? אם לא, מומלץ מאוד שתעשו זאת.

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

האתגרים בתחום הבדיקות בעולם התרגום:

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

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

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

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

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

בעיות קידוד ייפתרו על ידי שמירת הקבצים המתורגמים בקידוד אוניברסלי (UTF-8). רוב, אם לא כל כלי התרגומים המקצועיים תומכים כיום בייצוא קבצים מתורגמים בקידוד המתאים.

בעיות אי-תאימות לכללי המבנה בקובץ ייפתרו בבדיקות בכלים אוטומטיים (ולידטורים) שמאתרים שגיאות בתוכן הקובץ למול הסטנדרטים של סוג הקובץ. מרבית ספקיות כלי התרגום מציעות בדיקות כאלה כחלק מסט היכולות בתוכנת התרגום, וכן ניתן גם לבצע בדיקות אלו במגוון אתרים ייעודיים (אתרים כגון / https://codebeautify.org מציעים מגוון כלי בדיקה לסוגים שונים של קבצים. דוגמאות נוספות כוללות אתרים ייעודיים כגון / https://jsonlint.com לבדיקת קובצי json , וכן / https://www.jslint.com לבדיקת קובצי js.).

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

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

1. מה לבדוק בתוכנה המתורגמת?

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

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

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

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

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

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

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

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

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

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

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

האם משתנים שהוגדרו לתרגום לא משבשים את פעולתה התקינה של התוכנה? לדוגמה המשתנה 'משתמש' [user] שיכול לשמש הן כטקסט והן כמשתנה, תרגומו יכול לשבש את התוכנה בתפקודו כמשתנה.

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

2. כיצד לבדוק את כל הטקסטים המתורגמים?

ההחלטה כיצד לבדוק את התרגומים במערכת מוכתבת על ידי הסעיף הראשון – מה לבדוק:

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

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

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

2) אם הקמת סביבה לבדיקה דורשת מאמץ גדול מדי מצד הלקוח, בדרך-כלל יוצע לשלוח מתרגמים אל בית הלקוח, שם תהיה להם גישה לסביבת בדיקה, או שהלקוח ייצר בעצמו צילומי מסך של המסכים המתורגמים שברצונו לבדוק.

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

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

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

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

ישנן מערכות, כגון Applitools Eyes המספקות כלים לבדיקת פריסת הטקסט – מקור מול תרגום; ובסבבי עדכון בין תרגומים של שתי גרסאות שונות. כאשר התרגום של הגרסה הראשונה נבדק, אושר, ויצא לעולם, הוא יכול לשמש כ-baseline לבדיקות של הגרסאות הבאות שיתורגמו. ל-AppliTools יש גם את היכולת להריץ את אותן הרחבות של פסאודו-תרגום, ולפתור בעיות פריסה כבר בשלב הפיתוח. כלים נוספים כגון Perfecto Mobile, ו-Sauce Labs שניתן להריץ בהם תסריטי בדיקות במקביל על המערכות המתורגמות לכל השפות, ויפיקו צילומי מסך או סרטונים של תסריט הבדיקה, שישלחו לחברת התרגום לבדיקה. במעבר לכלים המשמשים את עולם הבדיקות, תחום בדיקות התרגום יהיה מסוגל לעמוד בקצב של תהליכי פיתוח ובדיקה אג'ילים שכל כך חיוניים בשוק הטכנולוגיה התחרותי והמהיר.

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

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

המאמר פורסם במגזין "עולם הבדיקות" גיליון מס' 10, 2017.

אודות הכותב צביקה גורדון:

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

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

נשוי ואב לשניים.

Liraz Postan

Translate now