12 בדיקות לפני ששולחים תרגום

TABLE OF CONTENTS

התרגום כבר נראה „מוכן“. זה השער הקצר בין התחושה הזאת ללחיצה על Send—בין אם שולחים מייל ללקוח, מפרסמים טקסט מוצר, מגישים שיעורי בית או משחררים מחרוזות UI.

תרגום מכונה וטיוטות AI חוסכים זמן. הם גם משאירים סט צפוי של טעויות קו־סיום שבדיקת איות לא תתפוס: תאריך בסגנון ארה״ב שהופך את היום באירופה, שם מוצר שתורגם, מציין מיקום {name} שנשבר, או קישור שעדיין פותח את דף שפת המקור. ה־American Translators Association מדגישה שלמות, דיוק, קריאות ומעבר אחרון בפורמט המסירה האמיתי לפני שחרור. אין צורך בתוכנית לוקליזציה מלאה לשם כך—צריך שתים־עשרה בדיקות קונקרטיות שאפשר להריץ בכ־5–15 דקות.

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

איך מריצים את שער 5–15 הדקות הזה

מצב	עומק מומלץ
מייל קצר, תשובת צ׳אט, כיתוב ברשתות	5 דקות — בדיקות 1–6 + 12
דף מוצר, הצעה, חיבור לבית הספר	10 דקות — הרשימה המלאה
מחרוזות UI, טקסט חנות אפליקציות, FAQ	15 דקות — הרשימה המלאה + מיקוד במצייני מיקום/קישורים

השאירו לשונית דפדפן אחת (או חלון) על המקור ואחת על היעד. תקנו בקובץ שתשלחו באמת—לא רק בטיוטת צ׳אט.

1. תאריכים וסדר לוקאלי

ודאו שכל תאריך תואם את הלוקאל של הקורא, לא את שלכם.

אנגלית ארה״ב משתמשת לעיתים קרובות ב־חודש–יום–שנה (11/01/2026 = 1 בנובמבר).
חלק גדול מאירופה ומאמריקה הלטינית משתמש ב־יום–חודש–שנה (01/11/2026 = 1 בנובמבר).
לוקאלים רבים במזרח אסיה מעדיפים שנה–חודש–יום.

Unicode CLDR מתעד דפוסי תאריך לוקאליים בדיוק מסיבה זו: תאריכים מספריים קצרים מעורפלים מעבר לגבולות. העדיפו צורה חד־משמעית לקהל מעורב (1 November 2026 או ISO 2026-11-01) כשהערוץ מאפשר. בדקו גם אם יום השבוע עדיין תואם אחרי שינוי הפורמט.

2. טקסט בשפת המקור שנשאר

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

כותרות, כיתובי תמונה, alt text, הערות שוליים, כותרות עליונות/תחתונות
טקסט בתוך טבלאות, תיבות טקסט, הערות דובר או שכבות על תמונה
ביטויי stub שנותרו בשפת המקור (TBD, lorem, TODO, N/A שיש ללוקליזציה)

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

3. שמות ופריטי do-not-translate (DNT)

הגנו על פריטים שצריכים להישאר כפי שהם אלא אם הבריף אומר אחרת:

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

בנו רשימת DNT קטנה לפני התרגום—גם חמישה מונחים עוזרים. למידע על מה שבדרך כלל לא צריך להחליף שפה, ראו What Not to Translate.

4. סמלי מטבע ומפרידי מספרים

מספרים אינם „אוניברסליים“. דפוסי מספר ומטבע של CLDR מתייחסים ל־. ול־, כאל מצייני מיקום שהופכים לסמלים ספציפיים ללוקאל.

הרגל לוקאל	משמעות לדוגמה של `1.500` / `1,500`
en-US	`1,500.00` → אלף וחמש מאות
de-DE / רבים ב־EU	`1.500,00` → אלף וחמש מאות
טיוטות מעורבות	`1.500` יכול להיות 1.5 או 1500—אסון בהצעת מחיר

בדקו קוד מול סמל מטבע (USD / $ / US$), מיקום הסמל ומקומות עשרוניים (ל־JPY לעיתים אין). לעולם אל תשנו את הערך המספרי תוך „תיקון“ מפרידים.

5. טון ומשלב

שאלו: האם זה יישמע נכון משולח זה לקורא זה בערוץ זה?

Cambridge Grammar מגדיר register כסוגי שפה למטרות, הקשרים וקהלים שונים—ומבחין בין שפה פורמלית (מצבים רציניים, אנשים שאינכם מכירים היטב) לשפה לא־פורמלית (הקשרים רגועים ומוכרים). טיוטת AI פטפטנית במייל ראשון ללקוח, או טון ספר לימוד נוקשה בטיפ אונבורדינג באפליקציה, שתיהן נכשלות בשער השליחה.

מבחן מהיר: קראו את הברכה, פסקת גוף אחת ואת החתימה. אם רמת הפורמליות אינה תואמת, תקנו את אי־ההתאמה. לדפוסי טון בין־לשוניים ראו Formal vs Informal: 12 Tone Tips.

6. מצייני מיקום ומשתנים

חפשו ביעד מצייני מיקום שבורים או מתורגמים:

{name}, {{count}}, %s, %1$s, ${user}
בלוקים בסגנון ICU / MessageFormat {count, plural, ...}

W3C internationalization guidance on composite messages מזהירה שמשתנים חייבים להישאר שלמים וניתנים לסידור מחדש; מתרגמים (ו־AI) לא צריכים „לעזור“ ולתרגם את הטוקן או לקבע סדר מילים באנגלית. השוו מספר ושמות של מצייני מיקום למחרוזת המקור. אם ה־UI מציג מילולית Hello, {name}!, עדיין לא סיימתם.

7. קישורים שעדיין מצביעים ל־URL בשפת המקור

לחצו—או לפחות ריחפו ובדקו—כל קישור חשוב:

האם /en/ או ?lang=en עדיין מופיעים כשהדף אמור להיות בספרדית?
האם כתובות מרכז העזרה והתמחור מובילות למקבילות בלוקאל היעד?
האם פרמטרי מעקב או UTM שלמים, והיעד חי (לא 404)?

משפט מושלם ששולח קוראים לדף בשפה הלא־נכונה עדיין נכשל בשער השליחה.

8. מספרים, יחידות ומדידות

מעבר למפרידי מטבע, אמתו:

יחידות שנשמרו או הומרו לפי הבריף (km מול mi, °C מול °F)
מספרי טלפון, מיקודים ושעות (12 שעות מול 24 שעות)
אחוזים וטווחים (10–15%) שעדיין תואמים לערכי המקור

אם הבריף אומר „אל תמירו יחידות“, השאירו אותן ולוקליזו רק את הניסוח סביבן.

9. עקביות מילון מונחים ושם מוצר

חפשו ביעד כל מונח מילון מונחים נדרש. אשרו:

המונח המועדף משמש בכל פעם (בלי גלישת מילים נרדפות)
מונחים אסורים או ישנים לא חוזרים
רישיות תואמת כללי מותג (OpenL, לא Openl)

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

10. שלמות מול המקור (ספירת תבליטים וסעיפים)

עשו ספירה מבנית, לא רק תחושת בטן:

אותו מספר סעיפי H2/H3?
אותו אורך רשימת תבליטים או ממוספרת?
טבלאות: אותו מספר שורות/עמודות? כיתובי תמונה קיימים?

בדיקת השלמות של ATA ישירה: דלגו על מילה קטנה כמו „no“ והמשמעות מתהפכת. ספירת פריטי רשימה תופסת השמטות שקריאה שוטפת מפספסת. למעבר מסמך דו־לשוני מלא השתמשו ב־The Bilingual Document Review Checklist.

11. עיצוב וגלישת אורך

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

כפתורים, תוויות תפריט, כותרות שקופיות, שורות נושא במייל
תאי טבלה, UI לנייד, תיבות טקסט ב־PDF

בדקו בגודל אמיתי (זום 100% / תצוגה מקדימה במכשיר). שימו לב למחרוזות חתוכות, טקסט חופף, שבירות שורה שבורות וגופנים שאינם תומכים בכתב היעד. אם תרגמתם שקופיות או מצגות, עברו גם על PPTX Translation QA Checklist להערות דובר ותוויות תרשים.

12. קריאה בקול אחרונה (או text-to-speech)

קראו את היעד בקול רם—או השתמשו ב־Word / OS read-aloud—תוך מבט למקור על מספרים ושמות. סוקרי ATA ממליצים במיוחד על read-aloud כדי לתפוס מספרים שגויים וניסוח לא טבעי. אתם מקשיבים ל:

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

כל דבר שעוצר אתכם—תקנו לפני Send.

רשימת בדיקה מהירה להעתקה־הדבקה

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

מתי צריך מעבר QA עמוק יותר

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

Translation QA Checklist: 15 Must-Check Items — QA פרויקט מלא יותר
Translation Proofreading Checklist for Pros — הגהה ברמת בלשן
Bilingual Document Review Checklist — מעברי מסמך מקור־מול־יעד

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

Sources

How to Review a Translation — American Translators Association (ATA) — completeness, accuracy, readability, read-aloud, hidden text, final format check
Quality Control in Translation — ATA — register, numbers/proper nouns, client instructions, bilingual review habits
CLDR Date/Time Patterns — locale date format conventions
CLDR Number and Currency Patterns — decimal/grouping separators and currency patterns
Register — Cambridge Dictionary Grammar — register as purpose-, context-, and audience-driven language variety
Formal and informal language — Cambridge Grammar — formal vs informal usage cues
Working with Composite Messages — W3C Internationalization — placeholders/variables must remain intact and reorderable
Multidimensional Quality Metrics (MQM) — open issue typology used across localization QA (accuracy, fluency, locale convention, and related dimensions)