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

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

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

קחו לדוגמה את המקרה הבא. התרגום לפולנית של “Low battery” רחב ב־65% מהגרסה באנגלית. ללא מספיק מקום, התרגום עלול לגלוש, להיחתך או לדחוק רכיבים אחרים ממקומם.

אנגליתLow battery122 px

פולניתNiski poziom baterii207 px

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

אנגליתNew message120 px

סינית新消息63 px

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

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

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

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

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

1. דמו תרגומים ארוכים לפני ההפצה

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

לדוגמה, אם אתם מפתחים תבנית או תוסף ל־WordPress, תוכלו להשתמש בכלי תרגום הדמה שלנו:

צפו בכלי תרגום הדמה שלנו ב־GitHub

הוא לוקח קובץ .po קיים, מרחיב את המחרוזות המתורגמות במקדם קבוע, ומייצר קובץ .po וקובץ .mo חדשים לבדיקה. כברירת מחדל, הוא מגדיל את האורך פי 1.5, אך תוכלו להתאים זאת לצרכים שלכם.

2. בדקו ידנית את ממשק המשתמש הגרפי של התוכנה שלכם לאיתור רגישויות בפריסה

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

נווטו בין מסכים שונים וחפשו את השיבושים הנפוצים הבאים:

טקסט חתוך

טקסט מסוים עלול להיעלם או לא להיות מוצג במלואו.

רכיבים חופפים

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

פריסות לא מיושרות

תרגומים ארוכים יותר עלולים לדחוק רכיבים ממקומם.

טקסט בלתי קריא

רכיבי ממשק מסוימים עלולים לכווץ או לדחוס טקסט.

ריווח לא אחיד

תרגומים קצרים עלולים ליצור רווחים מוגזמים.

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

3. התאימו את הפריסה כך שתהיה גמישה

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

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

השתמשו ברכיבים בעלי התאמת גודל אוטומטית

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

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

button {
  display: inline-block; /* Static display */
  width: 150px; /* Fixed width */
  height: 40px; /* Fixed height */
  padding: 10px; /* Fixed padding */
  font-size: 14px; /* Fixed font size */
  …
}

button {
  display: inline-flex; /* Use flexbox for alignment */
  align-items: center; /* Center content vertically */
  justify-content: center; /* Center content horizontally */
  padding: 0.75em 1.5em; /* Relative padding for scalability */
  font-size: 1rem; /* Relative font size */
  …
}

אפשרו גלישת טקסט

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

חלונית הגדרות עם התווית “Battery Percentage” באנגלית עשויה להפוך ל־“Prozentanzeige für Batterie” בגרמנית, מה שלא ייכנס בשורה אחת.

.nav-item {
  white-space: nowrap;
}

.nav-item {
  white-space: normal;
  word-wrap: break-word;
}

הימנעו ממכלים בעלי רוחב קבוע

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

.sidebar {
  width: 250px;
}

.sidebar {
  min-width: 250px;
  max-width: 40%;
}

השתמשו בריווח יחסי

ריפוד ושוליים (padding ו־margins) קבועים עלולים לגרום לחוסר יישור כאשר הטקסט מתרחב. שימוש באחוזים מבטיח שהריווח יישאר פרופורציונלי. טופס התחברות עם השדות “Username” ו־“Password” עשוי להיראות מצוין באנגלית, אך להפוך ללא מאוזן בצרפתית (“Nom d’utilisateur”).

label {
  margin-right: 20px;
}

label {
  margin-right: 5%;
}

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

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

• תפריטי ניווט
• כפתורים, תוויות או הסברים צצים (tooltips) קטנים
• רכיבים בעלי רוחב קבוע
• שרשור מחרוזות

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

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

כיצד PTC עוזרת לכם לאתר בעיות פריסה

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

שליטה במגבלות אורך התרגום

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

• פולנית → מגבלת אורך כברירת מחדל: 120%
• גרמנית → מגבלת אורך כברירת מחדל: 130%

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

בגישה זו, אתם:

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

סקירת תרגום בהקשר עם AI Visual QA

מגבלות אורך עוזרות. אבל הן לא מאתרות הכול.

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

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

AI Visual QA מבצע את הסקירה הזו עבורכם. שלחו צילומי מסך של ממשק המשתמש המתורגם שלכם, ו־PTC תבחן כל מסך באופן חזותי, בדיוק כפי שסוקר QA היה עושה.

מה אתם מקבלים:

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

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

שמרו על ממשק המשתמש שלכם מוכן לכל שפה

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

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

אל תתנו לתרגומים ארוכים לשבש את הממשק שלכם

התחילו את תקופת הניסיון שלכם ב־PTC ותרגמו עד 20,000 מילים ל־2 שפות. ודאו שכל תרגום נכנס למקומו בתוכנה שלכם.