מה קורה לטבלאות במהלך תרגום מסמכים?

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

מה משתנה כשטבלה מתורגמת?

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

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

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

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

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

אילו רכיבי טבלה נשמרים בדרך כלל בתרגום?

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

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

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

חמש בעיות נפוצות בטבלאות והפתרונות שלהן

1. הטקסט גולש או הופך את השורות לגבוהות מדי

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

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

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

2. תאים ממוזגים כבר אינם מתארים את הנתונים הנכונים

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

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

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

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

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

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

4. מספרים, נוסחאות ומזהים משתנים בשקט

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

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

5. טקסט מימין לשמאל משבש סימני פיסוק או יישור

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

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

רשימת בדיקה לפני תרגום

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

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

כיצד לבדוק את הטבלה המתורגמת

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

1. השוו את הרשת. ספרו טבלאות, שורות, עמודות, אזורים ממוזגים, שורות כותרת והערות מול המקור.
2. השוו את התוכן. ודאו שכל תא תורגם פעם אחת ונשאר תחת הכותרת הנכונה.
3. השוו את הנתונים. בדקו מספרים, סימנים, יחידות, נוסחאות, סכומים, מזהים וקישורים בלי לערוך את הטקסט.
4. בדקו את הפריסה. חפשו חיתוך, גידול מופרז של שורות, מעברי עמוד גרועים, טקסט זעיר כתוצאה מהתאמה אוטומטית, גופנים חלופיים ויישור לא אחיד.
5. בדקו כיוון ונגישות. אמתו תאי RTL, קשרי כותרות, סדר קריאה וכותרות חוזרות.
6. יצאו ובדקו שוב. פתחו את ה-PDF למסירה או פורמט סופי אחר; אל תאשרו רק את המקור הניתן לעריכה.

OpenL Doc Translator תומך בפורמטים של מסמכים, ובהם PDF, DOCX, PPTX ו-XLSX. העמוד הרשמי שלו מציין שהוא שומר על גופנים, צבעים, טבלאות ופריסת עמוד, ומספק גרסה מתורגמת וגרסה דו-לשונית לכל משימה. השתמשו במקור הניתן לעריכה כשאפשר, צפו בתוצאה והשוו את הגרסה הדו-לשונית לפני השלמת הבדיקה המובנית שלעיל.

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

מתי בדיקה ידנית חיונית

הקצו תמיד בודק אנושי כאשר הטבלה כוללת:

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

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

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

Sources

• W3C: Text size in translation - Explains text expansion, constrained layouts, compound words, character width, and line-height differences across languages.
• W3C WAI: Tables Tutorial - Explains header-to-data relationships, complex table markup, screen-reader context, and metadata loss during format conversion.
• Microsoft Support: Make your Word documents accessible to people with disabilities - Recommends simple tables, header rows, accessibility checks, and avoiding split, merged, nested, or blank structures where possible.
• Unicode Standard Annex #9: Unicode Bidirectional Algorithm - Defines display ordering for mixed right-to-left and left-to-right text, digits, punctuation, and direction at paragraph or table-cell level.
• OpenL Doc Translator - Lists supported document formats, formatting preservation, free preview, and bilingual review output.