10 טעויות i18n נפוצות ואיך להימנע מהן
למדו את הטעויות i18n הנפוצות ביותר שאנשי פיתוח עושים ואיך למנוע אותן. שפרו את איכות הלוקליזציה של האפליקציה שלכם באמצעות הטכניקות הטובות ביותר.
Internationalisierung (i18n) נראית פשוטה — עד שאתה מגלה שהמשתמשים הגרמנים שלך רואים לחצנים חתוכים, שהמשתמשים היפניים שלך מקבלים משפטים מעוותים והמשתמשים הדוברי ערבית שלך נתקלים בעיצובים שבורים לחלוטין. אלו אינן מקרי קצה. אלה התוצאות הצפויות של טעויות נפוצות שמרבית צוותי הפיתוח עושים כאשר הם ניגשים לראשונה ללוקליזציה. במדריך זה נפרט את 10 השגיאות הנפוצות ביותר ב-i18n, נסביר מדוע הן קורות, ונראה לך צעד-א-צעד איך לתקן כל אחת מהן. בין אם אתה בונה אפליקציה חדשה או משדרג קיימת — להימנע מן המכשולים הללו יחסוך לך שבועות debugging.
טעות #1: מחרוזות מוקשות בקוד
הקלדת מחרוזות ישירות בקוד היא הטעות הבסיסית ביותר ב-i18n. זה קורה כאשר המפתחים מתמקדים תחילה בהפעלת תכונות ומתכננים 'לסדר זאת מאוחר יותר'. אך מאוחר יותר לעולם לא מגיע, ולפתע יש לך אלפי מחרוזות מפוזרות על פני מאות קבצים.
['הגדר את מערכת i18n שלך לפני כתיבת שורת UI הקוד הראשונה', 'השתמש בתוסף lint כדי לזהות מחרוזות קשיחות בתבניות וברכיבים', 'החזק מפתחות תרגום תיאוריים ומאורגנים לפי תכונה או דף']
הגדר את מסגרת i18n שלך לפני כתיבת שורת UI הראשונה.
השתמש בתוסף Linter כדי לזהות מחרוזות hard-coded בתבניות וברכיבים.
הקפד שמפתחות התרגום יהיו תיאורים ומסודרים לפי תכונה או לפי עמוד.
תרחיש טיפוסי
מפתח כותב תווית כפתור ישירות ב-JSX: <button>Submit Order</button>.
האפליקציה משוחררת באנגלית ועובדת היטב. שש חודשים מאוחר יותר החברה מתרחבת לגרמניה.
צוות הלוקליזציה מגלה 2.000+ hardcodierte Strings. הה Nachrüstung dauert 3 Wochen und verursacht 47 Bugs.
מדוע זה בעיה
בקוד בשלבי ראוי, מחרוזות קשיחות יכולה להגיע לאלפים. חילוץ שלהן מאוחר דורש לגעת בכל קובץ, כל רכיב יידרש לבחון מחדש וייתכן שייתרחשו Regression-ים בכל מקום.
מחרוזות קשיחות נמצאות ישירות בקוד המקור, בתבניות או ברכיבים. לא ניתן לחלץ, לתרגם או להחליף אותן בזמן הריצה ללא שינוי בקוד עצמו.
משתמשים Locale שאינם אנגלים רואים רכיבי UI שלא תורגמו מעורבים בתוכן מתורגם — מראה מבולגן ולא מקצועי.
כך תפתור את זה
העבר את כל המחרוזות שנראות למשתמש מראש לקבצי משאבים.
הקם מסגרת תרגום (למשל next-intl, react-i18next, vue-i18n), לפני שאתה כותב את הרכיב הראשון שלך.
צור תבנית קבצי משאבים (למשל messages/de.json) והפני את כל המחרוזות באמצעות מפתחות תרגום כמו t('checkout.submitButton').
הוסף כלל linting או hook לפני הקומיט שמסמן מחרוזות-טקסט גולמיות ברכיבי UI.
שגיאה מס' 10: לתרגם הכל מילולית.
לא כל התוכן צריך להתורגם. שמות מותגים, שמות ישויות משפטיות, מונחים טכניים ושמות מוצרים מסוימים חייבים בהישאר בשפתם המקורית. תרגום יתר על המידה עלול לגרום לבעיות משפטיות, חוסר עקביות במותג ובלבול משתמשים.
["שמור מילון 'לא לתרגם' והעבר אותו עם כל המתרגמים", "השתמש בקטעים נעולים או ב-Namespaces נפרדים למותגים וזכויות", "הצע תמיד הערות הקשר עבור מחרוזות בעלות משמעויות מרובות כדי למנוע תרגומים שגויים"]
הפעל את מילון 'לא לתרגם' במערכת הניטור שלך למעקב.
השתמש בקטעי-מנע או ב-Namespaces נפרדים עבור מונחי מותג וזכויות.
הצע תמיד הערות הקשר עבור מחרוזות בעלות משמעות כפולה כדי למנוע תרגומים שגויים.
Ein typisches Szenario
קובץ תרגום מכיל את שם החברה 'CloudForge Inc.' ואת המונח הטכני 'OAuth 2.0 Token' כטקסטים שניתן לתרגם.
המתרגם הספרדי תרגם את 'CloudForge' ל‑'ForjaNube' ואת 'OAuth 2.0 Token' ל‑'ficha OAuth 2.0'.
תוצאה: המשתמשים לא מוצאים את החברה בשמה האמיתי, והמתכנתים שקוראים את התיעוד הספרדי מבולבלים ממונחים מקצועיים מתורגמים שאינם מוכרים.
מדוע זה בעיה
שם מותג שגוי במסמך משפטי יכול להפוך הסכם ללא תוקף. תיקון תרגומים יתר מצריך בדיקה של כל מחרוזת בכל שפה — עבודה שנמשכת שבועות.
כאשר כל הסטרינגים נשלחים לתרגום ללא הקשר, ייתכן שמתרגמים יתרגמו שמות מותגים ('Apple' → 'Apfel'), מונחים משפטיים ('GmbH' → 'LLC') או מזהי טכניים שצריכים להישאר באנגלית.
משתמשים לא מוצאים מוצרים תחת שם המותג המוכר להם, מסמכי משפט referencieren את החברה הלא נכונה, ותיעוד טכני נהיה לבלבול כאשר מונחים כמו 'API Endpoint' מתורגמים.
איך לתקן את זה
סמן בבירור תכנים שאינם ניתנים לתרגום והצע הערות הקשר למתרגמים.
צור Glossar של 'לא לתרגם' המכיל את כל שמות המותגים, שמות המוצרים, ישויות משפטיות ומונחים מקצועיים שעליהם להישאר ללא שינוי.
השתמש בשם מרחב נפרד (namespace) או מפתחות מיוחדים עבור תוכן שאינו ניתן לתרגום. רבים מכלי i18n תומכים בקטעים נעולים שאינם ניתנים לעריכה על ידי המתרגמים.
הוסף הערות/הסברים לקבצי התרגום שלך שמסבירים את ההקשר: 'זה שם מותג — לא לתרגם' או 'מונח — להשאיר באנגלית'.
טעות #2: צירוף מחרוזות
חיבור משפטים ממקטעים נראים הגיוני באנגלית, אך לא כך בתרבות שפות שונות. סדר המילים, הדקדוק ומבני המשפט משתנים בצורה משמעותית בין שפות, מה שהופך מחרוזות מחוברות לבלתי ניתנות לתרגום.
['לעולם אל תבנה משפטים על ידי חיבור של חלקי תרגום', 'השתמש בתבניות עם שמות ('{name}') במקום מיקום ({0}) לבהירות', 'ספק הערות הקשר למתרגמים שמסבירות מה מכיל כל תבנית']
אל תבנה משפטים באמצעות צירוף חלקי תרגום.
השתמש בתבניות עם שמות ('{name}') במקום מיקום ({0}) לבהירות
הצע הערות הקשר למתרגמים שמסבירות מה מכיל כל תחליף
תסריט טיפוסי
מפתח כותב: 'You have ' + count + ' items in your ' + cartType + ' cart' — זה פועל בצורה מושלמת באנגלית.
המתרגם הגרמני מקבל שלושה חלקים נפרדים ואינו יכול ליצור משפט דקדוקי תקין, כי סדר המילים צריך להשתנות.
תוצאה: משתמשים גרמנים רואים 'Sie haben 5 Artikel in Ihrem Warenkorb Standard' — לא זורם ולא מקצועי.
מדוע זה בעיה
כל מחרוזת קשורה היא פצצה מתקתקת. ב-20 שפות וב-50 מחרוזות קשורות יש לך 1,000 טעויות דקדוק פוטנציאליות שיש לתקן ידנית.
הצמדה של מחרוזות כמו 'Willkommen ' + userName + ', du hast ' + count + ' neue Nachrichten' דורשת סדר מילים מסוים. המתרגמים יקבלו פיסות ללא הקשר שאינן ניתנות לסידור.
משתמשים רואים משפטים דקדוקיים שגויים. בגרמנית הפועל לרוב נמצא בסוף המשפט. בערבית המבנה כולו הופך. התוצאה נראית כמו שטות.
כיצד לתקן זאת
השתמש בהודעות ממודלות עם תחליפים מסומנים כדי שמתרגמים יוכלו לשנות את כל המשפט.
החלף חיבור של חלקי תרגום במפתח הודעה אחד עם תבניות: 'cart.summary': 'יש לך {count} פריטים בסל '{cartType}''.
העבר משתנים כפרמטרים לפונקציית התרגום שלך: t('cart.summary', { count: 5, cartType: 'Premium' }).
המתרגמים יכולים כעת לשנות חופשי: 'ב'סל '{cartType}'' שלך נמצאים {count} פריטים' — גרמנית תקינה דקדוקית.
טעות #3: הזנחת צורות הרבים
לאנגלית יש שתי צורות ריבוי: יחיד ורבים. המפתחים נוטים להניח שכל השפות פועלות באותה צורה. זה לא כך. לפולנית יש 4 צורות, לערבית יש 6, ואפילו שפות כמו הצרפתית מתייחסות לאפס בצורה שונה מאנגלית.
['השתמש תמיד ב-ICU MessageFormat או בספרייה תואמת עבור תוכן שניתן לספור', 'אל תכתוב מעולם לוגיקת צורות רבים משלך — סמוך על כללי CLDR', 'בדוק צורות רבות עם ערכים כמו 0, 1, 2, 5, 21 ו-100 כדי לכסות את כל הקטגוריות']
השתמש תמיד ב-ICU MessageFormat או בספרייה המקבילה עבור תוכן שניתן לספור
אל תכתוב לעולם לוגיקת רבים משלך — סמוך על כללי CLDR
בדוק צורות רבים עם ערכים כמו 0, 1, 2, 5, 21 ו-100 כדי לכסות את כל הקטגוריות.
תסריט טיפוסי
מפתח כותב: count + (count === 1 ? ' Datei' : ' Dateien') — נכון לייד גרמנית.
המתרגם הפולני צריך 4 צורות: 1 plik, 2-4 pliki, 5-21 plików, 22-24 pliki. הטרינרי הפשוט לא יכול לבטא זאת.
תוצאה: משתמשים פולניים רואים '5 pliki' (צורה שגויה) במקום '5 plików' (צורה נכונה), והאפליקציה נראית מקולקלת.
למה זה בעיה
כל שם עצם שניתן לספור באפליקציה שלך דורש טיפול בקטגוריות הריבוי. עם 50 מחרוזות כאלה ו-20 שפות זה 1,000 כללי ריבוי — בלתי אפשרי לנהל ידנית.
בדיקות if/else פשוטות (count === 1 ? 'Datei' : 'Dateien') מטפלות רק בגרמנית/אנגלית. CLDR מגדיר עד שש קטגוריות רבות: zero, one, two, few, many ו-other. כל שפה משתמשת בקבוצת תתי-קטגוריות שונה.
משתמשים רואים טקסטים דקדוקים שגויים כמו '1 Nachrichten' או צורות רבים שגויות לחלוטין. בהקשרים רשמיים זה מפגע באמינות.
כיצד לתקן זאת
השתמש ב-ICU MessageFormat שממילא תומך בכללי הריבוי של CLDR.
הגדר הודעות עם תחביר ICU: 'fileCount': '{count, plural, one {# Datei} other {# Dateien}}'.
המתרגמים מספקים את כל צורות הריבוי הדרושות לשפתם. פולנית: '{count, plural, one {# plik} few {# pliki} many {# plików} other {# pliku}}'.
הספרייה i18n שלך בוחרת באופן אוטומטי את הצורה הנכונה בזמן הריצה לפי כללי CLDR של הלוקאלה הפעילה.
טעות #4: רוחבי UI קבועים
מעצבים יוצרים פריסות מדויקות בפיקסלים באנגלית, והמתכנתים מיישמים אותן ברוחבים קבועים. אך טקסט מתורגם יכול להיות משמעותית ארוך יותר או קצר יותר. הטקסט הגרמני הוא בערך 30% ארוך יותר מהאנגלית, בעוד הטקסט הסיני יכול להיות קצר יותר ב-50%.
['אל תשתמש מעולם ברוחבי פיקסל קבועים עבור אלמנטים עם טקסט שניתן לתרגם', 'תכנן הרחבת טקסט של 40% כבסיס — חלק מהשפות יתפשטו עוד יותר', 'השתמש ב-CSS Flexbox או Grid עבור פריסות שמסתגלות לאורך משתנים של תוכן']
אל תשתמש לעולם ברוחבי פיקסל קבועים עבור אלמנטים עם טקסט שניתן לתרגם.
תכנן הרחבת טקסט של 40% כקו בסיס — חלק מהשפות מתרחבות עוד יותר
השתמש ב-Flexbox או Grid של CSS עבור פריסות שמסתגלות לאורך תוכן משתנה.
תרחיש טיפוסי
המעצב יוצר סרגל ניווט עם 5 כפתורים, כל אחד ברוחב בדיוק 100px — נראה מצוין באנגלית.
תרגום גרמני: 'Settings' יהפוך ל-'Einstellungen' (13 תווים מול 8), 'Submit' יהפוך ל-'Absenden' (8 מול 6). סרגל הניווט יחרוג.
תוצאה: בטלפונים ניידים הכפתורים נערמים זה על זה או שהטקסט נחתך, מה שמפגע בניווט עבור משתמשים גרמנים.
מדוע זו בעיה
כל אלמנט עם רוחב קבוע הוא נקודת שבירה פוטנציאלית. אפליקציה טיפוסית מכילה מאות כפתורים, תוויות וכרטיסים שכולם צריכים לתמוך בהרחבת הטקסט.
מכולה ברוחב קבוע (width: 120px) וכפתורים בגודל קבוע נחתכים או חורגים כאשר הטקסט מתרחב. overflow: hidden ב-CSS מסתיר תוכן בשקט, בעוד overflow: visible משמיד את הפריסה.
המשתמשים רואים תוויות חתוכות כמו 'Einstellu...' במקום 'Einstellungen', או כפתורים שמכסים אובייקטים סמוכים. פעולות קריטיות הופכות לבלתי-קריאות או לא-ללחיצות.
כך תפתור את זה
תכנן ויישם פריסות גמישות שמסתגלות לאורך הטקסט בכל הלוקאלים.
החלף רוחבים קבועים ב-min-width, max-width ועיצובי Flex/Grid. השתמש ב-CSS Grid או Flexbox כדי לחלק את המקום בצורה דינאמית.
הפעל גבול טקסט עם שבירה: השתמש ב-overflow-wrap: break-word והימנע מ-white-space: nowrap עבור תוכן שניתן לתרגם.
בדוק את ה-UI שלך באמצעות פpseudo-Localization שמאריך את כל המחרוזות ב-40% כדי להדמות למקרה הגרוע — לפני שאתה שולח את המחרוזות למתרגים.
טעות #5: עיצוב תאריכים ומספרים
נתונים ומספרים נראים אוניברסליים לכאורה. אך 01/02/2025 משמעותו 2 בינואר בארה"ב ואת 1 בפברואר באירופה. פסיקים ונקודות מחליפים את משמעותם במספרים: 1,000.50 (USA) מול 1.000,50 (גרמניה). לעשות זאת שגוי מוביל לבלבול, שגיאות נתונים ואובדן אמון.
['השתמש מהיום הראשון אך ורק בתכונות CSS לוגיות (inline-start/end, block-start/end)', 'בדוק את האפליקציה שלך עם dir='rtl' על האלמנט HTML בכל סקירת Sprint', 'צור רשימת בדיקת RTL עבור ניווט, אייקונים, טפסים ומדדי התקדמות']
אל תעצב נתונים או מספרים ידנית באמצעות תבניות מחרוזת — השתמש תמיד ב-Intl APIs.
אחסן את כל הנתונים בפורמט ISO 8601 ובמטבעות ביחידה הקטנה ביותר (סנט) באופן פנימי.
בדוק עם לוקאלים שונים המשתמשים בתווי עשרוניים שונים, סדרי תאריכים שונים ומערכות לוח שונות.
תרחיש טיפוסי
המתכנתים מעצבים תאריך כ-MM/DD/YYYY ואת מחיר כ-$1,234.50 — נכון עבור משתמשי ארה"ב.
תרגום גרמני: 'Settings' יהפוך ל-'Einstellungen' (13 תווים מול 8), 'Submit' יהפוך ל-'Absenden' (8 מול 6). סרגל הניווט יחרוג.
תוצאה: המשתמש רוכש טיסה עבור התאריך הלא נכון ומפקפק בפורמט המחיר. כרטיסי תמיכה עולים בשוק הגרמני ב-15%.
מדוע זו בעיה
תצוגה בכל מקרה: תאריך וההצגה של המספרים. כל הצגה של נתונים באפליקציה: טבלאות, תרשימים, טפסים, חשבוניות, דוחות. תיקון גלובלי מכסה מאות מופעים.
מחרוזות פורמט קשיחים כמו toLocaleDateString('en-US') או עיצוב ידני באמצעות Template-Literals מתעלמים מה-Locales האמיתי של המשתמש. אפילו לוקאל נכון אך מערכת קלנדר שגויה (Gregorian מול Hijri) עלולה לגרום לבעיות.
המשתמשים קוראים נתונים בצורה שגויה ומזינים נתונים בפורמט לא נכון. משתמש אירופי שמוצג לו 03/04/2025 עשוי לפרש זאת כאפריל 3 במקום 4 במרץ — פגישות שהוחמצו או הזמנות שגויות.
כך תפתור את זה
השתמש ב-Intl-API המובנה או בספריית עיצובים המותאמת למקומיות עבור כל תאריכים, זמנים, מספרים ומטבעות.
החלף את העיצוב הידני באמצעות Intl.DateTimeFormat(locale) עבור תאריכים ו-Intl.NumberFormat(locale, { style: 'currency', currency }) עבור מחירים.
שמור את הנתונים בפורמט ISO 8601 (YYYY-MM-DD) באופן פנימי, ופורמט אותם להצגה בלבד לפי ה- locale של המשתמש.
בדוק הצגות תאריכים/מספרים קריטיות לפחות ב-5 מקומי שונים: en-US, de-DE, ja-JP, ar-SA ו-zh-CN, כדי לכסות את הצורות העיקריות של העיצוב.
טעות #6: שפות RTL נשכחות
שפות מימין לשמאל (RTL) כמו ערבית, עברית ופרסית משמשות מעל ל-500 מיליון אנשים. עם זאת, רוב האפליקציות מעוצבות רק עבור פריסה מימין-לשמאל (RTL). תמיכת RTL איננה רק לסובב את הטקסט — כל רכיבי ה-UI חייבים להיות משתקפים.
['השתמש מהיום הראשון אך ורק בתכונות CSS לוגיות (inline-start/end, block-start/end)', 'בדוק את האפליקציה שלך עם dir='rtl' על האלמנט HTML בכל סקירת Sprint', 'צור רשימת בדיקת RTL עבור ניווט, אייקונים, טפסים ומדדי התקדמות']
השתמש מהיום הראשון אך ורק בתכונות CSS לוגיות (inline-start/end, block-start/end).
השתמש בדיקה את האפליקציה שלך עם dir='rtl' על האלמנט HTML בכל סקירת ספרינט.
הכן רשימת בדיקות RTL עבור ניווט, אייקונים, טפסים וצגי התקדמות.
תרחיש טיפוסי
מפתח משתמש ב-margin-left: 16px וב-text-align: left לאורך כל האפליקציה — הפרקטיקה הרגילה של LTR.
האפליקציה מתחילה בערב הסעודית. החיצים 'החזרה' מצביעים קדימה, הסיידברים מופיעים בצדו של הלא נכון, והנתונים המספריים אינם מיושרים נכון.
תוצאה: משתמשים ערבים עוזבים את האפליקציה לאחר 30 שניות. הצוות זקוק ל-4 שבועות של חידוש CSS כדי לפתור את הבעיה.
מדוע זה בעיה
RTL-תמיכה נוגעת בכל רכיב באפליקציה שלך. הוספת RTL בדיעבד בדרך כלל דורשת rewrite של 30-50% מה-CSS ובדיקת כל אייקון ועיצוב.
CSS-מאפיינים כמו margin-left, padding-right, text-align: left ו-float: left מגדירים את הכיוון בקוד. אייקונים עם משמעות כיווניות (חצים, מדדי התקדמות) מצביעים לכיוון הלא נכון. אפילו ערכי border-radius חייבים להשתקף.
משתמשים ערבים רואים ניווט בפינה הלא נכונה, מדדי התקדמות זורמים לאחור, וטקסט שנוגש עם רכיבי UI. האפליקציה מרגישה זרה ולא נוחה לשימוש.
כך תפתור את זה
השתמש במאפייני CSS לוגיים ובדוק את הפריסה RTL מההתחלה.
החלף את כל מאפייני CSS הפיזיים באמצעות מקביליהם הלוגיים: margin-left → margin-inline-start, padding-right → padding-inline-end, text-align: left → text-align: start.
הגדר את המאפיין dir על האלמנט HTML-Root על בסיס Locale הפעילה. השתמש ב-CSS :dir(rtl) כדי לבצע Overrides ל-RTL.
בדוק את כל האייקונים על משמעות כיווניות. החלף אייקונים שמבוססי כיווניות בגרסה ה mirrored או השתמש ב-CSS transform: scaleX(-1) להקשרים RTL.
טעות #7: תמונות עם טקסט
הטמנת טקסט בתוך תמונות — בין אם בבאנרים, כפתורים, אינפוגרפיקות או צילומי מסך — הוא סיוט לוקליזציה. כל תמונה עם טקסט חייבת להיות מותאמת לכל שפה, מה שמגדיל עלויות עיצוב ומאחר את ההשקה.
['אל תכלול אף פעם טקסט מתורגם ישירות בתוך תמונות רסטר (PNG, JPG)', 'השתמש בשכבות טקסט ב-CSS על תמונות רקע לבאנרים-גיבור ול-CTAs', 'אוטומט את יצירת צילומי המסך עבור רשימות App Store ולעמודי שיווק']
אל תטמיע לעולם טקסט שניתן לתרגם ישירות בתוך תמונות רסטר (PNG, JPG).
השתמש בשכבות טקסט על תמונות הרקע עבור Hero-banner ו-CTAs.
אוטומציה של יצירת צילומי מסך לרשימות App Store ודפי שיווק
תרחיש טיפוסי
מעצב יוצר באנר קידום עם הטקסט 'Start Your Free Trial' המשולב ישירות בתוך התמונה.
הצוות הלוקליזציה מתרגם את כל מחרוזות ה‑UI, אך הבאנר בדף הגרמני עדיין מציג טקסט באנגלית.
תוצאה: דף הנחיתה הגרמני מכיל באנר באנגלית שמבלבל. יצירת באנרים ממודלים ל-15 שפות דורשת 3 ימים של עבודה עיצובית ועיכוב בהשקה.
מדוע זה בעיה
בעמוד שיווקי טיפוסי יש 5-10 תמונות עם טקסט. ב-15 שפות זה 75-150 וריאציות של תמונות שיש ליצור, לתחזק ולעדכן בכל שינוי עיצוב.
טקסט המובנה בתוך תמונות (PNG, JPG, SVG עם טקסט מובנה) אינו ניתן לחילוץ באמצעות כלים לתרגום. כל גרסת מקומית דורשת מהמעצב לערוך את קובץ המקור ידנית, לייצא אותו ולהעלות.
משתמשים רואים תמונות עם טקסט בשפה זרה, או גרוע מכך – תערובת של UI מתורגם ותמונות שאינן מתורגמות. זה מרגיש לא עקבי ופוגע באמון במותג.
כך תתקן את זה
הפרד טקסט מתמונות באמצעות שכבות CSS Overlay, SVG עם טקסטים מתורגמים או יצירת תמונות דינמית.
השתמש CSS כדי להניח את הטקסט המתורגם מעל תמונות רקע: מקם אותה באמצעות מיקום מוחלט מעל קונטיינר התמונה.
עבור אינפו-גרפים או תרשימים השתמש ב-SVGs עם אלמנטים <text> שמReferenzÜ Übersetzungs-Keys, במקום לשלב מחרוזות גולמליות.
התקן: צילומי מסך של אפליקציות בחומרי שיווק אוטומטיים באמצעות כלים כמו Fastlane (Mobile) או Playwright (Web), כדי לכל locale לכלול תמונות מסך.
שגיאה #8: תרגומים חסרים לא מטופלים
תרגומים אינם תמיד מלאים במהלך הפיתוח. תכונות חדשות מוסיפות מחרוזות מהר יותר מאשר המתרגמים יכולים לתרגם. ללא מערכת fallback נכונה, תרגומים חסרים גורמים לקריסות, ליישומי UI ריקים או להופעת מפתחות תרגום גולמיים שהמשתמשים רואים.
['הגדר תמיד לפחות שפת גיבוי אחת בהגדרת i18n שלך', 'הקליט מפתחות תרגום חסרים למערכת הניטור שלך למעקב', 'הגדר אחוז כיסוי תרגומים מינימלי לפני שה- locale מסוים יעלה לאוויר']
הגדר תמיד לפחות שפת חלופית בהגדרת i18n.
הפעל את הלוג של מפתחות התרגום החסרים למערכת הניטור שלך למעקב.
הגדר אחוז כיסוי תרגומי מינימלי לפני שה locale יכול להיות פעיל.
תרחיש טיפוסי
מפתחים מוסיפים אזור 'Premium Features' חדש עם 15 מפתחות תרגום חדשים. הגרסה האנגלית משודרת מייד.
התרגומים הצרפתיים עדיין לא מוכנים. הדף הצרפתי מציג מפתחות תרגום גולמיים: 'premium.feature1.title', 'premium.feature1.description'.
תוצאה: משתמשים בצרפתית רואים דף שבור מלא בשמות מפתחות מהצוות הפיתוח. צוות התמיכה מקבל עשרות דיווחי באגים.
למה זה בעיה
ככל שיתרחב האפליקציה שלך, כך יגדל הפער בין מחרוזות אנגליות לתרגומים בשפות אחרות. אפליקציה עם 100 שפות ו-2,000 מחרוזות עלולה להכיל תמיד מעל 10,000 תרגומים חסרים.
ללא לולאת fallback נכונה, מפתח תרגום חסר מחזיר undefined, null או את מחרוזת המפתח הגולמית (למשל 'checkout.confirmButton'). מנועי תבניות עלולים לזרוק שגיאות, לקרוס את הדף או לא להציג כל דבר.
משתמשים רואים UI פגום: כפתורים ריקים, תוויות חסרות או מחרוזות מסתוריות כמו 'nav.settings.title' במקום טקסט אמיתי. זה מבלבל ולא מקצועי.
כך תפתור את זה
הגדר רצף fallback חזק ומעקב אחר כיסוי התרגומים בכל הלוקאלים.
הגדר שרשרת שפות fallback בהגדרת i18n שלך: מפתחות(fr) חסרים יוחזרו אוטומטית לאנגלית(en).
הוסף מנגנון טיפול במפתחות חסרים שמקליט מפתחות שלא תורגמו למערכת המעקב שלך (למשל Sentry, Datadog) מבלי לפגוע בחוויית המשתמש.
צור לוח מחוונים לכיסוי תרגומים שמטרתו לעקוב אחר אחוז ההשלמה לכל locale ולסגור שחרורים אם הכיסוי יורד מתחת לסף מסוים (למשל 95%).
שגיאה מס' 9: בעיות קידוד תווים
בעיות קידוד תווים הן ההריגה השקטה של הלוקליזציה. הכל נראה תקין באנגלית ובשפות אירופיות, אבל ברגע שאתה מוסיף סינית, יפנית, קוריאנית, ערבית או אימוג'י, מופיעים תווים מעוותים (Mojibake). באגים אלה ידועים בכך שהם קשים לזהוי.
['השתמש בקידוד UTF-8 בכל המקומות —בקבצי המקור, במסד הנתונים, בתשובות ה-API ובתגי ה-HTML meta', 'השתמש ב utf8mb4 ב-MySQL (לא utf8) כדי לתמוך בכל טווח היוניקוד כולל אימוגי', 'בדוק עם תוכן אמיתי ב-CJK, ערבית ו-Emoji כדי לזהות בעיות קידוד מוקדם']
השתמש בקידוד UTF-8 בכל מקום — קבצי מקור, מסד נתונים, תשובות API ותגים מטא של HTML.
השתמש ב-utf8mb4 ב-MySQL (לא utf8) כדי לתמוך בכל טווח היוניקוד כולל אימוג'י.
נסה תוכן אמיתי ב-CJK, ערבית ואימוג'י כדי לאתר בעיות קידוד מוקדם.
תרחיש טיפוסי
מפתח מגדיר מסד נתונים MySQL עם latin1-Collation (התקן הישן). הקוד של App משתמש ב-UTF-8.
המשתמשים היפניים נרשמים בשם האמיתי שלהם. מסד הנתונים מאחסן '田中太郎' כבתים פגומים.
התוצאה: פרופיל המשתמש מציג טקסט מעוות. גרוע מכך: החיפוש והמיון מתפקשים עבור כל שמות ה-CJK, מה שמטריד אלפי משתמשים.
מדוע זה בעיה
בעיות קידוד מתפשטות לאורך כל הסטאק שלך. קולציית מסד הנתונים שהוגדרה שאינה נכונה יכולה לגרום נזק למיליוני רשומות — התיקון דורש מיגרציה יקרה של נתונים.
קידוד לא עקבי לאורך הסטאק — UTF-8 בקבצי המקור, Latin-1 בבסיס הנתונים ו-Windows-1252 בתגובה של ה-API — משמיד תווים מרובי-בתים. שכבת תצורה אחת שגויה יכולה להפוך '日本語' ל'????' או ל'日本èª'.
המשתמשים לא מוצאים מוצרים תחת שם המותג המוכר להם, מסמכי משפט מציינים את החברה הלא נכונה, ותיעוד טכני נהיה לבלבול כאשר מונחים כמו 'API Endpoint' מתורגמים.
כך תפתור זאת
אכוף קידוד UTF-8 עקבי בכל שלבי סטאק היישום.
הגדר את כל קבצי המקור ל-UTF-8 (הגדר את העורך שלך ואת .editorconfig). הוסף <meta charset='UTF-8'> ל-HTML שלך והגדר 'Content-Type: application/json; charset=utf-8' בתשובות API.
הגדר את מסד הנתונים שלך ל-utf8mb4 (לא רק utf8, שהוא תת-קולציה במסד הנתונים ב-MySQL). הגדר את הקולציה של החיבור ל-utf8mb4_unicode_ci.
בחר גופן-כתב המכסה את מערכות הכתב היעד שלך: לטינית, קירילי, CJK, ערבית, ודא Devanagari. השתמש ב- System Font Stacks או ב-Google Fonts עם תתי-קטגוריות לשפות כדי לטעינה אופטימלית.
בדוק את יישום ה-i18n שלך
בדיקת הארכת אורך
הרחב את כל המחרוזות המתורגמות ב‑30–40% כדי להשלים את ההרחבה הטקסטואלית שנוצרת בשפות עשירות במילים כמו גרמנית, פינית או יוונית. זה מכסה תיבות ברוחב קבוע, תוויות חתוכות וכפתורים שמפרצים לפני תחילת התרגום. רבים מכלי pseudo-lokalizacije מציעים זאת כתכונה מובנית.
"Senden" → "Ṡééééñðéñ_éxpáñðéð" (40% ארוך יותר)
pseudo-לוקליזציה
לוקליזציה מדומה מחליפה כל תו באמצעות מקביל מודגש (למשל, 'a' → 'á') ומעטיפה מחרוזות בתגים כמו [!! ו-!!]. כך נראות מיד אילו מחרוזות מובנות מראש בקוד ואילו מגיעות ממערכת התרגום. הרץ לוקליזציה מדומה כחלק מצינור ה-CI שלך כדי לזהות רגרסיות באופן אוטומטי.
כל טקסט על המסך שאינו בתוך [!! !!]-סימונים נחשב לטקסט שהוקלד בקוד וחייב להיות מחוץ לקוד. מבחן זה תופס 95% מה-stringים שלא אותרו בתוך פחות דקה.
"שלח הודעה" → "[!! Ñáçḥŕíçḥṫ ṡéñðéñ !!]"
בדיקת תצוגת RTL
גם ללא תרגומים לערבית או לעברית, תוכל לבדוק תצוגה RTL על ידי הוספת dir='rtl' לאלמנט השורש של HTML שלך. זה חושף מיד באגים כמו כיווניות CSS: יישור סמלים שגוי, מרג'ינים בצד הלא נכון, ניווט פגום ומיון לא נכון של פריטי Flex. נהג זאת לבדיקת תקן בכל סבב — זה לוקח 10 שניות להחליף וזה תופס בעיות שברוב המקרים היו דורשות שבועות כדי לתקן ב-Production.
רשימת בדיקות i18n
['העבר את כל המחרוזות שנראות למשתמש לקבצי משאבים', 'אין שימוש בהצמדת מחרוזות ליצירת משפטים', 'מומשו כללי הצורות הרבות באמצעות ICU MessageFormat או מקבילו', 'עיצוב תאריכים, זמן ומספרים באמצעות API-ים תואמי-locale', 'בדקנו תצוגת RTL עם תוכן ערבי או עברי', 'ממשק משתמש גמיש ללא רוחבי קבועים ברכיבים בעלי טקסט', 'הגדרת שפת חלופית ובדיקה שלה כאשר מפתחות חסרים', 'קידוד UTF-8 אחיד לאורך כל הקבצים ובמסדי הנתונים', 'מטא-נתונים בחנויות App Store ו-Play Store מותאמים לכל שוק', 'צילומי מסך ואלמנטים שיווקיים עבור כל שפה מעודכנים']