עברית ו-RTL ב-Claude Design — מדריך מלא

מה יהיה לך בסוף הפרק הזה

One-pager עברי מושלם ב-RTL — מוכן לשליחה ללקוח ללא תיקונים ידניים
RTL Prompt Template — תבנית prompt מוכנה לשימוש בכל פרויקט עברי
רשימת 5 פונטים עבריים מוכנסים לסביבת העבודה שלך ב-Claude Design
HTML Export Fix Script — קטע קוד מוכן לתיקון RTL בקוד HTML שיוצא
RTL QA Checklist ב-12 נקודות — מוכנה להדפסה ולשימוש לפני כל ייצוא
Mixed Content Template — תבנית לעמוד עם טקסט עברי ואנגלי ביחד
Workarounds Document — מסמך של 7 פתרונות לבעיות RTL ידועות

מה תדעו לעשות אחרי הפרק הזה

תוכל/י להגדיר RTL נכון ברמת המסמך וברמת האלמנט הבודד ב-Claude Design
תוכל/י לבחור ולהחיל את הפונט העברי המתאים לכל סוג תוצר
תוכל/י לפתור לפחות 5 בעיות RTL נפוצות בלי לפנות לאיש מקצוע
תוכל/י לכתוב Prompt שמייצר תוצאת RTL נכונה מהניסיון הראשון
תוכל/י לבצע QA מלא על כל תוצר עברי לפני ייצוא

לפני שמתחילים

פרקים קודמים: פרק 2 (הממשק), פרק 3 (פרויקט ראשון), פרק 5 (One-Pagers), פרק 6 (Landing Pages)
כלים נדרשים: גישה ל-Claude Design (Claude Pro, Max, Team או Enterprise)
ידע קודם: נוח ליצור one-pager בסיסי ב-Claude Design (פרק 3 ופרק 5)
זמן מוערך לפרק זה: 90-120 דקות, כולל תרגילים

הפרויקט שלך

בפרק 8 בנית Brand Kit מלא לעסק ישראלי — לוגו, פלטת צבעים, פונטים ו-social media templates. כולם מחכים בסביבת העבודה שלך. בפרק הזה תיקח את ה-Brand Kit הזה ותוודא שכל אחד מהתוצרים שלו יוצא ב-RTL מושלם — עמודים עבריים שנראים כמו שהם נועדו להיראות, ולא כמו תרגום גרוע. בפרק 10 תוציא את כל זה לחיים אמיתיים כאשר תבנה Wireframe ו-Prototype עם כיוון RTL נכון מהבסיס.

מילון מונחים — פרק 9

מונח (אנגלית)	תרגום / שם עברי	הסבר קצר
RTL (Right-to-Left)	ימין לשמאל	כיוון קריאה וכתיבה של שפות כמו עברית וערבית — הטקסט מתחיל מימין ומסתיים משמאל
LTR (Left-to-Right)	שמאל לימין	כיוון הקריאה הרגיל של אנגלית ורוב שפות אירופה
BiDi (Bidirectional)	דו-כיווני	מנגנון שמאפשר לטקסט LTR ו-RTL לדור בכפיפה אחת — לדוגמה: "הגענו ל-50% מהיעד"
Unicode BiDi Algorithm	אלגוריתם BiDi של Unicode	הסטנדרט הבינלאומי שקובע איך לטפל בטקסט מעורב. הדפדפן מיישם אותו, לעתים בטעות
dir attribute	תכונת הכיוון	תכונת HTML שקובעת את כיוון הטקסט: `dir="rtl"` או `dir="ltr"`
Document Level	רמת המסמך	הגדרת RTL על כל המסמך כולו — ב-HTML זה על תג <html> או <body>
Element Level	רמת האלמנט	הגדרת כיוון על רכיב ספציפי בלבד — שימושי למספרים, כותרות אנגליות, URLs
Google Fonts	Google Fonts	שירות חינמי של Google לטעינת פונטים באתרים ובמסמכים. תומך בפונטים עבריים מאיכות גבוהה
Heebo / Rubik / Assistant	שמות פונטים עבריים	שלושה פונטים עבריים מובילים מ-Google Fonts, מותאמים לעיצוב דיגיטלי ולהדפסה
PDF Export	ייצוא PDF	הפיכת המסמך לקובץ PDF — פורמט שמשמר עיצוב אבל לפעמים שובר RTL
HTML Export	ייצוא HTML	הפיכת העיצוב לקוד אינטרנט — מאפשר פריסה לאתר אבל מצריך תיקוני RTL
QA (Quality Assurance)	בקרת איכות	תהליך בדיקה שיטתי לפני ייצוא — ודא שכל הפרטים נכונים לפני שהתוצר יוצא

מתחיל 15 דקות חינם מושג

RTL Basics — מה זה ולמה זה בעייתי ב-AI

אם אתם מעצבים בעברית, אתם כבר יודעים את הכאב. פתחתם כלי AI חדש, כתבתם prompt, קיבלתם עיצוב מרשים — ואז ראיתם שהטקסט הפוך, הכפתורים בצד הלא נכון, הספרות קופצות מצד לצד, וה-layout נשבר לחלוטין. זה לא רק "תפיסה אסתטית" — תוצר RTL שבור הוא תוצר לא מקצועי שלא ניתן לשלוח ללקוח.

RTL (Right-to-Left, ימין לשמאל) הוא הכיוון הטבעי של עברית, ערבית ופרסית. זה אומר שלא רק הטקסט עצמו הפוך — כל ה-layout, מיקום הרכיבים, הרווחים, כיוון האייקונים, סדר עמודות הטבלה — הכל מכוון מימין לשמאל.

למה AI Tools בכלל מתקשים עם RTL?

מודלי AI אומנו בעיקר על תוכן באנגלית. גם כשהם "מבינים" עברית — הגנרציה החזותית שלהם מחושבת ב-LTR ורק מתורגמת אחר כך. זה יוצר סדרה של בעיות מובנות:

כיוון Layout: Navigation bars, sidebars, הרכיבים מסודרים ל-LTR גם כשהטקסט עברי
Bullet Points: הנקודות מופיעות משמאל לטקסט במקום מימין
מספרים: אלגוריתם BiDi לא תמיד מפרש נכון מספרים בתוך טקסט עברי
Input Fields: שדות טקסט מוגדרים LTR — המשתמש כותב מימין אבל הסמן זזה שמאלה
אייקונים כיווניים: חץ "קדימה" מצביע שמאלה גם בהקשר ימין-לשמאל
Export: גם אם הממשק נראה נכון, PDF ו-HTML מיוצאים עם LTR כברירת מחדל

עשה עכשיו — 3 דקות 3 דקות

פתחו תוצר עברי שיצרתם ב-Claude Design בפרקים הקודמים (one-pager, pitch deck — כל אחד). הסתכלו על 3 דברים:

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

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

הסטנדרט: Unicode BiDi Algorithm

הדפדפנים ומעבדי PDF מיישמים את Unicode Bidirectional Algorithm — אלגוריתם שמנסה להבין אוטומטית את כיוון כל תו. הוא עובד טוב עבור טקסט פשוט, אבל נכשל לעתים קרובות כאשר:

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

הפתרון היחיד הוודאי: הגדרה מפורשת של כיוון ב-HTML (dir="rtl") ובהגדרות עיצוב ב-Claude Design. לא לסמוך על אוטומציה.

ההשלכות העסקיות של RTL שבור

בעיות RTL הן לא רק אסתטיות — הן בעיות עסקיות ממשיות. כשתוצר שיווקי יוצא עם כיוון שבור, ההשפעה מיידית:

אובדן אמינות: לקוח ישראלי שמקבל one-pager עם טקסט מיושר שמאל או bullets הפוכים — מזהה מיד שזה "לא מקצועי". הוא לא יאמר לכם, הוא פשוט לא יחזור.
מחירים שגויים: כשמחיר ₪4,500 מוצג כ-500,4₪ זו לא טעות קוסמטית — זו בעיה משפטית פוטנציאלית. לקוח יכול לטעון שהמחיר המפורסם שונה.
מספרי טלפון הפוכים: לקוח שמנסה להתקשר ומגיע למספר שגוי — אבד לכם.
Landing Pages עם שיעור נטישה גבוה: אם ה-layout שבור, המבקר סוגר את הדף תוך שניות. אתם משלמים ל-Google Ads על קליק שלא הוביל לכלום.
זמן תיקון: לתקן RTL אחרי שהתוצר "בייצור" לוקח פי 3 מאשר לעשות את זה נכון מההתחלה. כל רגע שאתם מתקנים, אתם לא מייצרים דברים חדשים.

הנקודה: RTL הוא לא nice-to-have. בשוק הישראלי, RTL שבור = תוצר פגום = כסף שאבד. ב-Claude Design, ההשקעה בהגדרה נכונה מראש היא 2-3 דקות — התיקון לאחר מעשה הוא 30 דקות ומעלה.

טעות נפוצה: "נראה לי שזה נכון"

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

מתחיל 10 דקות חינם מושג

Claude Design ו-RTL — מצב נוכחי ומגבלות

Claude Design (אפריל 2026) תומך ב-RTL — אבל לא בצורה מושלמת. בפרק 2 עשיתם סיור בממשק ולמדתם את הפאנלים השונים. עכשיו נבחן ספציפית את היכולות ואת המגבלות של כל פאנל כשמדובר ב-RTL. הנה המציאות הכנה:

מה עובד טוב

הגדרת dir="rtl" ברמת המסמך בעת יצירה עם prompt מפורש
Google Fonts עבריים (Heebo, Rubik, Assistant) — נטענים ומוצגים נכון
ייצוא PDF עם RTL — כאשר הכיוון מוגדר נכון
עריכה ישירה של טקסט עברי בממשק
Layout של one-pagers עם RTL — כאשר מבקשים במפורש

מה עובד חלקית

Mixed Content (עברית + אנגלית) — צריך הגדרה מפורשת לכל בלוק
Slide Templates — חלק מהתבניות מוגדרות LTR ודורשות override
HTML Export — יוצא עם RTL ב-body אבל לא תמיד בכל האלמנטים
Tables — כיוון עמודות לא תמיד נכון

מה לא עובד (עדיין)

אוטומציה מלאה — Claude Design לא "מבין" שהוא בעברית ולא מגדיר RTL לבד
Bullet Alignment — נקודות bullet לא תמיד עוברות לצד ימין
ייצוא PPTX — PowerPoint לעיתים מאבד RTL בשקפים מסוימים
SVG Export — אלמנטים וקטוריים עם טקסט עברי לפעמים שבורים

עשה עכשיו — 2 דקות 2 דקות

פתחו Claude Design ויצרו מסמך חדש. כתבו בשדה ה-Chat: "צור one-pager בעברית עם dir=rtl". תראו מה Claude Design מייצר — האם הכיוון נכון מההתחלה? תעדו את התוצאה.

טעות נפוצה: להניח שמה שעבד אתמול עובד היום

Claude Design מתעדכן לעיתים קרובות, ומגבלות RTL עשויות להתקן — אבל גם להשתנות. הטעות: משתמשים בונים workflow ומניחים שהוא יעבוד לנצח. המציאות: עדכון אחד יכול לשנות את האופן שבו Claude Design מטפל ב-bullets או ב-text direction. הפתרון הבטוח: תמיד בדקו RTL על התוצר הסופי, ואל תניחו שמה שעבד אתמול עובד היום.

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

הגדרת כיוון טקסט — Document vs Element Level

יש שני מקומות שאפשר להגדיר RTL: ברמת המסמך כולו, או ברמת אלמנט בודד. הבנת ההבדל חוסכת שעות של תסכול. רוב המשתמשים מגדירים Document Level ומניחים שזה מספיק. זה לא. Element Level נחוץ בכל פעם שיש אלמנט LTR (מספר, URL, שם מותג) בתוך מסמך RTL — ובמסמכים ישראליים, זה כמעט תמיד.

Document Level — כיוון למסמך כולו

כשאתם בונים מסמך שהוא 80% עברית ומעלה — הגדירו RTL ברמת המסמך. ב-HTML זה נעשה על תג <html> או <body>:

Prompt לכיוון מסמך

כשאתם יוצרים מסמך חדש, הוסיפו תמיד לסוף ה-prompt:

"המסמך הוא בעברית עם כיוון RTL. הגדר dir='rtl' על כל המסמך. כיוון ה-layout הוא ימין לשמאל: טקסט מתחיל מימין, navigation בצד שמאל, כפתורים ראשיים בצד שמאל."

ב-Claude Design, ה-Document Level setting נמצא ב-Design System Panel → Layout → Text Direction. כאשר תגדירו RTL שם, כל אלמנט חדש שתוסיפו יירש את הכיוון הזה אוטומטית.

מה בדיוק קורה כשמגדירים Document RTL?

כשאתם מגדירים RTL ברמת המסמך, הדברים הבאים קורים אוטומטית:

יישור טקסט: כל טקסט חדש מיושר אוטומטית לצד ימין
כיוון Layout: אלמנטים מסודרים מימין לשמאל ב-flex containers
Scrollbar: סרגל גלילה עובר לצד שמאל (כמצופה ב-RTL)
Margin ו-Padding: הרווחים מותאמים — margin-start הופך ל-right
Tables: עמודה ראשונה היא הכי ימנית

מה לא קורה אוטומטית:

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

המסקנה: Document RTL הוא הצעד הראשון, אבל לא האחרון. הוא חוסך 70% מהעבודה, אבל ה-30% שנשארים דורשים תשומת לב פרטנית — ובדיוק את זה תלמדו בפרק הזה.

עשה עכשיו — 5 דקות 5 דקות

ב-Claude Design, פתחו מסמך שיצרתם בפרקים הקודמים. נווטו ל-Design System Panel → Layout → Text Direction. האם הוא מוגדר RTL? אם לא — שנו אותו ל-RTL ותראו מה קורה לעיצוב. כתבו מה השתנה.

Element Level — כיוון לאלמנט בודד

לפעמים אתם צריכים אלמנטים ספציפיים שיישארו LTR בתוך מסמך RTL. דוגמאות נפוצות:

כתובת URL: https://www.mysite.co.il — תמיד LTR
כתובת אימייל: info@mycompany.com — תמיד LTR
שם מותג באנגלית: "Nike", "Apple", "Waze" — LTR כשהוא עומד לבד
קוד תכנות: תמיד LTR
מספרי טלפון: בישראל — LTR (050-123-4567)

ב-Claude Design, בחרו אלמנט → Properties Panel → Text Direction → LTR. ב-HTML Export, הוסיפו dir="ltr" לאלמנט הספציפי.

Prompt לכיוון אלמנט

כאשר אתם מוסיפים אלמנט שצריך LTR בתוך מסמך RTL, כתבו:

"הוסף תיבת טקסט עם כתובת האתר www.example.co.il — הגדר אותה LTR בתוך המסמך הכללי ב-RTL"

מסגרת החלטה: Document RTL vs Element RTL

המצב	הגדרה מומלצת	איך לעשות
המסמך כולו בעברית (80%+)	Document RTL	Design System Panel → Layout → RTL
מסמך דו-לשוני שווה בשווה	Document RTL + Element LTR לקטעי אנגלית	RTL כברירת מחדל, LTR על כל קטע אנגלי
מסמך אנגלי עם פיסות עברית	Document LTR + Element RTL לקטעי עברית	LTR כברירת מחדל, RTL על כל פסקה עברית
URL / אימייל בתוך טקסט עברי	Element LTR	Properties Panel על האלמנט הספציפי
כותרת מותג (אנגלית) על מסמך עברי	Element LTR + Center alignment	LTR על כותרת, יישור מרכז למניעת בלבול

עשה עכשיו — 5 דקות 5 דקות

ב-one-pager שפתחתם לפני, הוסיפו כתובת אתר (למשל: www.hayesor.co.il). וודאו שהיא מוגדרת LTR בתוך המסמך ה-RTL. בדקו: האם ה-URL נראה נכון? האם הנקודות והסלשים בכיוון הנכון?

מתחיל 15 דקות חינם כלי

פונטים עבריים שעובדים — Heebo, Rubik, Assistant, Noto

בחירת פונט היא אחת ההחלטות הכי משפיעות על מסמך עברי. פונט לא מתאים הופך תוצר מקצועי לבינוני, ופונט שבור (שלא תומך בעברית) הופך את הטקסט לריבועים ריקים. בפרק 7 למדתם לבנות Design System, ובפרק 8 יצרתם Brand Kit שכולל בחירת פונטים. עכשיו נעמיק: איזה פונטים עבריים באמת עובדים ב-Claude Design, ומה ההבדלים בין הפונטים הנפוצים.

הפונטים המובילים לעברית (Google Fonts)

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

Heebo — הפונט הסטנדרטי

Heebo הוא פונט עברי מודרני, נקי ומקצועי. נוצר על ידי מעצבים ישראליים ומותאם במיוחד למסכים דיגיטליים. הוא נפוץ בממשקי ממשלה ישראליים (כמו gov.il), באפליקציות בנקאות, ובאתרים של חברות הייטק ישראליות. מתאים ל:

One-pagers ומסמכים שיווקיים
Landing Pages
מסמכי עסקים ופורמליים
כל מקום שצריך קריאות גבוהה

משקלים זמינים: 300 (Light), 400 (Regular), 500 (Medium), 600 (SemiBold), 700 (Bold), 800 (ExtraBold), 900 (Black).
Prompt: "השתמש בפונט Heebo מ-Google Fonts לכל הטקסט העברי"

Rubik — אופי ואישיות

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

מותגים פונים לצעירים
אפליקציות ומוצרים טכנולוגיים
Social Media — פוסטים ו-Stories
Start-up Pitch Decks

Prompt: "השתמש בפונט Rubik מ-Google Fonts — כותרות ב-700, גוף ב-400"

Assistant — דיוק ובהירות

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

דוחות ומסמכים עסקיים
טבלאות ותוכן מפורט
Footnotes וtexts קטנים
מסמכים משפטיים ופיננסיים

Prompt: "השתמש בפונט Assistant מ-Google Fonts — פונט נקי ומקצועי לדוח"

Noto Sans Hebrew — תמיכה מלאה

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

Prompt: "השתמש בפונט Noto Sans Hebrew — יש במסמך עברית וערבית ביחד"

Frank Ruhl Libre — אלגנטיות סריפית

Frank Ruhl Libre הוא פונט עברי סריפי (עם תגיות) — מה שנקרא Serif בעולם האנגלי. הוא נותן תחושה קלאסית, רשמית ואלגנטית. מתאים ל:

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

Prompt: "השתמש בפונט Frank Ruhl Libre לכותרות, ו-Heebo לגוף הטקסט — שילוב serif + sans-serif"

Font Pairing — שילוב פונטים לתוצאה מקצועית

מעצבים מקצועיים לא משתמשים בפונט אחד — הם משלבים 2 פונטים: אחד לכותרות ואחד לגוף. ב-Claude Design אפשר להגדיר font pairing בקלות. בפרק 7 למדתם לבנות Design System — עכשיו הזמן להוסיף font pairing ל-DS שלכם:

שילוב	כותרות	גוף	מתאים ל-
קלאסי + מודרני	Frank Ruhl Libre	Heebo	משרדי עורכי דין, יועצים, נדל"ן
צעיר + נקי	Rubik Bold	Assistant	סטארטאפים, אפליקציות, טכנולוגיה
נקי + נקי	Heebo Black	Heebo Regular	כל סוגי התוצרים — הבחירה הבטוחה
רב-לשוני	Noto Sans Hebrew Bold	Noto Sans Regular	מסמכים עם 3+ שפות

Prompt לשילוב פונטים: "השתמש ב-Rubik Bold (700) לכל הכותרות ו-Assistant Regular (400) לגוף הטקסט. שני הפונטים מ-Google Fonts."

מסגרת החלטה: איזה פונט לבחור?

סוג תוצר	פונט מומלץ	כותרות	גוף טקסט
One-Pager שיווקי	Heebo	800 / ExtraBold	400 / Regular
Pitch Deck לסטארטאפ	Rubik	700 / Bold	400 / Regular
Landing Page	Heebo או Rubik	700-800	400
דוח עסקי / מסמך רשמי	Assistant	700 / Bold	400 / Regular
Brand Guidelines	Heebo	900 / Black	300 / Light
מסמך רב-לשוני	Noto Sans Hebrew	700	400
Social Media	Rubik	800	500 / Medium

עשה עכשיו — 5 דקות 5 דקות

פתחו one-pager מפרק 5. שנו את הפונט ל-Heebo. עשו זאת דרך ה-Chat: "שנה את הפונט של כל המסמך ל-Heebo מ-Google Fonts — כותרות ב-700, גוף ב-400". בדקו: האם הטקסט נקרא טוב יותר? האם הכיוון נשמר?

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

פונטים כמו Arial, Helvetica, Times New Roman תומכים בעברית בסיסית — אבל לא בצורה איכותית. ה-kerning (רווח בין אותיות) לקוי, המשקלים מוגבלים, וה-rendering על מסך נחות. תמיד העדיפו פונט עברי ייעודי מ-Google Fonts. זה חינמי לחלוטין ומשפר את המראה פלאים.

טעות נפוצה: פונט אחד לעברית ואנגלית ביחד

בלתי נמנע — מסמכים ישראליים מעורבים. הבעיה: פונטים עבריים רבים מגדירים ספרות ורומן (אנגלית) בצורה שנראית לא עקבית. הפתרון: הגדירו פונט זוגי (pair). Heebo לעברית + Inter לאנגלית עובד מצוין. הגידו ל-Claude Design: "Heebo לטקסט עברי, Inter לטקסט אנגלי".

בינוני 20 דקות חינם תרגול

Mixed Content — עברית ואנגלית באותו מסמך

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

בפרק 5 בניתם one-pagers, ובפרק 6 בניתם landing pages. בשניהם נתקלתם כנראה ב-Mixed Content — גם אם לא שמתם לב. עכשיו אתם מקבלים את הכלים לטפל בזה בצורה שיטתית. כל תוצר שתבנו מפרק זה והלאה — Mixed Content שלו יצא נכון מההתחלה.

כלל הזהב של Mixed Content

כלל הזהב פשוט: כל בלוק תוכן — כל תיבת טקסט, כל כותרת, כל פסקה — צריך כיוון מוגדר מפורש. אל תסמכו על אוטומציה של BiDi. הסיבה: גם אם הדפדפן מציג נכון, ה-PDF ייצא לעתים קרובות שגוי. ב-Claude Design, הדרך הטובה ביותר לעשות זאת היא לציין בכל prompt את כיוון כל אלמנט מפורשות.

דפוסים נפוצים ב-Mixed Content

דפוס 1: מותג באנגלית + תיאור בעברית

דוגמה מייצגת:

לוגו: "TechStart" (LTR, center)
כותרת: "הפתרון שעבדתם כל כך קשה כדי למצוא" (RTL)
כפתור: "התחילו עכשיו" (RTL)

Prompt: "שם המותג 'TechStart' בראש העמוד ב-LTR, מיושר למרכז. שאר כל התוכן בעברית עם RTL."

דפוס 2: כותרת עברית + תת-כותרת אנגלית (מונח מקצועי)

דוגמה מייצגת:

כותרת: "שיפור ה-Conversion Rate שלכם" (RTL, עם המונח האנגלי ב-LTR inline)
טיפ: המונח האנגלי "Conversion Rate" יוצג נכון כ-LTR בתוך הכותרת ה-RTL — הדפדפן מטפל בזה אוטומטית. אבל: ב-PDF ייצוא עשויה להיות בעיה. הפתרון: כתבו את המונח ה-אנגלי בנפרד ב-span dir="ltr".

דפוס 3: טבלה עם ראשים בעברית ונתונים מעורבים

דוגמה מייצגת:

Prompt: "צור טבלה ב-RTL — ראשי עמודות וטקסט עברי ימינה, אבל עמודת Status ב-LTR. מספרים ותאריכים — ראה הנחיות BiDi בהמשך."

עשה עכשיו — 5 דקות 5 דקות

ב-Claude Design, כתבו prompt לדף אחד עם Mixed Content:

"צור section קצר עם כותרת עברית, פסקה עם שם מותג אנגלי ('Mobileye') בתוכה, וכפתור CTA בעברית. RTL כברירת מחדל."

בדקו: האם שם המותג נראה נכון? האם הכפתור בצד הנכון?

דוגמאות מהשוק הישראלי — Mixed Content בפועל

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

דוגמה: One-Pager לסטודיו יוגה בתל אביב

כותרת: "Flow Studio — סטודיו ליוגה ומדיטציה" (שם המותג Flow Studio ב-LTR, שאר הכותרת ב-RTL)

גוף: "השיעורים שלנו כוללים Vinyasa, Yin Yoga ו-Power Yoga — כולם ברמות שונות." (מונחים מקצועיים באנגלית בתוך משפט עברי)

CTA: "הירשמו לשיעור ניסיון" (עברית)

פרטים: "02-123-4567 | www.flowstudio.co.il | רחוב דיזנגוף 120, תל אביב" (מספר טלפון ו-URL ב-LTR, כתובת ב-RTL)

Prompt: "שם המותג 'Flow Studio' — ב-LTR, center. מונחים מקצועיים (Vinyasa, Yin Yoga, Power Yoga) — השאר כ-LTR inline. מספר טלפון ו-URL — ב-LTR spans. כל שאר הטקסט — RTL."

שימו לב: ככל שאתם מדייקים יותר ב-prompt, כך Claude Design מייצר תוצאה טובה יותר מההתחלה. השקיעו 2 דקות נוספות בכתיבת prompt מפורט — תחסכו 15 דקות של תיקונים.

טעות נפוצה: Prompt ל-Mixed Content בלי הגדרה מפורשת

כשאתם כותבים prompt שמכיל מילים אנגליות (שמות מותגים, מונחים מקצועיים) בתוך הנחיה עברית — Claude Design לא יודע מה אתם רוצים. הוא עשוי ל"תרגם" את המונחים, לשנות את הכיוון, או לתת LTR לכל הדף. תמיד פרטו: "שם המותג X — ב-LTR, שאר התוכן — RTL".

בינוני 15 דקות חינם תרגול

מספרים ותאריכים — בעיות BiDi נפוצות

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

הבעיות הנפוצות

בעיה 1: מספרים בתחילת שורה

שורה שמתחילה במספר בתוך טקסט RTL — לדוגמה "3 סיבות למה..." — עלולה להיות מוצגת עם ה-3 בצד השמאלי (LTR), כאילו היא שורה אנגלית.

פתרון: כתבו "שלוש סיבות למה..." (מילה במקום מספר) או עטפו בתוך  בייצוא HTML.

בעיה 2: מספרי טלפון

מספר טלפון ישראלי: 050-123-4567. בתוך טקסט RTL הוא עשוי להיות מוצג: 7654-321-050. הסיבה: BiDi הופך את סדר הספרות.

פתרון: עטפו מספרי טלפון ב-LTR: 050-123-4567

בעיה 3: תאריכים

תאריך ישראלי: 22.04.2026. בתוך טקסט RTL יכול להיות מוצג: 2026.04.22 (נהפך לפורמט אמריקאי).

פתרון: הגדירו תאריך ב-LTR span. או: כתבו את התאריך בעברית: "כ"ב אפריל 2026" — עברית מלאה לא מושפעת מ-BiDi.

בעיה 4: מחירים עם סמלים

₪4,500 בתוך טקסט RTL — סמל השקל יכול להיות מוצג ₪4,500 (נכון) או 500,4₪ (שגוי). תלוי בהקשר.

פתרון: ₪4,500 בקוד HTML.

Prompts לטיפול ב-BiDi מספרים

למספרי טלפון: "הוסף מספר טלפון 050-123-4567 בתיבת טקסט LTR נפרדת — לא בתוך הפסקה העברית"

לתאריכים: "הוסף תאריך: 'עודכן: אפריל 2026' — כתוב אותו בעברית מלאה כדי למנוע בעיות BiDi"

למחירים: "הוסף מחיר ₪4,500 — ב-LTR span בתוך הטקסט"

עשה עכשיו — 5 דקות 5 דקות

ב-Claude Design, בקשו מסמך עם: "פסקה עברית עם מחיר ₪2,990, מספר טלפון 03-123-4567, ותאריך 22/04/2026". בדקו איך הם מוצגים. האם המספרים נכונים? האם כיוונם הגיוני?

טעות נפוצה: לא לבדוק מספרים לפני ייצוא

משתמשים בודקים שהטקסט ב-RTL ושוכחים לבדוק את המספרים. מחיר שגוי בתוצר שיווקי הוא שגיאה מביכה שיכולה לעלות כסף — לקוח עשוי לדרוש את המחיר ה"מפורסם". תמיד הוסיפו "בדיקת מספרים" כנקודה נפרדת ב-QA checklist.

בינוני 20 דקות חינם תרגול

RTL ב-Slides — כיוון שקפים ו-Bullet Points

מצגות הן ה"בוס הסופי" של RTL. הן מכילות layout מורכב, bullets, טבלאות, גרפים, אנימציות — וכל אחד מהם יכול להישבר בצורה שונה. בפרק 4 למדתם לבנות pitch decks מקצועיים עם מבנה של 10 שקפים. עכשיו נדבר על מה שהופך pitch deck עברי מ"שקפים עם טקסט הפוך" ל"מצגת מקצועית שנראית כאילו מעצב ייעודי בנה אותה".

כיוון שקף — Slide Direction

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

Prompt לפתיחת מצגת RTL

"צור מצגת ב-10 שקפים בעברית. כיוון כל השקפים: RTL (ימין לשמאל). Navigation arrows של הקהל יהיו בצד שמאל. טקסט מתחיל מצד ימין. Bullet points — נקודה מצד ימין לטקסט."

Bullet Points — הבעיה הנפוצה ביותר

ב-RTL, נקודת ה-bullet צריכה להופיע מימין לטקסט, לא משמאל. אבל רוב התבניות של Claude Design (ורוב הכלים) מגדירות bullets כ-LTR.

הסימנים:

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

Prompt לתיקון: "ה-bullet points בשקפים — הנקודות צריכות להיות בצד ימין של הטקסט העברי. תקן את ה-list-style-position ל-inside, ה-text-align ל-right"

Slide Layout בעברית

Layout שקף עברי שונה מ-Layout שקף אנגלי:

אלמנט	שקף אנגלי (LTR)	שקף עברי (RTL)
כותרת	יישור שמאל	יישור ימין
לוגו	פינה שמאל עליון	פינה ימין עליון
מספר שקף	פינה ימין תחתון	פינה שמאל תחתון
Bullet List	● טקסט (נקודה שמאל)	טקסט ● (נקודה ימין)
תמונה + טקסט	תמונה שמאל, טקסט ימין	תמונה ימין, טקסט שמאל
Progress Bar	ממלא שמאל לימין	ממלא ימין לשמאל

עשה עכשיו — 5 דקות 5 דקות

פתחו pitch deck מפרק 4. בחרו שקף עם bullets. בדקו: הנקודות מאיזה צד? אם הן משמאל — כתבו ב-Chat: "תקן את ה-bullet points בכל השקפים לכיוון RTL — נקודות מצד ימין". שמרו לפני ואחרי.

ייצוא PPTX — מה לצפות

ייצוא ל-PowerPoint (PPTX) הוא האתגר הגדול ביותר. מה שנראה מושלם ב-Claude Design יכול להישבר ב-PowerPoint:

כיוון שקף: PowerPoint תומך ב-RTL אבל צריך לאקטב בהגדרות: View → Slide Properties → RTL
Bullets: PowerPoint לפעמים הופך אותן ל-LTR — צריך תיקון ידני
טבלאות: לפעמים עמודות הופכות סדר — בדקו בעיון
פונטים: אם Heebo לא מותקן על מחשב הנמען — Windows יחליף אותו באוטומטי

המלצה מעשית: לכל מצגת עברית שנשלחת ל-PowerPoint — הוסיפו את הפונטים כ-Embed בקובץ, ובקשו מהנמען להפעיל RTL ידנית אם נדרש.

Prompt Template מלא למצגת RTL

בפרק 4 למדתם את מבנה ה-Pitch Deck ב-10 שקפים. הנה הגרסה המעודכנת שמבטיחה RTL מושלם מההתחלה:

Prompt Template — מצגת עברית מושלמת

"צור מצגת Pitch Deck ב-10 שקפים לעסק [שם העסק].
עברית מלאה, כיוון RTL על כל השקפים.
פונט: Heebo — כותרות ב-800, גוף ב-400.
Layout: כותרת מיושרת ימין, לוגו בפינה ימנית עליונה, מספור שקפים בפינה שמאלית תחתונה.
Bullets: נקודה מצד ימין לטקסט, עם ריווח של 1em.
שקף נתונים: גרפים עם תוויות בעברית, ציר X מימין לשמאל.
שקף אחרון (CTA): כפתור ראשי במרכז עם טקסט עברי.
מספרי טלפון ו-URLs — ב-LTR spans.
פלטת צבעים: [צבעי Brand Kit מפרק 8]."

שימו לב איך ה-prompt הזה מפנה לפלטת הצבעים מפרק 8 — ה-Design System שבניתם. כך כל התוצרים שלכם עקביים: המצגת נראית כמו ה-one-pager, שנראה כמו ה-landing page, שנראה כמו ה-Brand Kit. זו הנקודה שבה הכל מתחבר.

בינוני 25 דקות חינם תרגול

RTL ב-Landing Pages — HTML Export Fixes

בפרק 6 למדתם לבנות Landing Pages ולייצא HTML. כעת נעמיק בטיפול ב-RTL בקוד שיוצא. זה החלק ה"מפחיד" — אבל עם הכלים הנכונים הוא הופך לתהליך פשוט ושיטתי.

מה מייצר Claude Design ב-HTML Export

כאשר אתם מייצאים HTML מ-Claude Design, מה שאתם מקבלים הוא בדרך כלל:

HTML שיוצא — מבנה טיפוסי

<!DOCTYPE html>
<html lang="he">  <!-- lang נכון, אבל dir חסר -->
<head>
  <meta charset="UTF-8">
  <link href="https://fonts.googleapis.com/css2?family=Heebo..." rel="stylesheet">
</head>
<body>  <!-- בלי dir="rtl" -->
  <section class="hero">
    <h1>כותרת ראשית</h1>  <!-- נכון, אבל alignment עשוי להיות left -->
    <p>טקסט תיאור...</p>
  </section>
</body>
</html>

ה-Fix Script — תיקון מלא ב-5 שורות CSS

הוסיפו את ה-CSS הבאה לתוך ה-<head> של כל HTML שמייצאים:

RTL Fix CSS — העתיקו את זה לכל HTML עברי

<style>
/* RTL Global Fix for Claude Design HTML Export */
html { direction: rtl; }
body { direction: rtl; text-align: right; }
ul, ol { padding-right: 1.5em; padding-left: 0; }
.ltr, [dir="ltr"] { direction: ltr; text-align: left; }
input, textarea, select { direction: rtl; text-align: right; }
table { direction: rtl; }
th, td { text-align: right; }
/* Phone numbers, emails, URLs - keep LTR */
a[href^="tel"], a[href^="mailto"] { direction: ltr; display: inline-block; }
</style>

הוסיפו גם את ה-attribute ל-HTML:

HTML attribute fixes

<!-- שנו את שורת ה-html ל: -->
<html lang="he" dir="rtl">

<!-- ואת ה-body ל: -->
<body dir="rtl">

עשה עכשיו — 10 דקות 10 דקות

ייצאו landing page עברי שבניתם בפרק 6 כ-HTML. פתחו את הקובץ בעורך טקסט (Notepad++, VS Code). הוסיפו את ה-RTL Fix CSS ל-head. שנו את תגי html ו-body. שמרו ופתחו בדפדפן. מה השתנה?

בעיות RTL נפוצות ב-Landing Pages

Hero Section

הכותרת הראשית, תת-כותרת, וכפתור CTA — לפעמים מיושרים שמאל. Fix: הוסיפו text-align: right ל-.hero ול-.hero h1, h2.

Navigation Bar

לינקי navigation — לפעמים בצד שמאל. ב-RTL, ה-nav bar צריך להיות בצד ימין. Fix: flex-direction: row-reverse על ה-navbar container.

Feature Cards

כרטיסי features עם אייקון + טקסט — אייקון בצד שמאל. ב-RTL צריך מימין. Fix: flex-direction: row-reverse על .feature-card.

Form Fields

שדות לידים — Placeholder מיושר שמאל. Fix: text-align: right; direction: rtl על כל input ו-textarea.

Footer

Footer עם פרטי קשר — כתובת עברית, מספר טלפון, ואימייל — כל אחד דורש טיפול שונה. הכתובת ב-RTL, הטלפון והאימייל ב-LTR. Fix: עטפו כל אלמנט ב-span עם dir מתאים. דוגמה:

<div class="footer" dir="rtl">
  <p>רחוב הרצל 22, תל אביב</p>
  <p><span dir="ltr">03-123-4567</span></p>
  <p><a href="mailto:info@example.co.il" dir="ltr">info@example.co.il</a></p>
</div>

Testimonials / Social Proof

ציטוטים של לקוחות עבריים — לפעמים מוצגים עם גרשיים אנגליים (" ") במקום גרשיים עבריים (׳ ״) או עם מירכאות הפוכות. Fix: החליפו גרשיים אנגליים ב-HTML entities: “ ו-” או פשוט השתמשו ב-em dash לפני הציטוט.

Landing Page RTL — סיכום מהיר

הסדר לבניית Landing Page עברי ב-Claude Design שיוצא נכון ב-HTML:

כתבו prompt עם הנחיית RTL מפורשת (כולל פונט, כיוון, יישור)
בנו את הדף ב-Claude Design ובדקו preview
ייצאו HTML
הוסיפו RTL Fix CSS ו-dir="rtl" ל-html ו-body
בדקו בדפדפן — Desktop ו-Mobile
תקנו בעיות ספציפיות (nav, forms, footer)
אם מעבירים ל-Claude Code (פרק 11) — ה-RTL Fix CSS כבר במקום, מה שחוסך שלב שלם

מסגרת החלטה: HTML RTL Debug — איפה לחפש קודם?

כאשר HTML עברי שבור, בדקו לפי הסדר הזה:

html ו-body attributes: האם יש dir="rtl"? אם לא — זה שורש הבעיה.
text-align: חפשו text-align: left בכל ה-CSS ושנו ל-right (אלא אם מכוון ל-LTR)
flexbox direction: כל flex-direction: row ב-RTL צריך להיות row-reverse
padding/margin: padding-left הופך ל-padding-right ב-RTL — בדקו spacing
floats: float: left הופך ל-float: right ב-RTL
inputs ו-forms: בדקו placeholder direction ו-text alignment

בינוני 20 דקות חינם תרגול

RTL ב-One-Pagers — PDF Export Fixes

One-Pagers ב-PDF הם ה-use case הנפוץ ביותר לעסקים ישראליים — ולכן גם הנושא שבו הכי הרבה אנשים נתקעים. כל בעל עסק קטן בישראל צריך one-pager ב-PDF: לשלוח ב-WhatsApp ללקוח, לצרף למייל, להניח בדלפק בחנות. ייצוא PDF מ-Claude Design שומר את הויזואל יפה, אבל עשוי לאבד כיוון RTL.

למה PDF מאבד RTL?

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

זה ההבדל המרכזי בין HTML ל-PDF: ב-HTML אפשר לתקן אחרי הייצוא (הוספת CSS, שינוי dir attributes), אבל ב-PDF — מה שייצאתם זה מה שתקבלו. PDF שומר את מיקום הפיקסלים, לא את המשמעות הסמנטית של הטקסט. לכן ה-workflow חייב להיות: תקנו הכל בתוך Claude Design, בדקו preview, ורק אז ייצאו.

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

כלל הזהב: תקנו ב-Claude Design, לא ב-PDF

הסדר הנכון:

הגדירו RTL ב-Claude Design לפני הייצוא
בדקו preview ב-Claude Design
ייצאו PDF
בדקו את ה-PDF
אם יש בעיה — חזרו ל-Claude Design, תקנו, ייצאו מחדש

Prompts לפני ייצוא PDF

Pre-Export RTL Prompt — הריצו לפני כל ייצוא PDF

לפני שאתם לוחצים Export → PDF, כתבו ב-Chat של Claude Design:

"לפני הייצוא, בדוק את כל האלמנטים במסמך: (1) כיוון RTL על כל תיבות הטקסט, (2) הטקסט מיושר לימין, (3) bullet points — נקודות בצד ימין, (4) מספרי טלפון ו-URLs ב-LTR, (5) הכותרת הראשית בצד ימין. אשר שהכל תקין לפני הייצוא."

בעיות PDF נפוצות ופתרונות

הבעיה ב-PDF	הסיבה	הפתרון ב-Claude Design
טקסט מיושר שמאל	text-align לא הוגדר ל-right	בחרו כל תיבת טקסט → יישור ימין
כותרת מרכוז שעברה לשמאל	Center alignment נעלם	הגדירו Center alignment מחדש
אייקונים בצד הלא נכון	Layout LTR	שנו את ה-layout עם Prompt: "הזז אייקונים לצד ימין"
פונט לא מוצג (ריבועים)	פונט לא embedded בPDF	בקשו: "embed font Heebo ב-PDF export"
שוליים לא שווים	padding הופך בין LTR ל-RTL	הגדירו שוליים שווים (symmetric margins)
טבלה עם עמודות הפוכות	table direction לא מוגדר	Prompt: "table direction RTL — עמודה ראשונה מימין"

עשה עכשיו — 7 דקות 7 דקות

פתחו one-pager עברי מפרק 5 ב-Claude Design. ריצו את ה-Pre-Export RTL Prompt. ייצאו PDF. פתחו את ה-PDF ב-Adobe Acrobat Reader (או בדפדפן). בדקו את הרשימה: כיוון, יישור, bullets, מספרים. כמה דברים צריכים תיקון?

בינוני 15 דקות חינם ניתוח

בדיקת RTL — Checklist לפני ייצוא

QA (Quality Assurance, בקרת איכות) של RTL לא צריך לקחת יותר מ-10 דקות. עם checklist שיטתי — אתם לא שוכחים כלום. זכרו: בפרק 3 למדתם את ה-Pre-Export Checklist הכללי של 7 נקודות. ה-RTL QA Checklist הוא תוספת ספציפית — אתם מריצים אותו בנוסף ל-checklist הרגיל, לא במקומו.

ה-RTL QA Checklist המלאה — 12 נקודות

RTL QA Checklist — הדפיסו וקבעו ליד המחשב

מספר	מה לבדוק	סימן תקין
1	כיוון מסמך כללי — RTL מוגדר	טקסט מתחיל מימין
2	כותרת ראשית — יישור ימין	H1 מיושר לצד ימין
3	פסקאות גוף — יישור ימין	טקסט רץ מימין לשמאל
4	Bullet Points — נקודות בצד ימין	• מופיע מימין לטקסט
5	מספרי טלפון — נכונים ולא הפוכים	050-123-4567 (לא 7654-321-050)
6	URLs — ב-LTR ונכונים	www.example.co.il (לא הפוך)
7	מחירים — סמל ₪ ומספר בסדר נכון	₪4,500 (לא 500,4₪)
8	תאריכים — לא הפוכים	22.04.2026 (לא 2026.04.22)
9	פונט עברי — נטען ומוצג נכון	ריבועים ריקים = שגיאת פונט
10	CTA כפתור — בצד הנכון ומיושר	כפתור ראשי בצד שמאל (RTL)
11	טבלאות — עמודה ראשונה מימין	עמודת "שם" בצד ימין
12	בדיקה על מכשיר נפרד / דפדפן אחר	פתחו על מובייל או שלחו לחבר

עשה עכשיו — 10 דקות 10 דקות

קחו one-pager עברי שיצרתם בפרקים הקודמים. ריצו עליו את כל 12 הנקודות של ה-QA Checklist. תעדו: כמה V קיבלתם? כמה X? כל X הוא דבר שצריך תיקון — תקנו אחד אחד.

ה-Prompt ל-QA אוטומטי ב-Claude Design

אפשר לבקש מ-Claude Design לבדוק RTL אוטומטית לפני ייצוא:

QA Prompt

"עבור על המסמך ובדוק: (1) כל תיבות הטקסט — כיוון RTL? (2) bullets נכונים? (3) מספרים ותאריכים הגיוניים? (4) פונט טעון? (5) CTA בצד הנכון? דווח על כל בעיה שמצאת ותקן אוטומטית."

Case Study: דו"ח QA על One-Pager לעסק ישראלי

כדי להמחיש את התהליך, הנה דוגמה מלאה של תוצאות QA על one-pager שנבנה ב-Claude Design לעסק ייעוץ עסקי בירושלים:

Case Study: "מומחים לעסקים — ייעוץ אסטרטגי"

תוצר: One-Pager שיווקי ב-PDF, פונט Heebo, RTL. תוכן: כותרת, 4 שירותים, 3 testimonials, מחירים, CTA, פרטי קשר.

ממצאי QA (12 נקודות):

נקודה	תוצאה	פעולה
1. כיוון מסמך כללי	V — RTL תקין	—
2. כותרת — יישור ימין	V — תקין	—
3. פסקאות גוף	V — תקין	—
4. Bullet Points	X — נקודות משמאל	שינוי ל-em dash (—) מימין
5. מספר טלפון	X — 7654-321-050	LTR span על מספר הטלפון
6. URL	V — תקין ב-LTR	—
7. מחירים	X — ₪ אחרי המספר	LTR span על כל מחיר
8. תאריכים	V — בעברית מלאה	—
9. פונט	V — Heebo נטען	—
10. CTA	V — בצד שמאל (נכון ב-RTL)	—
11. טבלאות	אין טבלאות	—
12. בדיקה על מכשיר נפרד	V — נשלח למובייל	—

תוצאה: 9/12. 3 תיקונים נדרשים — כולם ביחד לקחו 8 דקות ב-Claude Design. לאחר תיקון וייצוא מחדש: 12/12.

ה-case study הזה מראה שגם כשמגדירים RTL מההתחלה, יש כמעט תמיד 2-3 נקודות שדורשות תיקון. זה נורמלי. ה-QA Checklist הוא ההבדל בין "כמעט מושלם" ל"שלוח ללקוח בבטחון".

מתקדם 20 דקות חינם אסטרטגיה

Workarounds לבעיות ידועות

כמה בעיות RTL קיימות ב-Claude Design (אפריל 2026) ואין להן פתרון אוטומטי — אבל יש workarounds שעובדים. ה-workarounds האלה פותחו על ידי משתמשים ישראליים ומפתחים שעובדים עם RTL יום יום. הם לא אלגנטיים תמיד — אבל הם עובדים. שמרו את הרשימה הזו לשימוש חוזר. כאן ה-7 הנפוצים ביותר.

Workaround 1: Bullet Points שלא עוברים לימין

הבעיה: גם אחרי הגדרת RTL, bullets נשארים משמאל.

הפתרון: במקום bullet list, בקשו "כל נקודה בשורה נפרדת עם — (מקף) מימין לטקסט". מקף עברי (—) מוצג נכון ב-RTL ונראה מקצועי.

Prompt: "במקום bullet list, השתמש בשורות עם — (em dash) בתחילת כל שורה, מיושר לימין"

Workaround 2: Navigation Bar שנשאר LTR

הבעיה: לינקי ה-nav bar ב-Landing Page — לפעמים מיושרים שמאל גם אחרי RTL.

הפתרון: בקשו מ-Claude Design לשנות את ה-nav layout: "nav bar — לינקים בצד שמאל (כי זה RTL), לוגו בצד ימין. flex-direction: row-reverse על ה-nav container"

Workaround 3: Form Fields עם Placeholder LTR

הבעיה: שדות טופס — placeholder מוצג מהצד הלא נכון.

הפתרון ב-HTML: הוסיפו style="direction:rtl; text-align:right" לכל input שמקבל עברית. לשדות אנגליים (אימייל, טלפון) — direction:ltr; text-align:left.

Workaround 4: שקף PowerPoint שמאבד RTL

הבעיה: PPTX export — שקפים מסוימים מוצגים LTR ב-PowerPoint.

הפתרון: ב-PowerPoint, לחצו על שקף בעייתי → Design → Slide Size → אל תשנו. במקום זאת: Home → Paragraph → RTL. עשו זאת לכל text box בעייתי.

Workaround 5: מספרים הפוכים בתוך טקסט עברי

הבעיה: "הגדלנו את המכירות ב-150% ביחס לרבעון הקודם" — ה-150% עשוי להיות מוצג הפוך.

הפתרון: הוסיפו Unicode zero-width marks: ‎ (Left-to-Right Mark) לפני המספר ואחריו בקוד HTML. ב-Claude Design — בקשו: "עטוף את הנתון 150% ב-span עם direction ltr"

Workaround 6: PDF עם שוליים לא שווים

הבעיה: שוליים ב-PDF — מה שהיה padding-right הופך ל-padding-left ו-vice versa.

הפתרון: תמיד הגדירו שוליים סימטריים (שווים משני הצדדים) ב-Claude Design: "margin: 40px בכל הצדדים — זהה לימין ולשמאל"

Workaround 7: SVG עם טקסט עברי שבור

הבעיה: אלמנטים וקטוריים (לוגו, אייקונים עם טקסט עברי) — טקסט מוצג שגוי ב-SVG.

הפתרון: שני אפשרויות: (א) המירו SVG ל-PNG לפני ייצוא, (ב) אם SVG מוכרח — הוסיפו direction="rtl" ל-<text> element בקוד SVG ידנית.

עשה עכשיו — 5 דקות 5 דקות

בחרו workaround אחד מהרשימה שרלוונטי לתוצר שעליו אתם עובדים עכשיו. יישמו אותו. תעדו: האם הבעיה נפתרה? האם הפתרון עבד כמצופה?

טעות נפוצה: "אסביר ל-Claude Design בעברית — הוא יבין"

מפתה לחשוב שכיוון ה-Prompt בעברית מבטיח RTL בתוצר. זה לא נכון. Claude Design לא "יודע" שאתם רוצים RTL רק כי כתבתם בעברית. תמיד הוסיפו הנחיית RTL מפורשת בכל prompt: "...עם כיוון RTL, טקסט מיושר לימין, פונט Heebo". ה-3 מילים האלה חוסכות 20 דקות של תיקונים.

Workarounds בהקשר — מתי להשתמש בכל אחד

אם אתם עובדים על תוצרים ישראליים באופן שוטף, הנה תרשים זרימה מהיר לעזרה:

One-Pager לשליחה ב-PDF: Workaround 6 (שוליים סימטריים) + RTL ב-Claude Design לפני ייצוא
Landing Page ב-HTML: RTL Fix CSS (סעיף 8 בפרק זה) + Workaround 3 (Form Fields) + Workaround 2 (Nav Bar)
Pitch Deck ל-PPTX: Workaround 4 (PowerPoint RTL) + Workaround 1 (Bullets) + embed fonts
Social Media: בדרך כלל אין צורך ב-workarounds — PNG/JPG export שומר את הויזואל כמו שהוא
Brand Guidelines: Workaround 1 (Bullets) + font pairing (Heebo + Inter, או Frank Ruhl Libre + Heebo)

זכרו: כל תוצר שיצרתם בפרקים 3-8 יכול להפוך מ"טוב" ל"מושלם" על ידי יישום ה-RTL techniques מהפרק הזה. חזרו לתוצרים ישנים — תראו כמה הם משתפרים.

RTL לפי סוג עסק ישראלי — טיפים ספציפיים

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

מסעדות ובתי קפה

תפריטים הם המסמך הנפוץ ביותר. הבעיה המרכזית: מחירים. כל מנה עם מחיר בש"ח — וכל מחיר צריך LTR span. הפתרון הכי טוב: בניית תפריט כטבלה ב-Claude Design, עם עמודת "שם מנה" (RTL) ועמודת "מחיר" (LTR). בקשו מ-Claude Design: "בנה תפריט מסעדה כטבלה עם 3 עמודות: מנה, תיאור, מחיר. עמודות מנה ותיאור — RTL. עמודת מחיר — LTR, סמל ₪ לפני המספר."

חנויות אונליין (e-commerce)

Product Sheets ו-Landing Pages לחנויות מקוונות מכילים הרבה מספרים: מחירים, הנחות, כמויות, מידות. כל אלה דורשים טיפול BiDi. בנוסף, שמות מוצרים לעתים קרובות באנגלית (שמות מותגים בינלאומיים). הגדירו: שמות מוצרים כ-LTR inline, תיאורים כ-RTL, מחירים ב-LTR spans.

עורכי דין ורואי חשבון

מסמכים פורמליים — חוזים, טיוטות, דוחות. האתגר: מספרי סעיפים ("סעיף 3.2.1") בתוך טקסט עברי. הפתרון: כתבו את מספרי הסעיפים בתור שורה נפרדת ב-LTR, ואת תוכן הסעיף ב-RTL. פונט מומלץ: Assistant או Frank Ruhl Libre לתחושה רשמית.

סטארטאפים בשלב Early Stage

Pitch Decks דו-לשוניים — חלק מהשקפים בעברית (למשקיעים ישראליים) וחלק באנגלית (למשקיעים בינלאומיים). הפתרון: אל תערבבו שפות בתוך שקף. שקף עברי = RTL מלא. שקף אנגלי = LTR מלא. החליפו כיוון בין שקפים.

יועצים ומאמנים (Coaches)

מסמכי הצעת מחיר (quotation), מצגות לשיווק, ותוכן ל-Social Media. הבעיה הנפוצה: שימוש במונחים אנגליים כמו "Coaching", "Mindset", "Growth" בתוך טקסט עברי. הפתרון: השאירו את המונחים באנגלית אבל ציינו ב-prompt שהם LTR inline. אל תתרגמו מונחים שקהל היעד משתמש בהם באנגלית.

תרגיל 1 — RTL Audit על תוצר קיים (20 דקות)

מה תייצרו: דוח בדיקת RTL מתועד + גרסה מתוקנת של תוצר קיים

בחרו תוצר: פתחו one-pager עברי שיצרתם בפרקים 3, 5, או 8 ב-Claude Design.
ריצו QA: עברו על כל 12 הנקודות של RTL QA Checklist. תעדו V/X לכל אחת.
תעדו בעיות: לכל X שמצאתם — כתבו: "מה הבעיה? איפה היא מופיעה? מה הפתרון הצפוי?"
תקנו ב-Claude Design: השתמשו ב-Chat כדי לתקן כל בעיה. ריצו prompt לכל תיקון בנפרד.
ייצאו PDF: לאחר התיקונים, ייצאו PDF. פתחו ובדקו שוב את הנקודות שתיקנתם.

תוצאה מצופה: PDF של one-pager עברי עם לפחות 10/12 נקודות QA ירוקות, ודוח מתועד של הבעיות שמצאתם ותיקנתם.

תרגיל 2 — Landing Page עברי מאפס עם RTL נכון (35 דקות)

מה תייצרו: Landing Page עברי מיוצא כ-HTML עם RTL מושלם

כתבו prompt מלא: בנו landing page לשירות ישראלי אמיתי (עסק שאתם מכירים). הכניסו בסוף הprompt: "...מסמך RTL מלא: dir=rtl, פונט Heebo, טקסט מיושר לימין, bullets מימין, nav bar מימין, CTA בצד שמאל"
בנו את הדף: תנו ל-Claude Design ליצור. בדקו את הפריוויו ב-Claude Design.
ריצו RTL QA: עברו על ה-checklist. תקנו כל בעיה שמצאתם.
ייצאו HTML: Export → HTML. פתחו את הקובץ בעורך.
הוסיפו RTL Fix CSS: העתיקו את ה-fix script מהפרק הזה לתוך ה-head של ה-HTML.
בדקו בדפדפן: פתחו את ה-HTML בדפדפן. ריצו את ה-QA Checklist שוב על גרסת הדפדפן.

תוצאה מצופה: קובץ HTML של landing page עברי שנפתח בדפדפן עם RTL מושלם — כל הטקסט מימין, bullets נכונים, מספרים תקינים, CTA פועל.

תרגיל 3 — One-Pager עברי מושלם — The Full Package (45 דקות)

מה תייצרו: One-Pager עברי מושלם עם כל הפונטים, RTL מלא, Mixed Content נכון — מוכן לשליחה ללקוח

בחרו נושא: בחרו שירות עסקי ישראלי אמיתי שאתם מכירים (או עסק שלכם).

כתבו RTL Prompt מלא:

"צור one-pager שיווקי בעברית לשירות [שם השירות].
תוכן: כותרת ראשית, 3 יתרונות עיקריים, מחיר (בש"ח), CTA, מספר טלפון ואתר.
עיצוב: פונט Heebo, RTL מלא, יישור ימין.
פלטת צבעים: [צבעי Brand Kit מפרק 8 שלכם].
Mixed Content: שם המותג באנגלית ב-LTR, שאר הכל RTL.
מספרים: מספר טלפון ו-URL ב-LTR spans.
Checklist לפני ייצוא: בדוק RTL, bullets, מחיר, טלפון."

Iteration: לאחר הייצור הראשוני, עשו לפחות 2 סבבי תיקון דרך Chat.
QA מלא: ריצו את כל 12 נקודות ה-Checklist.
ייצאו PDF + HTML: ייצאו גם כ-PDF וגם כ-HTML. הוסיפו RTL Fix CSS ל-HTML.
בדיקה סופית: שלחו את ה-PDF לעצמכם למייל. פתחו על מובייל. האם נראה נכון?

תוצאה מצופה: One-pager מושלם ב-2 פורמטים (PDF + HTML), עם RTL, Heebo, Mixed Content נכון, ו-QA 12/12. זה ה-deliverable המרכזי של הפרק.

שגרת עבודה — RTL ב-Claude Design

בנוסף לשגרה שבניתם מפרקים 1-8 (כולל Design System, Brand Kit, One-Pagers, Landing Pages), הוסיפו:

תדירות	משימה	זמן
לפני כל ייצוא	ריצו RTL QA Checklist (12 נקודות) על כל תוצר עברי לפני שליחה	10 דקות
לפני כל ייצוא	בדקו מספרים ותאריכים ספציפית — BiDi לא נבדק אוטומטי	3 דקות
לפני כל ייצוא HTML	הוסיפו RTL Fix CSS לקובץ HTML שיוצא	2 דקות
שבועית	בדקו אם Claude Design שחרר עדכונים ל-RTL support — הכלי מתעדכן	5 דקות
לכל לקוח חדש	הגדירו RTL Template נפרד ב-Design System של הלקוח (בפרק 7 למדתם איך)	15 דקות
חד-פעמי	שמרו את RTL Fix CSS ו-Workarounds כקובץ Snippets — כדי לא לחפש כל פעם מחדש	10 דקות
חודשי	בדקו תוצר ישן (מפרק 3, 4, 5, או 6) וריצו עליו את RTL QA — תרגול שמשפר עין לפרטים	20 דקות

שימו לב: השגרה הזו מתווספת על שגרת ה-Design System מפרק 7 ושגרת ה-Brand Kit מפרק 8. אם אתם עובדים עם לקוחות ישראליים — הנקודה "לפני כל ייצוא" תהפוך למשמעותית ביותר בזמן שלכם.

אם אתם עושים רק דבר אחד מהפרק הזה

הוסיפו לכל Prompt של תוצר עברי את ה-3 מילים הבאות בסוף: "RTL, Heebo, יישור ימין". זה לבד יחסוך לכם 80% מהבעיות. שאר ה-20% — ה-QA Checklist של 12 הנקודות יתפוס אותם.

בדוק את עצמך — 5 שאלות

4/5 תשובות נכונות = עברתם את הפרק. מתחת ל-4 — חזרו לסעיפים הרלוונטיים.

למה BiDi Algorithm לא מספיק כדי להבטיח RTL נכון בתוצר סופי?
(רמז: חשבו על ההבדל בין דפדפן שמציג ל-PDF שיוצא)
מדוע מספר טלפון ישראלי בתוך פסקה עברית עלול להיות מוצג הפוך, ומה הפתרון הנכון?
(רמז: חשבו על כיוון ה-span הספציפי)
מה ההבדל בין הגדרת RTL ברמת המסמך לבין ברמת האלמנט, ומתי תשתמשו בכל אחד?
(רמז: חשבו על URL בתוך טקסט עברי)
למה פונט Heebo עדיף על Arial לעברית, ומה הסיבה הטכנית לכך?
(רמז: חשבו על kerning, משקלים, ו-rendering)
מדוע תיקון RTL ב-PDF אחרי הייצוא בלתי אפשרי, ומה הסדר הנכון של פעולות?
(רמז: חשבו על איך PDF שומר מידע)

סיכום הפרק

RTL לא הוא "פיצ'ר" ב-Claude Design — הוא הבסיס שעליו כל תוצר עברי נבנה. המסקנה העיקרית של הפרק: אוטומציה עיוורת לא עובדת. לא BiDi Algorithm, לא ה-lang="he" לבד, ולא הנחיה כללית "עשה RTL". כל תוצר עברי צריך 3 שכבות: הגדרה מפורשת ב-Claude Design, RTL Fix ב-HTML Export, ו-QA Checklist לפני כל שליחה.

הדבר שהכי משנה מיידית: 3 המילים בסוף כל Prompt — "RTL, Heebo, יישור ימין". ואחריהן — 10 דקות QA על הנקודות המספרים-תאריכים-bullets. עם הרגל הזה, התוצרים שלכם יתחילו להיראות כמו עבודת מעצב מקצועי, לא כמו תוצר AI שמתעלם מהשפה.

הפרק הזה משנה את האופן שבו אתם ניגשים לכל פרויקט ב-Claude Design. מפרק 1 ועד פרק 8 בניתם מיומנויות בעיצוב — מצגות, one-pagers, landing pages, design systems, brand kits. הפרק הזה מוסיף את שכבת ה-RTL שהופכת את כל התוצרים האלה למוצרים מוכנים לשוק הישראלי. בלי RTL נכון, התוצרים שלכם "טובים אבל לא ישראליים". עם RTL נכון — הם מקצועיים, מהימנים, ומוכנים ללקוח.

בפרק הבא נעבור ל-Wireframes ו-Prototypes — ואתם כבר תדעו לבנות אותם עם RTL נכון מהבסיס, לא כ-afterthought.

Checklist — פרק 9 הושלם?

☐ זיהיתי לפחות 3 בעיות RTL בתוצר עברי קיים (תרגיל 1)
☐ כתבתי prompt עם הנחיית RTL מפורשת וקיבלתי תוצאה תקינה
☐ הגדרתי RTL ברמת המסמך (Design System Panel) בפרויקט קיים
☐ הוספתי LTR לאלמנט אחד לפחות (URL, מספר טלפון) בתוך מסמך RTL
☐ בחרתי ויישמתי פונט Heebo (או Rubik/Assistant) על תוצר עברי
☐ יצרתי mixed content עם עברית ואנגלית ביחד, עם כיוון נכון לכל חלק
☐ תיקנתי מספרי טלפון ו-URL ב-LTR spans
☐ בדקתי bullets במצגת ותיקנתי לצד ימין
☐ ייצאתי HTML ב-landing page עברי
☐ הוספתי RTL Fix CSS לקובץ HTML
☐ ריצתי RTL QA Checklist של 12 נקודות על תוצר אחד לפחות
☐ ביצעתי את תרגיל 3 — One-Pager עברי מושלם (PDF + HTML)
☐ שמרתי את RTL Fix CSS ואת ה-Workarounds Document בתיקיית הכלים שלי
☐ בדקתי את התוצר על מכשיר נפרד (מובייל או שלחתי לחבר)

→ פרק 8: Brand Assets — לוגו, צבעים, Typography פרק 10: Wireframes ו-Prototypes →