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

בישראל, ערבית היא לא «שפה זרה» במחשב — היא שפה רשמית, שפת שירות בגופים ציבוריים, ושפת יום-יום למיליוני אזרחים. מי שמקליד מכתב לרשות מקומית בנצרת, ממלא טופס באתר gov.il, כותב הודעה ב-WhatsApp לשכן, או מכין מצגת בעבודה — צריך מקלדת ערבית שעובדת. לא «בערך». לא «אחרי שלושה ניסיונות». עובדת.

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

מדריך זה מסביר את מקלדת הערבית בישראל מהיסוד: פריסת Arabic 101, הקשר ל-RTL, התקנה ושימוש ב-Windows, Mac, iOS ו-Android, אתגרים של משתמשים דו-לשוניים עברית-ערבית, טעויות נפוצות, שירות ציבורי וקהילות מעורבות — ואיך תיקלוד (tiklud.com) יכול לתקן טקסט שכבר הוקלד בשכבה שגויה, כולל מיפוי ערבית שמסומן כבטא.

חשוב מההתחלה: «טקסט הפוך» או «גיבריש» בערבית ברוב המקרים אינו בעיית כיוון (RTL) אלא בעיית מיפוי מקשים — Keyboard Layout. Word, Outlook, Google Docs, WhatsApp וטפסים מקוונים מקבלים את התווים שמערכת ההפעלה שולחת. אם השכבה שגויה, כל מסמך, כל הודעה, כל שדה בטופס — מקולקל.

בישראל, workflow טיפוסי כולל שלוש שכבות: עברית (SI 1452), אנגלית (QWERTY), וערבית (Arabic 101). מעבר בין שלושתן — Alt+Shift ב-Windows, Globe ב-Mac, מקש השפה בנייד — קורה עשרות פעמים ביום. כל מעבר הוא נקודת סיכון.

מיפוי הערבית בתיקלוד מסומן כבטא — יש פער ידוע: המקש שאמור לייצר «لا» (לאם-אלף) מפושט ל-«ل» בודדת. תיקלוד מציג סימון בטא גלוי.

אם חיפשתם «מקלדת ערבית בישראל» או «הקלדתי ערבית יצא עברית» — הגעתם למקום הנכון. חיפה, ירושלים, נצרת, gov.il, קהילות מעורבות.

ההמרה בתיקלוד locally בדפדפן — הטקסט לא נשלח לשרת. העתקה → tiklud.com → המרה → העתקה חזרה.

tiklud.com בסימניות — רשת ביטחון. הבדילו בין מקש, שכבה (HE/EN/AR), כיוון (RTL/LTR).

ערבית ועברית חולקות RTL — אבל לא את אותה פריסת מקשים. מקש T: א בעברית, ف בערבית.

מילות מפתח SEO: מקלדת ערבית בישראל, Arabic 101, תיקלוד ערבית בטא, שכבת מקלדת ערבית, שירות ציבורי ערבית.

מילות מפתח SEO: מקלדת ערבית בישראל, Arabic 101, תיקלוד ערבית בטא, שכבת מקלדת ערבית, שירות ציבורי ערבית.

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

בנושא מבוא, חשוב לזכור שתיקלוד לא מחליף עורך מסמכים — הוא כלי ביניים. אחרי «הפוך כיוון» או «המרה», תמיד הדביקו ליעד עם כיוון פסקה RTL (ב-Word: Ctrl+Shift+חץ ימין, ב-Google Docs: Format → Paragraph direction). בלי זה, גם טקסט מתוקן עלול «להיראות» LTR.

לגבי מבוא: מפתחים שבונים pipeline לייבוא מסמכים עבריים — הפרידו בין נרמול BiDi לבין היפוך מחרוזת. נרמול ≠ היפוך. בדקו עם «שלום» → «םולש» → reverse → «שלום». regression test ב-CI.

תרחיש יומיומי (מבוא): עורך תוכן מעתיק ציטוט ממאמר PDF לאתר WordPress. הדבקה → «םיללכ םע םולש» → תיקלוד reverse → «שלום עם כללים» → הדבקה לבלוק → RTL → פרסום. דקה אחת.

נגישות (מבוא): קוראי מסך (NVDA, JAWS, VoiceOver) קוראים לפי סדר לוגי. הדבקה שגויה = חוויה שבורה לעיוורים. תיקון reverse לפני פרסום — חובה אתית, לא רק אסתטיקה.

ארגונים (מבוא): הוסיפו ל-playbook תמיכה — «טקסט הפוך מ-PDF? תיקלוד reverse, לא התקנה מחדש של Windows». חוסך tickets.

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

סיכום ביניים ל-מבוא: שמרו tiklud.com בסימניות, למדו לזהות «םולש» מול «akuo», ובדקו כיוון פסקה ב-Word אחרי כל תיקון. שלושה צעדים — workflow שעובד.

RTL (Right-to-Left) ו-LTR (Left-to-Right) הם כיווני כתיבה. עברית, ערבית, ופרסית — RTL: השורה מתחילה מימין, הטקסט «זורם» שמאלה. אנגלית, רוסית, סינית — LTR: השורה מתחילה משמאל. כשאתם מקלידים בעברית ב-Word או Gmail, האפליקציה מגדירה כיוון פסקה RTL, והמנוע מסדר את התווים בהתאם.

בהדבקה, הבעיה מתחילה כשמקור ויעד לא מסכימים על «מהו הסדר הנכון». PDF לעיתים שומר visual order — מה שראיתם על המסך — ולא logical order — מה שהמחשב «חושב» שסדר האותיות. Word ישן עלול לשמור סימן LTR. אתר באנגלית שמכיל משפט עברי אחד — אלגוריתם BiDi של Unicode מנסה לסדר, אבל ההדבקה ל-Word עלולה לשבור את הסדר.

מספרים וסימני פיסוק — ברוב המקרים LTR — גם בתוך משפט עברי. «2026» נשאר 2026. נקודה בסוף משפט עברי — לרוב בצד שמאל ויזואלית. כשסדר התווים מתהפך, גם המספרים והפיסוק «קופצים».

בממשק משתמש, RTL משפיע על יישור: עברית מיושרת לימין. LTR — לשמאל. כשמדביקים טקסט עם סימנים שגויים, היישור «נראה» נכון אבל סדר האותיות בתוך המילה — לא.

מערכות הפעלה: Windows, macOS, iOS, Android — כולן תומכות RTL באופן מובנה. אבל קוראי PDF, עורכים ישנים, וכלים של צד שלישי — לא תמיד. לכן אותה הדבקה «עובדת» ב-Gmail ו«נשברת» ב-Notepad++.

הבחנה קריטית: כיוון פסקה (paragraph direction) שונה מסדר תווים (character order) ושונה משכבת מקלדת (keyboard layout). מדריך זה מתמקד בשניים הראשונים; לשכבה — ראו מאמרים נוספים בבלוג תיקלוד.

בישראל, משתמשים דו-לשוניים עוברים בין RTL ל-LTR עשרות פעמים ביום. כל מעבר הוא נקודת כשל פוטנציאלית — במיוחד בהדבקה, כי ההדבקה לא «שואלת» אתכם באיזה כיוון המקור נוצר.

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

RTL אינו «היפוך» של LTR — אלו שני מצבי baseline שונים. Unicode מגדיר strong, weak, ו-neutral characters. עברית strong RTL; ספרות weak; רווח neutral. אלגוריתם BiDi משלב את הכל.

פרק 2 במדריך זה (RTL ו-LTR: מה ההבדל הבסיסי ולמה זה משנה בהדבקה) מדגיש שהדבקה אינה «העתקה» פשוטה — היא העברה של קידוד, מטא-דאטה של כיוון, ולעיתים סדר גליפים ויזואלי. משתמשים מנוסים בישראל למדו לבדוק את המשפט הראשון אחרי כל הדבקה מ-PDF. אם המילה הראשונה לא הגיונית — עצרו לפני המשך עריכה.

בנושא RTL ו-LTR: מה ההבדל הבסיסי ולמה זה משנה בהדבקה, חשוב לזכור שתיקלוד לא מחליף עורך מסמכים — הוא כלי ביניים. אחרי «הפוך כיוון» או «המרה», תמיד הדביקו ליעד עם כיוון פסקה RTL (ב-Word: Ctrl+Shift+חץ ימין, ב-Google Docs: Format → Paragraph direction). בלי זה, גם טקסט מתוקן עלול «להיראות» LTR.

לגבי RTL ו-LTR: מה ההבדל הבסיסי ולמה זה משנה בהדבקה: מפתחים שבונים pipeline לייבוא מסמכים עבריים — הפרידו בין נרמול BiDi לבין היפוך מחרוזת. נרמול ≠ היפוך. בדקו עם «שלום» → «םולש» → reverse → «שלום». regression test ב-CI.

תרחיש יומיומי (RTL ו-LTR: מה ההבדל הבסיסי ולמה זה משנה בהדבקה): עורך תוכן מעתיק ציטוט ממאמר PDF לאתר WordPress. הדבקה → «םיללכ םע םולש» → תיקלוד reverse → «שלום עם כללים» → הדבקה לבלוק → RTL → פרסום. דקה אחת.

נגישות (RTL ו-LTR: מה ההבדל הבסיסי ולמה זה משנה בהדבקה): קוראי מסך (NVDA, JAWS, VoiceOver) קוראים לפי סדר לוגי. הדבקה שגויה = חוויה שבורה לעיוורים. תיקון reverse לפני פרסום — חובה אתית, לא רק אסתטיקה.

ארגונים (RTL ו-LTR: מה ההבדל הבסיסי ולמה זה משנה בהדבקה): הוסיפו ל-playbook תמיכה — «טקסט הפוך מ-PDF? תיקלוד reverse, לא התקנה מחדש של Windows». חוסך tickets.

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

סיכום ביניים ל-RTL ו-LTR: מה ההבדל הבסיסי ולמה זה משנה בהדבקה: שמרו tiklud.com בסימניות, למדו לזהות «םולש» מול «akuo», ובדקו כיוון פסקה ב-Word אחרי כל תיקון. שלושה צעדים — workflow שעובד.

Unicode BiDi Algorithm (UAX #9) הוא הסטנדרט שמגדיר איך מערכות מציגות טקסט מעורב RTL ו-LTR. כשמשפט מכיל «שלום world» — האלגוריתם מזהה בלוקים: «שלום» RTL, רווח neutral, «world» LTR. כל בלוק מוצג בכיוון שלו; הסדר הכולל נקבע לפי כיוון הבסis של הפסקה.

Strong characters: אותיות עבריות — RTL strong. אותיות לatin — LTR strong. Weak: מספרים. Neutral: רווחים, פיסוק רב. האלגוריתם סורק את המחרוזת, מחלק ל-runs, ומסדר מחדש לתצוגה — בלי לשנות בהכרח את סדר ה-bytes בזיכרון.

כשמדביקים, לפעמים מגיעים גם תווי בקרה: U+200E (LRM), U+200F (RLM), U+202A–U+202E (embedding overrides). הם «מכריחים» כיוון לקטע. PDF ו-OCR לעיתים מוסיפים או מאבדים אותם — ואז ההדבקה נראית שונה מהמקור.

Mixed Hebrew-English במייל: «נא לשלוח ל-info@company.com עד יום חמישי» — BiDi מסדר נכון ברוב הדפדפנים. אבל אם הסדר ב-buffer הפוך — «יsimח» במקום «חמישי» — צריך reverse, לא תיקון BiDi.

מפתחים: `dir="rtl"` ב-HTML, `direction: rtl` ב-CSS, מאפייני bidi ב-Win32 — שכבות שונות. הדבקה מ-HTML ל-Word מעתיקה לפעמים style, לפעמים רק plain text — התוצאה שונה.

ערבית ועברית — שניהם RTL, אבל תיקלוד תומך גם בערבית (בטא) להמרת שכבה. BiDi דומה; ההבדלים בצורת האותיות, לא בכיוון.

למידה: אם רואים «עברית הפוכה» — שאלו: האם כל מילה הפוכה בתוך עצמה, או שהמילים בסדר הפוך? «םולש» = reverse chars. «חמישי יום» = סדר מילים הפוך (נדיר) או artifact של הדבקה.

אלגוריתם BiDi נכנס לפעולה בשלב התצוגה (rendering). הוא לא «מתקן» טקסט שהועתק בסדר visual order — הוא מניח שה-buffer כבר logical. לכן paste מ-PDF הוא out-of-band ל-BiDi.

בדפדפנים מודרניים, `getSelection().toString()` מחזיר לרוב logical order. אבל PDF viewers ויישומי desktop ישנים — לא תמיד. זו הסיבה שאין «כלל אחד» לכל מקור.

פרק 3 במדריך זה (טקסט דו-כיווני (Bidirectional Text): איך Unicode מסדר עברית ואנגלית יחד) מדגיש שהדבקה אינה «העתקה» פשוטה — היא העברה של קידוד, מטא-דאטה של כיוון, ולעיתים סדר גליפים ויזואלי. משתמשים מנוסים בישראל למדו לבדוק את המשפט הראשון אחרי כל הדבקה מ-PDF. אם המילה הראשונה לא הגיונית — עצרו לפני המשך עריכה.

בנושא טקסט דו-כיווני (Bidirectional Text): איך Unicode מסדר עברית ואנגלית יחד, חשוב לזכור שתיקלוד לא מחליף עורך מסמכים — הוא כלי ביניים. אחרי «הפוך כיוון» או «המרה», תמיד הדביקו ליעד עם כיוון פסקה RTL (ב-Word: Ctrl+Shift+חץ ימין, ב-Google Docs: Format → Paragraph direction). בלי זה, גם טקסט מתוקן עלול «להיראות» LTR.

לגבי טקסט דו-כיווני (Bidirectional Text): איך Unicode מסדר עברית ואנגלית יחד: מפתחים שבונים pipeline לייבוא מסמכים עבריים — הפרידו בין נרמול BiDi לבין היפוך מחרוזת. נרמול ≠ היפוך. בדקו עם «שלום» → «םולש» → reverse → «שלום». regression test ב-CI.

תרחיש יומיומי (טקסט דו-כיווני (Bidirectional Text): איך Unicode מסדר עברית ואנגלית יחד): עורך תוכן מעתיק ציטוט ממאמר PDF לאתר WordPress. הדבקה → «םיללכ םע םולש» → תיקלוד reverse → «שלום עם כללים» → הדבקה לבלוק → RTL → פרסום. דקה אחת.

נגישות (טקסט דו-כיווני (Bidirectional Text): איך Unicode מסדר עברית ואנגלית יחד): קוראי מסך (NVDA, JAWS, VoiceOver) קוראים לפי סדר לוגי. הדבקה שגויה = חוויה שבורה לעיוורים. תיקון reverse לפני פרסום — חובה אתית, לא רק אסתטיקה.

ארגונים (טקסט דו-כיווני (Bidirectional Text): איך Unicode מסדר עברית ואנגלית יחד): הוסיפו ל-playbook תמיכה — «טקסט הפוך מ-PDF? תיקלוד reverse, לא התקנה מחדש של Windows». חוסך tickets.

עוד נקודה על טקסט דו-כיווני (Bidirectional Text): איך Unicode מסדר עברית ואנגלית יחד: בישראל, מיליוני משתמשים מעתיקים טקסט מדי יום מקבצי PDF, מיילים, וואטסאפ, ואתרי חדשות. הבנה של ההבדל בין RTL, LTR, BiDi, ושכבת מקלדת — מפחיתה תסכול ומונעת שליחת מסמכים מקולקלים ללקוחות.

סיכום ביניים ל-טקסט דו-כיווני (Bidirectional Text): איך Unicode מסדר עברית ואנגלית יחד: שמרו tiklud.com בסימניות, למדו לזהות «םולש» מול «akuo», ובדקו כיוון פסקה ב-Word אחרי כל תיקון. שלושה צעדים — workflow שעובד.

Logical order: הסדר שבו התווים «אמורים» להיקרא — של-ו-ם. Visual order: הסדר שבו הם מופיעים פיזית על המסך מימין לשמאל — ם-ו-ל-ש (במקרה של טקסט שגוי). PDF לעיתים נוצר מ-OCR או מ-flattened text — ושומר visual order כי כך «נראה נכון» ב-viewer.

כשמעתיקים מ-PDF, clipboard מקבל לעיתים visual order. מדביקים ל-Word — Word מנסה BiDi — ויוצא בלגן. «הפתרון» של משתמשים רבים: הקלדה מחדש. הפתרון הנכון: הדבקה ל-tiklud.com → «הפוך כיוון» → העתקה חזרה.

סריקות ישנות: טקסט עברי מימין, אבל layer של הטקסט נשמר כ-LTR stream. Adobe Reader, Foxit, דפדפנים — כל אחד מעתיק differently. אין «PDF אחד שתמיד עובד».

Word «Save as PDF» ואז copy back — לפעמים round-trip שובר כיוון. Google Docs → PDF → copy — אותה בעיה. המקור הכי בטוח: קובץ DOCX מקורי, לא PDF.

כלי OCR (ABBYY, Google Vision): output עברי לפעמים reversed character stream. בדיקה: אם «שלום» יוצא «םולש» — reverse. אם «akuo» — keyboard layer.

Visual vs logical — דוגמה: שורה «123 שלום» — logical: 123 (LTR) + space + שלום (RTL). Visual on screen: שלום מימין, 123 משמאל לו. Reverse entire string wrongly → «םולש 321».

טיפ: הדביקו ל-Notepad (plain) קודם — אם גם שם הפוך, הבעיה ב-character order. אם Notepad OK אבל Word לא — paragraph direction ב-Word.

מסמכים ארכיוניים: ספרים דigitized, עיתונים ישנים, פרוטokolים — כולם מקורות נפוצים ל-visual order. ארגונים שdigitalize ארכיון — חייבים pipeline תיקון.

OCR על עברית handwritten — סדר תווים almost always broken. reverse + manual proof — standard workflow.

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

בנושא סדר לוגי מול סדר ויזואלי: למה PDF ו-OCR «מרמים», חשוב לזכור שתיקלוד לא מחליף עורך מסמכים — הוא כלי ביניים. אחרי «הפוך כיוון» או «המרה», תמיד הדביקו ליעד עם כיוון פסקה RTL (ב-Word: Ctrl+Shift+חץ ימין, ב-Google Docs: Format → Paragraph direction). בלי זה, גם טקסט מתוקן עלול «להיראות» LTR.

לגבי סדר לוגי מול סדר ויזואלי: למה PDF ו-OCR «מרמים»: מפתחים שבונים pipeline לייבוא מסמכים עבריים — הפרידו בין נרמול BiDi לבין היפוך מחרוזת. נרמול ≠ היפוך. בדקו עם «שלום» → «םולש» → reverse → «שלום». regression test ב-CI.

תרחיש יומיומי (סדר לוגי מול סדר ויזואלי: למה PDF ו-OCR «מרמים»): עורך תוכן מעתיק ציטוט ממאמר PDF לאתר WordPress. הדבקה → «םיללכ םע םולש» → תיקלוד reverse → «שלום עם כללים» → הדבקה לבלוק → RTL → פרסום. דקה אחת.

נגישות (סדר לוגי מול סדר ויזואלי: למה PDF ו-OCR «מרמים»): קוראי מסך (NVDA, JAWS, VoiceOver) קוראים לפי סדר לוגי. הדבקה שגויה = חוויה שבורה לעיוורים. תיקון reverse לפני פרסום — חובה אתית, לא רק אסתטיקה.

ארגונים (סדר לוגי מול סדר ויזואלי: למה PDF ו-OCR «מרמים»): הוסיפו ל-playbook תמיכה — «טקסט הפוך מ-PDF? תיקלוד reverse, לא התקנה מחדש של Windows». חוסך tickets.

עוד נקודה על סדר לוגי מול סדר ויזואלי: למה PDF ו-OCR «מרמים»: בישראל, מיליוני משתמשים מעתיקים טקסט מדי יום מקבצי PDF, מיילים, וואטסאפ, ואתרי חדשות. הבנה של ההבדל בין RTL, LTR, BiDi, ושכבת מקלדת — מפחיתה תסכול ומונעת שליחת מסמכים מקולקלים ללקוחות.

סיכום ביניים ל-סדר לוגי מול סדר ויזואלי: למה PDF ו-OCR «מרמים»: שמרו tiklud.com בסימניות, למדו לזהות «םולש» מול «akuo», ובדקו כיוון פסקה ב-Word אחרי כל תיקון. שלושה צעדים — workflow שעובד.

PDF הוא פורמט תצוגה — לא עריכה. text layer יכול להיות ב-any order. Copy-paste הוא «best effort». ספרים, חוזים, מאמרים אקדמיים, דוחות ממשלתיים — כולם מקור נפוץ לטקסט עברי «שבור».

סימפטום 1: כל המילה הפוכה — «תודה» → «הדות». סימפטום 2: אותיות נפרדות בסדר מוזר — «ש ל ו ם» עם רווחים. סימפטום 3: עברית + אנגלית — האנגלית «קופצת» באמצע. סימפטום 4: מספרים בסדר הפוך — 6202 במקום 2026.

Adobe Acrobat: Edit → Copy. לפעמים «Copy with formatting» vs plain — נסו plain. Chrome PDF viewer — often worse. Desktop app — often better.

פתרון workflow: (1) Copy from PDF. (2) Paste to tiklud.com input. (3) If gibberish latin — «המרה» HE. (4) If hebrew chars reversed — «הפוך כיוון». (5) Copy output. (6) Paste to Word with RTL paragraph.

מסמכים משפטיים: טעות בסדר תווים = סיכון. תמיד verify after fix. «בעל» vs «לעב» — reverse partial.

PDF from Hebrew Word: usually better than scan. Still test paste. PDF/A archival — text extraction varies by tool.

ארגונים: template «הדבקה מ-PDF» — mandatory pass through tiklud for public-facing text.

Accessibility: screen readers קוראים logical order. Visual order paste breaks accessibility — fix matters beyond cosmetics.

PDF עם שכבות (layers): copy from wrong layer — gibberish. בדקו layer panel ב-Acrobat Pro.

טקסט מ-PDF מוגן (password, no copy): אין shortcut — OCR external. OCR → reverse likely needed.

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

בנושא הדבקה מ-PDF: הסיבות, הסימפטומים, והפתרון, חשוב לזכור שתיקלוד לא מחליף עורך מסמכים — הוא כלי ביניים. אחרי «הפוך כיוון» או «המרה», תמיד הדביקו ליעד עם כיוון פסקה RTL (ב-Word: Ctrl+Shift+חץ ימין, ב-Google Docs: Format → Paragraph direction). בלי זה, גם טקסט מתוקן עלול «להיראות» LTR.

לגבי הדבקה מ-PDF: הסיבות, הסימפטומים, והפתרון: מפתחים שבונים pipeline לייבוא מסמכים עבריים — הפרידו בין נרמול BiDi לבין היפוך מחרוזת. נרמול ≠ היפוך. בדקו עם «שלום» → «םולש» → reverse → «שלום». regression test ב-CI.

תרחיש יומיומי (הדבקה מ-PDF: הסיבות, הסימפטומים, והפתרון): עורך תוכן מעתיק ציטוט ממאמר PDF לאתר WordPress. הדבקה → «םיללכ םע םולש» → תיקלוד reverse → «שלום עם כללים» → הדבקה לבלוק → RTL → פרסום. דקה אחת.

נגישות (הדבקה מ-PDF: הסיבות, הסימפטומים, והפתרון): קוראי מסך (NVDA, JAWS, VoiceOver) קוראים לפי סדר לוגי. הדבקה שגויה = חוויה שבורה לעיוורים. תיקון reverse לפני פרסום — חובה אתית, לא רק אסתטיקה.

ארגונים (הדבקה מ-PDF: הסיבות, הסימפטומים, והפתרון): הוסיפו ל-playbook תמיכה — «טקסט הפוך מ-PDF? תיקלוד reverse, לא התקנה מחדש של Windows». חוסך tickets.

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

סיכום ביניים ל-הדבקה מ-PDF: הסיבות, הסימפטומים, והפתרון: שמרו tiklud.com בסימניות, למדו לזהות «םולש» מול «akuo», ובדקו כיוון פסקה ב-Word אחרי כל תיקון. שלושה צעדים — workflow שעובד.

Word מציע אפשרויות הדבקה: Keep Source Formatting (K), Merge Formatting (M), Keep Text Only (T), Picture. כל אחת מעבירה metadata שונה — כולל bidi marks, styles, language tags.

הדבקה מ-Word ישן (.doc) ל-Word חדש — charset ו-direction markers עלולים להתנגש. «הפוך כיוון» אחרי Paste Text Only — often fixes.

Ctrl+Shift+Right/Left Arrow — ב-Word משנה כיוון פסקה. לא reverse characters. אם האותיות «םולש» — Ctrl+Shift לא יעזור.

Styles: «Normal» LTR vs «Hebrew» RTL style. הדבקה עם style LTR לתוך doc RTL — paragraph OK אבל inline order wrong.

Tables in Word: cells have direction per cell. Paste row from PDF into table — cell direction inheritance mess.

Word Online vs Desktop: paste behavior differs. Teams chat copy from Word Desktop — test target.

Macro/VBA: `.Range.Text = reversed` — developers; users use tiklud.

Best practice: Paste Text Only → tiklud reverse if needed → Apply Hebrew style → Set paragraph RTL.

Word «Show/Hide ¶» — reveals paragraph marks. bidi marks invisible — Notepad++ hex for debug.

Linked styles from template — Hebrew doc template with RTL default reduces paste pain.

פרק 6 במדריך זה (הדבקה מ-Word: Keep Source Formatting, Merge, ו-Text Only) מדגיש שהדבקה אינה «העתקה» פשוטה — היא העברה של קידוד, מטא-דאטה של כיוון, ולעיתים סדר גליפים ויזואלי. משתמשים מנוסים בישראל למדו לבדוק את המשפט הראשון אחרי כל הדבקה מ-PDF. אם המילה הראשונה לא הגיונית — עצרו לפני המשך עריכה.

בנושא הדבקה מ-Word: Keep Source Formatting, Merge, ו-Text Only, חשוב לזכור שתיקלוד לא מחליף עורך מסמכים — הוא כלי ביניים. אחרי «הפוך כיוון» או «המרה», תמיד הדביקו ליעד עם כיוון פסקה RTL (ב-Word: Ctrl+Shift+חץ ימין, ב-Google Docs: Format → Paragraph direction). בלי זה, גם טקסט מתוקן עלול «להיראות» LTR.

לגבי הדבקה מ-Word: Keep Source Formatting, Merge, ו-Text Only: מפתחים שבונים pipeline לייבוא מסמכים עבריים — הפרידו בין נרמול BiDi לבין היפוך מחרוזת. נרמול ≠ היפוך. בדקו עם «שלום» → «םולש» → reverse → «שלום». regression test ב-CI.

תרחיש יומיומי (הדבקה מ-Word: Keep Source Formatting, Merge, ו-Text Only): עורך תוכן מעתיק ציטוט ממאמר PDF לאתר WordPress. הדבקה → «םיללכ םע םולש» → תיקלוד reverse → «שלום עם כללים» → הדבקה לבלוק → RTL → פרסום. דקה אחת.

נגישות (הדבקה מ-Word: Keep Source Formatting, Merge, ו-Text Only): קוראי מסך (NVDA, JAWS, VoiceOver) קוראים לפי סדר לוגי. הדבקה שגויה = חוויה שבורה לעיוורים. תיקון reverse לפני פרסום — חובה אתית, לא רק אסתטיקה.

ארגונים (הדבקה מ-Word: Keep Source Formatting, Merge, ו-Text Only): הוסיפו ל-playbook תמיכה — «טקסט הפוך מ-PDF? תיקלוד reverse, לא התקנה מחדש של Windows». חוסך tickets.

עוד נקודה על הדבקה מ-Word: Keep Source Formatting, Merge, ו-Text Only: בישראל, מיליוני משתמשים מעתיקים טקסט מדי יום מקבצי PDF, מיילים, וואטסאפ, ואתרי חדשות. הבנה של ההבדל בין RTL, LTR, BiDi, ושכבת מקלדת — מפחיתה תסכול ומונעת שליחת מסמכים מקולקלים ללקוחות.

סיכום ביניים ל-הדבקה מ-Word: Keep Source Formatting, Merge, ו-Text Only: שמרו tiklud.com בסימניות, למדו לזהות «םולש» מול «akuo», ובדקו כיוון פסקה ב-Word אחרי כל תיקון. שלושה צעדים — workflow שעובד.

Web pages: HTML `dir=rtl` on `<html>` or `<body>`. Copy selection — browser puts plain text + sometimes HTML on clipboard. Paste to Word — Word parses HTML bidi.

Facebook, LinkedIn posts Hebrew — copy often OK in browser, breaks in email client. WhatsApp Web — RTL auto when Hebrew detected; paste from WhatsApp to Word — usually OK unless message was layer-wrong.

Google Translate output Hebrew — copy «translation» — sometimes odd bidi. Don't use Translate for keyboard gibberish.

Wikipedia Hebrew: generally good logical order. Infobox mixed EN/HE — careful with paste.

CMS (WordPress, Wix): editor blocks. Paste from Google Docs — hidden spans. «Clear formatting» then tiklud if needed.

Email newsletters RTL: some use tables for layout. Copy — visual order junk. View in browser → select carefully → paste plain.

Developer tools: copy from DevTools console Hebrew string — usually logical. Copy from rendered page — visual.

Chrome vs Firefox vs Safari — clipboard HTML differs slightly. If one browser fails, try another for copy source.

Medium, Substack — LTR platform, Hebrew posts — paste to Word needs RTL paragraph after.

Copy from mobile browser — iOS Share → copy — sometimes strips bidi. test before long paste.

פרק 7 במדריך זה (הדבקה מהאינternet: דפדפנים, CMS, ורשתות חברתיות) מדגיש שהדבקה אינה «העתקה» פשוטה — היא העברה של קידוד, מטא-דאטה של כיוון, ולעיתים סדר גליפים ויזואלי. משתמשים מנוסים בישראל למדו לבדוק את המשפט הראשון אחרי כל הדבקה מ-PDF. אם המילה הראשונה לא הגיונית — עצרו לפני המשך עריכה.

בנושא הדבקה מהאינternet: דפדפנים, CMS, ורשתות חברתיות, חשוב לזכור שתיקלוד לא מחליף עורך מסמכים — הוא כלי ביניים. אחרי «הפוך כיוון» או «המרה», תמיד הדביקו ליעד עם כיוון פסקה RTL (ב-Word: Ctrl+Shift+חץ ימין, ב-Google Docs: Format → Paragraph direction). בלי זה, גם טקסט מתוקן עלול «להיראות» LTR.

לגבי הדבקה מהאינternet: דפדפנים, CMS, ורשתות חברתיות: מפתחים שבונים pipeline לייבוא מסמכים עבריים — הפרידו בין נרמול BiDi לבין היפוך מחרוזת. נרמול ≠ היפוך. בדקו עם «שלום» → «םולש» → reverse → «שלום». regression test ב-CI.

תרחיש יומיומי (הדבקה מהאינternet: דפדפנים, CMS, ורשתות חברתיות): עורך תוכן מעתיק ציטוט ממאמר PDF לאתר WordPress. הדבקה → «םיללכ םע םולש» → תיקלוד reverse → «שלום עם כללים» → הדבקה לבלוק → RTL → פרסום. דקה אחת.

נגישות (הדבקה מהאינternet: דפדפנים, CMS, ורשתות חברתיות): קוראי מסך (NVDA, JAWS, VoiceOver) קוראים לפי סדר לוגי. הדבקה שגויה = חוויה שבורה לעיוורים. תיקון reverse לפני פרסום — חובה אתית, לא רק אסתטיקה.

ארגונים (הדבקה מהאינternet: דפדפנים, CMS, ורשתות חברתיות): הוסיפו ל-playbook תמיכה — «טקסט הפוך מ-PDF? תיקלוד reverse, לא התקנה מחדש של Windows». חוסך tickets.

עוד נקודה על הדבקה מהאינternet: דפדפנים, CMS, ורשתות חברתיות: בישראל, מיליוני משתמשים מעתיקים טקסט מדי יום מקבצי PDF, מיילים, וואטסאפ, ואתרי חדשות. הבנה של ההבדל בין RTL, LTR, BiDi, ושכבת מקלדת — מפחיתה תסכול ומונעת שליחת מסמכים מקולקלים ללקוחות.

סיכום ביניים ל-הדבקה מהאינternet: דפדפנים, CMS, ורשתות חברתיות: שמרו tiklud.com בסימניות, למדו לזהות «םולש» מול «akuo», ובדקו כיוון פסקה ב-Word אחרי כל תיקון. שלושה צעדים — workflow שעובד.

Reversed character order: המחרוזת בזיכרון היא mirror של intended. «שלום» stored as «םולש». קריאה משמאל לימין נותנת gibberish; קריאה מימין לשמאל — almost correct per char but wrong word.

Test: compare first char. «שלום» starts with ש (right side visually). Reversed starts with ם. Quick eye test.

Causes: PDF visual order, some OCR, old databases exported wrong, bug in custom software, manual «reverse string» mistake.

NOT reversed: keyboard layer «akuo» — those are latin letters, different fix (convert). NOT reversed: «hello» when you wanted English — layer.

NOT reversed: paragraph starts left — Word paragraph direction. Fix in app.

תיקלוד «הפוך כיוון»: uses Intl.Segmenter when available — grapheme-aware — important for emoji and combining marks. Hebrew letters — simple reverse.

Double reverse: if you reverse twice — back to wrong. Undo or re-paste original.

Partial reverse: select only broken sentence, not whole doc — safer.

Heuristic: if first Hebrew letter is final form (ם ן ץ ף ך) — likely reversed. «םולש» starts with ם — red flag.

Long documents: fix paragraph by paragraph — easier to spot which sections broken.

פרק 8 במדריך זה (סדר תווים הפוך (Reversed Character Order): זיהוי ותיקון) מדגיש שהדבקה אינה «העתקה» פשוטה — היא העברה של קידוד, מטא-דאטה של כיוון, ולעיתים סדר גליפים ויזואלי. משתמשים מנוסים בישראל למדו לבדוק את המשפט הראשון אחרי כל הדבקה מ-PDF. אם המילה הראשונה לא הגיונית — עצרו לפני המשך עריכה.

בנושא סדר תווים הפוך (Reversed Character Order): זיהוי ותיקון, חשוב לזכור שתיקלוד לא מחליף עורך מסמכים — הוא כלי ביניים. אחרי «הפוך כיוון» או «המרה», תמיד הדביקו ליעד עם כיוון פסקה RTL (ב-Word: Ctrl+Shift+חץ ימין, ב-Google Docs: Format → Paragraph direction). בלי זה, גם טקסט מתוקן עלול «להיראות» LTR.

לגבי סדר תווים הפוך (Reversed Character Order): זיהוי ותיקון: מפתחים שבונים pipeline לייבוא מסמכים עבריים — הפרידו בין נרמול BiDi לבין היפוך מחרוזת. נרמול ≠ היפוך. בדקו עם «שלום» → «םולש» → reverse → «שלום». regression test ב-CI.

תרחיש יומיומי (סדר תווים הפוך (Reversed Character Order): זיהוי ותיקון): עורך תוכן מעתיק ציטוט ממאמר PDF לאתר WordPress. הדבקה → «םיללכ םע םולש» → תיקלוד reverse → «שלום עם כללים» → הדבקה לבלוק → RTL → פרסום. דקה אחת.

נגישות (סדר תווים הפוך (Reversed Character Order): זיהוי ותיקון): קוראי מסך (NVDA, JAWS, VoiceOver) קוראים לפי סדר לוגי. הדבקה שגויה = חוויה שבורה לעיוורים. תיקון reverse לפני פרסום — חובה אתית, לא רק אסתטיקה.

ארגונים (סדר תווים הפוך (Reversed Character Order): זיהוי ותיקון): הוסיפו ל-playbook תמיכה — «טקסט הפוך מ-PDF? תיקלוד reverse, לא התקנה מחדש של Windows». חוסך tickets.

עוד נקודה על סדר תווים הפוך (Reversed Character Order): זיהוי ותיקון: בישראל, מיליוני משתמשים מעתיקים טקסט מדי יום מקבצי PDF, מיילים, וואטסאפ, ואתרי חדשות. הבנה של ההבדל בין RTL, LTR, BiDi, ושכבת מקלדת — מפחיתה תסכול ומונעת שליחת מסמכים מקולקלים ללקוחות.

סיכום ביניים ל-סדר תווים הפוך (Reversed Character Order): זיהוי ותיקון: שמרו tiklud.com בסימניות, למדו לזהות «םולש» מול «akuo», ובדקו כיוון פסקה ב-Word אחרי כל תיקון. שלושה צעדים — workflow שעובד.

Mixed text is daily reality: «Meeting ב-14:00», «API של החברה», «גרסה 2.0 released». BiDi handles most — until paste introduces wrong order.

URLs and emails LTR always: info@tiklud.com stays LTR inside RTL sentence. If reversed entire line — URL breaks.

Numbers: 2026, phone 050-1234567 — LTR digits. Reversing whole string breaks phones.

Parentheses: «(see appendix)» in English inside Hebrew — nesting levels in BiDi. Paste corruption → unbalanced parens.

Code snippets in Hebrew doc: `const x = 1` — keep LTR. Selective reverse — don't reverse code block.

Acronyms: HTML, PDF, RTL — LTR. «שימוש ב-RTL בעברית» — correct mixed.

Fix strategy: paste to tiklud → reverse if needed → if only part wrong, fix part manually. Or split: Hebrew segment reverse, English segment leave.

Excel: cells mixed. CSV export — encoding + order. Paste column to Word — test cell by cell.

Hashtags #עברית — BiDi edge case. Social paste — verify hashtag clickable.

Version numbers v2.1.0 — don't reverse whole line if contains semver.

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

בנושא טקסט מעורב עברית-אנגלית: מלכודות BiDi בהדבקה, חשוב לזכור שתיקלוד לא מחליף עורך מסמכים — הוא כלי ביניים. אחרי «הפוך כיוון» או «המרה», תמיד הדביקו ליעד עם כיוון פסקה RTL (ב-Word: Ctrl+Shift+חץ ימין, ב-Google Docs: Format → Paragraph direction). בלי זה, גם טקסט מתוקן עלול «להיראות» LTR.

לגבי טקסט מעורב עברית-אנגלית: מלכודות BiDi בהדבקה: מפתחים שבונים pipeline לייבוא מסמכים עבריים — הפרידו בין נרמול BiDi לבין היפוך מחרוזת. נרמול ≠ היפוך. בדקו עם «שלום» → «םולש» → reverse → «שלום». regression test ב-CI.

תרחיש יומיומי (טקסט מעורב עברית-אנגלית: מלכודות BiDi בהדבקה): עורך תוכן מעתיק ציטוט ממאמר PDF לאתר WordPress. הדבקה → «םיללכ םע םולש» → תיקלוד reverse → «שלום עם כללים» → הדבקה לבלוק → RTL → פרסום. דקה אחת.

נגישות (טקסט מעורב עברית-אנגלית: מלכודות BiDi בהדבקה): קוראי מסך (NVDA, JAWS, VoiceOver) קוראים לפי סדר לוגי. הדבקה שגויה = חוויה שבורה לעיוורים. תיקון reverse לפני פרסום — חובה אתית, לא רק אסתטיקה.

ארגונים (טקסט מעורב עברית-אנגלית: מלכודות BiDi בהדבקה): הוסיפו ל-playbook תמיכה — «טקסט הפוך מ-PDF? תיקלוד reverse, לא התקנה מחדש של Windows». חוסך tickets.

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

סיכום ביניים ל-טקסט מעורב עברית-אנגלית: מלכודות BiDi בהדבקה: שמרו tiklud.com בסימניות, למדו לזהות «םולש» מול «akuo», ובדקו כיוון פסקה ב-Word אחרי כל תיקון. שלושה צעדים — workflow שעובד.

U+200F RLM (Right-to-Left Mark): zero-width, forces RTL context. U+200E LRM: LTR. Invisible but affect paste.

U+202B RTL Embedding, U+202A LTR Embedding — start embedded direction. U+202C Pop — end. Word sometimes inserts on paste.

Show in editor: Word «Show formatting marks» — won't show RLM. Notepad++ with «Show all characters» — hex view.

Strip invisible: paste plain to Notepad, or find-replace in advanced editors. tiklud reverse works on visible chars; invisible may remain — rare issue.

Copy from PDF with RLM flood — paste looks «almost» right but breaks search. Strip and reverse.

Security: bidi override attacks (Trojan Source) — U+202E can display code misleadingly. Developers aware; paste from untrusted PDF — caution.

Normalization NFC/NFD — Hebrew usually stable. Not main paste issue.

Tip: if search «שלום» fails but looks correct — invisible chars or wrong order. Paste to tiklud, re-copy clean.

Word Find/Replace ^w for spaces — won't remove RLM. Use hex editor or specialized strip tool.

Powershell: inspect `[int][char]$c` per char — debug paste pipeline.

פרק 10 במדריך זה (תווי בקרה נסתרים: RLM, LRM, ו-Embedding) מדגיש שהדבקה אינה «העתקה» פשוטה — היא העברה של קידוד, מטא-דאטה של כיוון, ולעיתים סדר גליפים ויזואלי. משתמשים מנוסים בישראל למדו לבדוק את המשפט הראשון אחרי כל הדבקה מ-PDF. אם המילה הראשונה לא הגיונית — עצרו לפני המשך עריכה.

בנושא תווי בקרה נסתרים: RLM, LRM, ו-Embedding, חשוב לזכור שתיקלוד לא מחליף עורך מסמכים — הוא כלי ביניים. אחרי «הפוך כיוון» או «המרה», תמיד הדביקו ליעד עם כיוון פסקה RTL (ב-Word: Ctrl+Shift+חץ ימין, ב-Google Docs: Format → Paragraph direction). בלי זה, גם טקסט מתוקן עלול «להיראות» LTR.

לגבי תווי בקרה נסתרים: RLM, LRM, ו-Embedding: מפתחים שבונים pipeline לייבוא מסמכים עבריים — הפרידו בין נרמול BiDi לבין היפוך מחרוזת. נרמול ≠ היפוך. בדקו עם «שלום» → «םולש» → reverse → «שלום». regression test ב-CI.

תרחיש יומיומי (תווי בקרה נסתרים: RLM, LRM, ו-Embedding): עורך תוכן מעתיק ציטוט ממאמר PDF לאתר WordPress. הדבקה → «םיללכ םע םולש» → תיקלוד reverse → «שלום עם כללים» → הדבקה לבלוק → RTL → פרסום. דקה אחת.

נגישות (תווי בקרה נסתרים: RLM, LRM, ו-Embedding): קוראי מסך (NVDA, JAWS, VoiceOver) קוראים לפי סדר לוגי. הדבקה שגויה = חוויה שבורה לעיוורים. תיקון reverse לפני פרסום — חובה אתית, לא רק אסתטיקה.

ארגונים (תווי בקרה נסתרים: RLM, LRM, ו-Embedding): הוסיפו ל-playbook תמיכה — «טקסט הפוך מ-PDF? תיקלוד reverse, לא התקנה מחדש של Windows». חוסך tickets.

עוד נקודה על תווי בקרה נסתרים: RLM, LRM, ו-Embedding: בישראל, מיליוני משתמשים מעתיקים טקסט מדי יום מקבצי PDF, מיילים, וואטסאפ, ואתרי חדשות. הבנה של ההבדל בין RTL, LTR, BiDi, ושכבת מקלדת — מפחיתה תסכול ומונעת שליחת מסמכים מקולקלים ללקוחות.

סיכום ביניים ל-תווי בקרה נסתרים: RLM, LRM, ו-Embedding: שמרו tiklud.com בסימניות, למדו לזהות «םולש» מול «akuo», ובדקו כיוון פסקה ב-Word אחרי כל תיקון. שלושה צעדים — workflow שעובד.

סוג א: שכבת מקלדת — נראה latin: akuo, vhh, nz rubh. האותיות לא עבריות בכלל. פתרון: תיקלוד «המרה» (EN→HE). לא «הפוך כיוון».

סוג ב: סדר תווים הפוך — נראה עברית אבל mirror: םולש, הדות, םokנש. פתרון: תיקלוד «הפוך כיוון». לא «המרה».

סוג ג: כיוון פסקה — «שלום» נכון, אבל השורה מתחילה משמאל, cursor משמאל. פתרון: Word Ctrl+Shift; Google Docs Format → RTL. לא תיקלוד.

סוג ד: שילוב — layer wrong THEN pasted to PDF THEN copied — double corruption. Fix layer first (convert), then reverse if still needed.

Decision tree: Step 1 — are chars Hebrew? No → convert. Yes → Step 2 — read word left-to-right, makes sense? No → reverse. Yes → Step 3 — paragraph direction in app.

Common mistake: reverse on «akuo» → «ouka» — worse. Convert on «םולש» → still wrong chars.

Share with team: screenshot + label type A/B/C — saves helpdesk time.

Print table near desk — reduces panic paste-fix loops.

IT helpdesk script: «שלחו צילום + האם האותיות עבריות או לatin» — triage in 10 sec.

Training slide: one page A/B/C — onboarding win.

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

בנושא שלושה סוגי «טקסט הפוך» — טבלת אבחון מהירה, חשוב לזכור שתיקלוד לא מחליף עורך מסמכים — הוא כלי ביניים. אחרי «הפוך כיוון» או «המרה», תמיד הדביקו ליעד עם כיוון פסקה RTL (ב-Word: Ctrl+Shift+חץ ימין, ב-Google Docs: Format → Paragraph direction). בלי זה, גם טקסט מתוקן עלול «להיראות» LTR.

לגבי שלושה סוגי «טקסט הפוך» — טבלת אבחון מהירה: מפתחים שבונים pipeline לייבוא מסמכים עבריים — הפרידו בין נרמול BiDi לבין היפוך מחרוזת. נרמול ≠ היפוך. בדקו עם «שלום» → «םולש» → reverse → «שלום». regression test ב-CI.

תרחיש יומיומי (שלושה סוגי «טקסט הפוך» — טבלת אבחון מהירה): עורך תוכן מעתיק ציטוט ממאמר PDF לאתר WordPress. הדבקה → «םיללכ םע םולש» → תיקלוד reverse → «שלום עם כללים» → הדבקה לבלוק → RTL → פרסום. דקה אחת.

נגישות (שלושה סוגי «טקסט הפוך» — טבלת אבחון מהירה): קוראי מסך (NVDA, JAWS, VoiceOver) קוראים לפי סדר לוגי. הדבקה שגויה = חוויה שבורה לעיוורים. תיקון reverse לפני פרסום — חובה אתית, לא רק אסתטיקה.

ארגונים (שלושה סוגי «טקסט הפוך» — טבלת אבחון מהירה): הוסיפו ל-playbook תמיכה — «טקסט הפוך מ-PDF? תיקלוד reverse, לא התקנה מחדש של Windows». חוסך tickets.

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

סיכום ביניים ל-שלושה סוגי «טקסט הפוך» — טבלת אבחון מהירה: שמרו tiklud.com בסימניות, למדו לזהות «םולש» מול «akuo», ובדקו כיוון פסקה ב-Word אחרי כל תיקון. שלושה צעדים — workflow שעובד.

ב-tiklud.com, «הפוך כיוון» קורא ל-reverseText(): הופך את סדר graphemes במחרוזת. מיועה ל-RTL paste order issues — לא להמרת שכבת מקלדת.

Workflow: (1) פתחו tiklud.com. (2) הדביקו טקסט שבור. (3) לחצו «הפוך כיוון». (4) בדקו output — קראו מילה ראשונה. (5) העתיקו → הדבקו ליעד.

Grapheme-aware: emoji 🇮🇱, אות עם ניקוד — reversed as units when Intl.Segmenter supported. Older browsers — char-by-char.

When NOT to use: latin gibberish keyboard layer. English text you typed correctly. Paragraph direction only.

Combine: PDF paste reversed Hebrew with english word inside — reverse whole paste often fixes Hebrew parts; english «hello» becomes «olleh» — BAD. Fix: split segments or manual fix english part.

Privacy: reverse runs client-side — same as convert. Safe for contracts, medical, legal.

Mobile: tiklud.com in mobile browser — same buttons. Long paste OK.

Bookmark tiklud.com — muscle memory for paste emergencies.

Keyboard shortcut: none built-in — click button. Fast enough for 30-sec fix.

Compare before/after side-by-side — first word must make sense.

פרק 12 במדריך זה (תיקון עם תיקלוד: כפתור «הפוך כיוון» (Reverse Direction)) מדגיש שהדבקה אינה «העתקה» פשוטה — היא העברה של קידוד, מטא-דאטה של כיוון, ולעיתים סדר גליפים ויזואלי. משתמשים מנוסים בישראל למדו לבדוק את המשפט הראשון אחרי כל הדבקה מ-PDF. אם המילה הראשונה לא הגיונית — עצרו לפני המשך עריכה.

בנושא תיקון עם תיקלוד: כפתור «הפוך כיוון» (Reverse Direction), חשוב לזכור שתיקלוד לא מחליף עורך מסמכים — הוא כלי ביניים. אחרי «הפוך כיוון» או «המרה», תמיד הדביקו ליעד עם כיוון פסקה RTL (ב-Word: Ctrl+Shift+חץ ימין, ב-Google Docs: Format → Paragraph direction). בלי זה, גם טקסט מתוקן עלול «להיראות» LTR.

לגבי תיקון עם תיקלוד: כפתור «הפוך כיוון» (Reverse Direction): מפתחים שבונים pipeline לייבוא מסמכים עבריים — הפרידו בין נרמול BiDi לבין היפוך מחרוזת. נרמול ≠ היפוך. בדקו עם «שלום» → «םולש» → reverse → «שלום». regression test ב-CI.

תרחיש יומיומי (תיקון עם תיקלוד: כפתור «הפוך כיוון» (Reverse Direction)): עורך תוכן מעתיק ציטוט ממאמר PDF לאתר WordPress. הדבקה → «םיללכ םע םולש» → תיקלוד reverse → «שלום עם כללים» → הדבקה לבלוק → RTL → פרסום. דקה אחת.

נגישות (תיקון עם תיקלוד: כפתור «הפוך כיוון» (Reverse Direction)): קוראי מסך (NVDA, JAWS, VoiceOver) קוראים לפי סדר לוגי. הדבקה שגויה = חוויה שבורה לעיוורים. תיקון reverse לפני פרסום — חובה אתית, לא רק אסתטיקה.

ארגונים (תיקון עם תיקלוד: כפתור «הפוך כיוון» (Reverse Direction)): הוסיפו ל-playbook תמיכה — «טקסט הפוך מ-PDF? תיקלוד reverse, לא התקנה מחדש של Windows». חוסך tickets.

עוד נקודה על תיקון עם תיקלוד: כפתור «הפוך כיוון» (Reverse Direction): בישראל, מיליוני משתמשים מעתיקים טקסט מדי יום מקבצי PDF, מיילים, וואטסאפ, ואתרי חדשות. הבנה של ההבדל בין RTL, LTR, BiDi, ושכבת מקלדת — מפחיתה תסכול ומונעת שליחת מסמכים מקולקלים ללקוחות.

סיכום ביניים ל-תיקון עם תיקלוד: כפתור «הפוך כיוון» (Reverse Direction): שמרו tiklud.com בסימניות, למדו לזהות «םולש» מול «akuo», ובדקו כיוון פסקה ב-Word אחרי כל תיקון. שלושה צעדים — workflow שעובד.

«המרה» מחליפה תווים לפי מיפוי SI 1452 — 33 מקשי QWERTY ↔ עברית. a↔ש, k↔ל, t↔א. זה keyboard layout fix — orthogonal to reverse.

Example: pasted «akuo, nz rubh» from chat — convert HE → «שלום, מה קורה». Reverse would not help.

detectScript() suggests direction: dominant Hebrew → suggest EN target (you typed wrong layer english output). Dominant EN → suggest HE.

Toggle «הפוך כיוון» for conversion direction swap — if auto-wrong.

Mixed: «2026 akuo» → convert → «2026 שלום» — numbers preserved.

After convert, if still reversed char order (rare combo bug) — then reverse.

Round-trip test: שלום → convert EN → akuo → convert HE → שלום. Validates tool.

Not translation: «hello» convert → not «שלום» semantically — gibberish hebrew chars only if hello was layer-wrong hebrew intent.

Arabic beta: same UI — layout for Arabic keyboard, not Hebrew SI 1452.

Case toggle: separate button — for latin after convert.

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

בנושא תיקון עם תיקלוד: כפתור «המרה» (Convert) — מתי ולמה, חשוב לזכור שתיקלוד לא מחליף עורך מסמכים — הוא כלי ביניים. אחרי «הפוך כיוון» או «המרה», תמיד הדביקו ליעד עם כיוון פסקה RTL (ב-Word: Ctrl+Shift+חץ ימין, ב-Google Docs: Format → Paragraph direction). בלי זה, גם טקסט מתוקן עלול «להיראות» LTR.

לגבי תיקון עם תיקלוד: כפתור «המרה» (Convert) — מתי ולמה: מפתחים שבונים pipeline לייבוא מסמכים עבריים — הפרידו בין נרמול BiDi לבין היפוך מחרוזת. נרמול ≠ היפוך. בדקו עם «שלום» → «םולש» → reverse → «שלום». regression test ב-CI.

תרחיש יומיומי (תיקון עם תיקלוד: כפתור «המרה» (Convert) — מתי ולמה): עורך תוכן מעתיק ציטוט ממאמר PDF לאתר WordPress. הדבקה → «םיללכ םע םולש» → תיקלוד reverse → «שלום עם כללים» → הדבקה לבלוק → RTL → פרסום. דקה אחת.

נגישות (תיקון עם תיקלוד: כפתור «המרה» (Convert) — מתי ולמה): קוראי מסך (NVDA, JAWS, VoiceOver) קוראים לפי סדר לוגי. הדבקה שגויה = חוויה שבורה לעיוורים. תיקון reverse לפני פרסום — חובה אתית, לא רק אסתטיקה.

ארגונים (תיקון עם תיקלוד: כפתור «המרה» (Convert) — מתי ולמה): הוסיפו ל-playbook תמיכה — «טקסט הפוך מ-PDF? תיקלוד reverse, לא התקנה מחדש של Windows». חוסך tickets.

עוד נקודה על תיקון עם תיקלוד: כפתור «המרה» (Convert) — מתי ולמה: בישראל, מיליוני משתמשים מעתיקים טקסט מדי יום מקבצי PDF, מיילים, וואטסאפ, ואתרי חדשות. הבנה של ההבדל בין RTL, LTR, BiDi, ושכבת מקלדת — מפחיתה תסכול ומונעת שליחת מסמכים מקולקלים ללקוחות.

סיכום ביניים ל-תיקון עם תיקלוד: כפתור «המרה» (Convert) — מתי ולמה: שמרו tiklud.com בסימניות, למדו לזהות «םולש» מול «akuo», ובדקו כיוון פסקה ב-Word אחרי כל תיקון. שלושה צעדים — workflow שעובד.

Scenario: contract PDF, clause in Hebrew, copy gives «ןומימ םע תורש» instead of «שורת עם מינוי».

Step 1: Copy clause from PDF. Step 2: tiklud.com paste. Step 3: Confirm Hebrew chars (not latin) — yes. Step 4: «הפוך כיוון» → «שורת עם מינוי». Step 5: Copy. Step 6: Word → Paste Text Only → Home → Paragraph → RTL.

If also had «akuo» typo in same paste — unlikely mix; usually one issue type per source.

Verify: read aloud. Check numbers unchanged. Send to colleague proof.

Save tiklud output to .txt backup before pasting to Word — undo reference.

Large doc: fix paragraph by paragraph — easier rollback.

Time: 30 seconds per clause vs 5 min retype.

Legal: fixed text = same obligation; formatting cleanup separate.

Second example: academic PDF abstract — mixed EN abstract + HE keywords. Copy keywords only — reverse if םולש pattern.

Third: government form PDF — fillable fields copy OK; body text from scan — reverse likely.

פרק 14 במדריך זה (Workflow משולב: PDF → תיקלוד → Word — דוגמה מלאה) מדגיש שהדבקה אינה «העתקה» פשוטה — היא העברה של קידוד, מטא-דאטה של כיוון, ולעיתים סדר גליפים ויזואלי. משתמשים מנוסים בישראל למדו לבדוק את המשפט הראשון אחרי כל הדבקה מ-PDF. אם המילה הראשונה לא הגיונית — עצרו לפני המשך עריכה.

בנושא Workflow משולב: PDF → תיקלוד → Word — דוגמה מלאה, חשוב לזכור שתיקלוד לא מחליף עורך מסמכים — הוא כלי ביניים. אחרי «הפוך כיוון» או «המרה», תמיד הדביקו ליעד עם כיוון פסקה RTL (ב-Word: Ctrl+Shift+חץ ימין, ב-Google Docs: Format → Paragraph direction). בלי זה, גם טקסט מתוקן עלול «להיראות» LTR.

לגבי Workflow משולב: PDF → תיקלוד → Word — דוגמה מלאה: מפתחים שבונים pipeline לייבוא מסמכים עבריים — הפרידו בין נרמול BiDi לבין היפוך מחרוזת. נרמול ≠ היפוך. בדקו עם «שלום» → «םולש» → reverse → «שלום». regression test ב-CI.

תרחיש יומיומי (Workflow משולב: PDF → תיקלוד → Word — דוגמה מלאה): עורך תוכן מעתיק ציטוט ממאמר PDF לאתר WordPress. הדבקה → «םיללכ םע םולש» → תיקלוד reverse → «שלום עם כללים» → הדבקה לבלוק → RTL → פרסום. דקה אחת.

נגישות (Workflow משולב: PDF → תיקלוד → Word — דוגמה מלאה): קוראי מסך (NVDA, JAWS, VoiceOver) קוראים לפי סדר לוגי. הדבקה שגויה = חוויה שבורה לעיוורים. תיקון reverse לפני פרסום — חובה אתית, לא רק אסתטיקה.

ארגונים (Workflow משולב: PDF → תיקלוד → Word — דוגמה מלאה): הוסיפו ל-playbook תמיכה — «טקסט הפוך מ-PDF? תיקלוד reverse, לא התקנה מחדש של Windows». חוסך tickets.

עוד נקודה על Workflow משולב: PDF → תיקלוד → Word — דוגמה מלאה: בישראל, מיליוני משתמשים מעתיקים טקסט מדי יום מקבצי PDF, מיילים, וואטסאפ, ואתרי חדשות. הבנה של ההבדל בין RTL, LTR, BiDi, ושכבת מקלדת — מפחיתה תסכול ומונעת שליחת מסמכים מקולקלים ללקוחות.

סיכום ביניים ל-Workflow משולב: PDF → תיקלוד → Word — דוגמה מלאה: שמרו tiklud.com בסימניות, למדו לזהות «םולש» מול «akuo», ובדקו כיוון פסקה ב-Word אחרי כל תיקון. שלושה צעדים — workflow שעובד.

Gmail: compose RTL auto for Hebrew. Paste reversed — shows wrong. Fix in tiklud before paste to compose.

WhatsApp Web/Desktop: RTL for Hebrew messages. Copy message with wrong order — tiklud reverse before forward to email.

Google Docs: Format → Paragraph direction → Right to left. Paste then fix direction OR fix text then paste. Both work.

Outlook: like Word — RTL paragraph + correct char order. Signature blocks — fix once in tiklud, save.

Slack: monospace for code; Hebrew RTL in default. Paste from PDF to Slack — reverse first.

Notion: blocks LTR default — Hebrew paste issue reported. Plain block + RTL toggle + tiklud.

PowerPoint: text boxes direction per box. Slides from PDF — nightmare — tiklud batch fix.

Teams: similar Outlook stack — same rules.

Apple Mail: RTL compose — paste from PDF same rules.

Telegram desktop — copy Hebrew OK usually; forward chain — test.

פרק 15 במדריך זה (אפליקציות נפוצות: Gmail, WhatsApp, Google Docs, Outlook) מדגיש שהדבקה אינה «העתקה» פשוטה — היא העברה של קידוד, מטא-דאטה של כיוון, ולעיתים סדר גליפים ויזואלי. משתמשים מנוסים בישראל למדו לבדוק את המשפט הראשון אחרי כל הדבקה מ-PDF. אם המילה הראשונה לא הגיונית — עצרו לפני המשך עריכה.

בנושא אפליקציות נפוצות: Gmail, WhatsApp, Google Docs, Outlook, חשוב לזכור שתיקלוד לא מחליף עורך מסמכים — הוא כלי ביניים. אחרי «הפוך כיוון» או «המרה», תמיד הדביקו ליעד עם כיוון פסקה RTL (ב-Word: Ctrl+Shift+חץ ימין, ב-Google Docs: Format → Paragraph direction). בלי זה, גם טקסט מתוקן עלול «להיראות» LTR.

לגבי אפליקציות נפוצות: Gmail, WhatsApp, Google Docs, Outlook: מפתחים שבונים pipeline לייבוא מסמכים עבריים — הפרידו בין נרמול BiDi לבין היפוך מחרוזת. נרמול ≠ היפוך. בדקו עם «שלום» → «םולש» → reverse → «שלום». regression test ב-CI.

תרחיש יומיומי (אפליקציות נפוצות: Gmail, WhatsApp, Google Docs, Outlook): עורך תוכן מעתיק ציטוט ממאמר PDF לאתר WordPress. הדבקה → «םיללכ םע םולש» → תיקלוד reverse → «שלום עם כללים» → הדבקה לבלוק → RTL → פרסום. דקה אחת.

נגישות (אפליקציות נפוצות: Gmail, WhatsApp, Google Docs, Outlook): קוראי מסך (NVDA, JAWS, VoiceOver) קוראים לפי סדר לוגי. הדבקה שגויה = חוויה שבורה לעיוורים. תיקון reverse לפני פרסום — חובה אתית, לא רק אסתטיקה.

ארגונים (אפליקציות נפוצות: Gmail, WhatsApp, Google Docs, Outlook): הוסיפו ל-playbook תמיכה — «טקסט הפוך מ-PDF? תיקלוד reverse, לא התקנה מחדש של Windows». חוסך tickets.

עוד נקודה על אפליקציות נפוצות: Gmail, WhatsApp, Google Docs, Outlook: בישראל, מיליוני משתמשים מעתיקים טקסט מדי יום מקבצי PDF, מיילים, וואטסאפ, ואתרי חדשות. הבנה של ההבדל בין RTL, LTR, BiDi, ושכבת מקלדת — מפחיתה תסכול ומונעת שליחת מסמכים מקולקלים ללקוחות.

סיכום ביניים ל-אפליקציות נפוצות: Gmail, WhatsApp, Google Docs, Outlook: שמרו tiklud.com בסימניות, למדו לזהות «םולש» מול «akuo», ובדקו כיוון פסקה ב-Word אחרי כל תיקון. שלושה צעדים — workflow שעובד.

Prefer source format: DOCX over PDF, HTML with dir=rtl over plain export.

Paste Text Only shortcut: Ctrl+Shift+V (many apps) — strips harmful formatting.

One clipboard fix tool: tiklud bookmark — habit before second paste.

PDF: export «text» from Acrobat if available vs drag-select.

Don't chain: PDF→Word→Gmail→copy back — each hop adds corruption.

Language tag: set Word doc default Hebrew RTL — new paste inherits less badly.

Team docs: link this guide — shared vocabulary type A/B/C.

OCR: post-process through tiklud reverse pipeline — IT manual step for now.

Quality gate: proofread first sentence before publish — catches 90% issues.

Source discipline: keep DOCX master — PDF only for distribution.

פרק 16 במדריך זה (מניעה: איך להפחית בעיות RTL/LTR לפני ההדבקה) מדגיש שהדבקה אינה «העתקה» פשוטה — היא העברה של קידוד, מטא-דאטה של כיוון, ולעיתים סדר גליפים ויזואלי. משתמשים מנוסים בישראל למדו לבדוק את המשפט הראשון אחרי כל הדבקה מ-PDF. אם המילה הראשונה לא הגיונית — עצרו לפני המשך עריכה.

בנושא מניעה: איך להפחית בעיות RTL/LTR לפני ההדבקה, חשוב לזכור שתיקלוד לא מחליף עורך מסמכים — הוא כלי ביניים. אחרי «הפוך כיוון» או «המרה», תמיד הדביקו ליעד עם כיוון פסקה RTL (ב-Word: Ctrl+Shift+חץ ימין, ב-Google Docs: Format → Paragraph direction). בלי זה, גם טקסט מתוקן עלול «להיראות» LTR.

לגבי מניעה: איך להפחית בעיות RTL/LTR לפני ההדבקה: מפתחים שבונים pipeline לייבוא מסמכים עבריים — הפרידו בין נרמול BiDi לבין היפוך מחרוזת. נרמול ≠ היפוך. בדקו עם «שלום» → «םולש» → reverse → «שלום». regression test ב-CI.

תרחיש יומיומי (מניעה: איך להפחית בעיות RTL/LTR לפני ההדבקה): עורך תוכן מעתיק ציטוט ממאמר PDF לאתר WordPress. הדבקה → «םיללכ םע םולש» → תיקלוד reverse → «שלום עם כללים» → הדבקה לבלוק → RTL → פרסום. דקה אחת.

נגישות (מניעה: איך להפחית בעיות RTL/LTR לפני ההדבקה): קוראי מסך (NVDA, JAWS, VoiceOver) קוראים לפי סדר לוגי. הדבקה שגויה = חוויה שבורה לעיוורים. תיקון reverse לפני פרסום — חובה אתית, לא רק אסתטיקה.

ארגונים (מניעה: איך להפחית בעיות RTL/LTR לפני ההדבקה): הוסיפו ל-playbook תמיכה — «טקסט הפוך מ-PDF? תיקלוד reverse, לא התקנה מחדש של Windows». חוסך tickets.

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

סיכום ביניים ל-מניעה: איך להפחית בעיות RTL/LTR לפני ההדבקה: שמרו tiklud.com בסימניות, למדו לזהות «םולש» מול «akuo», ובדקו כיוון פסקה ב-Word אחרי כל תיקון. שלושה צעדים — workflow שעובד.

Windows 11: clipboard history Win+V — recover pre-fix original. RTL in Notepad — no bidi, good debug.

macOS: Paste and Match Style Cmd+Option+Shift+V — like Paste Text Only. TextEdit plain — debug step.

Linux: xclip/xsel — plain text pipeline. LibreOffice Writer — RTL paragraph like Word.

Cross-platform Google Docs — same from any OS once in browser.

Remote desktop: copy from RDP session — encoding edge cases. Paste locally to tiklud first.

WSL: Windows↔Linux clipboard — Hebrew OK in modern builds; test long text.

ChromeOS: Linux container + Android apps — triple clipboard confusion. tiklud web universal.

Virtual machine: host↔guest copy — sometimes mangles. intermediate .txt file.

Mobile→Desktop: AirDrop text, WhatsApp export — test order on desktop.

פרק 17 במדריך זה (Windows, Mac, Linux: הבדלי הדבקה בין מערכות) מדגיש שהדבקה אינה «העתקה» פשוטה — היא העברה של קידוד, מטא-דאטה של כיוון, ולעיתים סדר גליפים ויזואלי. משתמשים מנוסים בישראל למדו לבדוק את המשפט הראשון אחרי כל הדבקה מ-PDF. אם המילה הראשונה לא הגיונית — עצרו לפני המשך עריכה.

בנושא Windows, Mac, Linux: הבדלי הדבקה בין מערכות, חשוב לזכור שתיקלוד לא מחליף עורך מסמכים — הוא כלי ביניים. אחרי «הפוך כיוון» או «המרה», תמיד הדביקו ליעד עם כיוון פסקה RTL (ב-Word: Ctrl+Shift+חץ ימין, ב-Google Docs: Format → Paragraph direction). בלי זה, גם טקסט מתוקן עלול «להיראות» LTR.

לגבי Windows, Mac, Linux: הבדלי הדבקה בין מערכות: מפתחים שבונים pipeline לייבוא מסמכים עבריים — הפרידו בין נרמול BiDi לבין היפוך מחרוזת. נרמול ≠ היפוך. בדקו עם «שלום» → «םולש» → reverse → «שלום». regression test ב-CI.

תרחיש יומיומי (Windows, Mac, Linux: הבדלי הדבקה בין מערכות): עורך תוכן מעתיק ציטוט ממאמר PDF לאתר WordPress. הדבקה → «םיללכ םע םולש» → תיקלוד reverse → «שלום עם כללים» → הדבקה לבלוק → RTL → פרסום. דקה אחת.

נגישות (Windows, Mac, Linux: הבדלי הדבקה בין מערכות): קוראי מסך (NVDA, JAWS, VoiceOver) קוראים לפי סדר לוגי. הדבקה שגויה = חוויה שבורה לעיוורים. תיקון reverse לפני פרסום — חובה אתית, לא רק אסתטיקה.

ארגונים (Windows, Mac, Linux: הבדלי הדבקה בין מערכות): הוסיפו ל-playbook תמיכה — «טקסט הפוך מ-PDF? תיקלוד reverse, לא התקנה מחדש של Windows». חוסך tickets.

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

סיכום ביניים ל-Windows, Mac, Linux: הבדלי הדבקה בין מערכות: שמרו tiklud.com בסימניות, למדו לזהות «םולש» מול «akuo», ובדקו כיוון פסקה ב-Word אחרי כל תיקון. שלושה צעדים — workflow שעובד.

ש: הדבקתי מ-PDF וכל העברית הפוכה. מה עושים? ת: tiklud.com → הדביקו → «הפוך כיוון» → העתיקו חזרה.

ש: «הפוך כיוון» או «המרה»? ת: latin gibberish (akuo) = המרה. Hebrew mirror (םולש) = הפוך כיוון.

ש: Word Ctrl+Shift לא עוזר. ת: כנראה סדר תווים, לא פסקה — tiklud reverse.

ש: האם תיקלוד שולח טקסט לשרת? ת: לא — client-side בדפדפן.

ש: טקסט מעורב עברית ואנגלית — בטוח להפוך? ת: reverse whole string may flip English — בדקו URLs ומספרים; fix segments.

ש: זה קשור ל-SI 1452? ת: SI 1452 = keyboard layout (המרה). RTL order = נפרד (הפוך כיוון).

ש: macOS vs Windows? ת: paste issues cross-platform — tiklud web works both.

ש: ערבית? ת: reverse works; convert beta for Arabic layout.

ש: למה Notepad מציג נכון אבל Word לא? ת: Word applies paragraph bidi; fix direction + char order.

ש: אפשר ל-automate? ת: manual tiklud fast; bookmark workflow.

ש: OCR עברית? ת: almost always reverse + proof.

ש: Excel paste? ת: cell-by-cell; don't reverse whole sheet.

פרק 18 במדריך זה (שאלות נפוצות (FAQ) על RTL, LTR והדבקה) מדגיש שהדבקה אינה «העתקה» פשוטה — היא העברה של קידוד, מטא-דאטה של כיוון, ולעיתים סדר גליפים ויזואלי. משתמשים מנוסים בישראל למדו לבדוק את המשפט הראשון אחרי כל הדבקה מ-PDF. אם המילה הראשונה לא הגיונית — עצרו לפני המשך עריכה.

בנושא שאלות נפוצות (FAQ) על RTL, LTR והדבקה, חשוב לזכור שתיקלוד לא מחליף עורך מסמכים — הוא כלי ביניים. אחרי «הפוך כיוון» או «המרה», תמיד הדביקו ליעד עם כיוון פסקה RTL (ב-Word: Ctrl+Shift+חץ ימין, ב-Google Docs: Format → Paragraph direction). בלי זה, גם טקסט מתוקן עלול «להיראות» LTR.

לגבי שאלות נפוצות (FAQ) על RTL, LTR והדבקה: מפתחים שבונים pipeline לייבוא מסמכים עבריים — הפרידו בין נרמול BiDi לבין היפוך מחרוזת. נרמול ≠ היפוך. בדקו עם «שלום» → «םולש» → reverse → «שלום». regression test ב-CI.

תרחיש יומיומי (שאלות נפוצות (FAQ) על RTL, LTR והדבקה): עורך תוכן מעתיק ציטוט ממאמר PDF לאתר WordPress. הדבקה → «םיללכ םע םולש» → תיקלוד reverse → «שלום עם כללים» → הדבקה לבלוק → RTL → פרסום. דקה אחת.

נגישות (שאלות נפוצות (FAQ) על RTL, LTR והדבקה): קוראי מסך (NVDA, JAWS, VoiceOver) קוראים לפי סדר לוגי. הדבקה שגויה = חוויה שבורה לעיוורים. תיקון reverse לפני פרסום — חובה אתית, לא רק אסתטיקה.

ארגונים (שאלות נפוצות (FAQ) על RTL, LTR והדבקה): הוסיפו ל-playbook תמיכה — «טקסט הפוך מ-PDF? תיקלוד reverse, לא התקנה מחדש של Windows». חוסך tickets.

עוד נקודה על שאלות נפוצות (FAQ) על RTL, LTR והדבקה: בישראל, מיליוני משתמשים מעתיקים טקסט מדי יום מקבצי PDF, מיילים, וואטסאפ, ואתרי חדשות. הבנה של ההבדל בין RTL, LTR, BiDi, ושכבת מקלדת — מפחיתה תסכול ומונעת שליחת מסמכים מקולקלים ללקוחות.

סיכום ביניים ל-שאלות נפוצות (FAQ) על RTL, LTR והדבקה: שמרו tiklud.com בסימניות, למדו לזהות «םולש» מול «akuo», ובדקו כיוון פסקה ב-Word אחרי כל תיקון. שלושה צעדים — workflow שעובד.

«שלום» שהועתק מ-PDF ויצא «םולש» — לחצו «הפוך כיוון» → «שלום». אין צורך בהמרה.

«akuo» מהצ'אט — שכבת מקלדת — «המרה» לעברית → «שלום». «הפוך כיוון» יהרוס.

«Meeting ב-14:00» עם מילה עברית הפוכה בלבד — בחרו את הקטע העברי, reverse segment, השאירו את האנגלית.

«2026 תודה» → «הדות 6202» — reverse כל השורה שובר מספרים. reverse רק «הדות» → «תודה», השאר ידני.

משפט ארוך מ-PDF: «ןומימ םע תורש תא ונל שי» → reverse → «יש לנו את שורת עם מינוי».

WhatsApp: העתקת הודעה «nz rubh» — convert → «מה קורה». לא reverse.

Word: «שלום» נכון, cursor משמאל — Ctrl+Shift ב-Word, לא תיקלוד.

שילוב: «akuo » + PDF reversed — קודם convert על akuo, אחר כך reverse על segment PDF.

בדיקה: קראו בקול — אם נשמע טבעי, סיימתם.

שמרו לפני/אחרי בקובץ — documentation ללקוח.

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

בנושא דוגמאות מעשיות: לפני ואחרי תיקון בתיקלוד, חשוב לזכור שתיקלוד לא מחליף עורך מסמכים — הוא כלי ביניים. אחרי «הפוך כיוון» או «המרה», תמיד הדביקו ליעד עם כיוון פסקה RTL (ב-Word: Ctrl+Shift+חץ ימין, ב-Google Docs: Format → Paragraph direction). בלי זה, גם טקסט מתוקן עלול «להיראות» LTR.

לגבי דוגמאות מעשיות: לפני ואחרי תיקון בתיקלוד: מפתחים שבונים pipeline לייבוא מסמכים עבריים — הפרידו בין נרמול BiDi לבין היפוך מחרוזת. נרמול ≠ היפוך. בדקו עם «שלום» → «םולש» → reverse → «שלום». regression test ב-CI.

תרחיש יומיומי (דוגמאות מעשיות: לפני ואחרי תיקון בתיקלוד): עורך תוכן מעתיק ציטוט ממאמר PDF לאתר WordPress. הדבקה → «םיללכ םע םולש» → תיקלוד reverse → «שלום עם כללים» → הדבקה לבלוק → RTL → פרסום. דקה אחת.

נגישות (דוגמאות מעשיות: לפני ואחרי תיקון בתיקלוד): קוראי מסך (NVDA, JAWS, VoiceOver) קוראים לפי סדר לוגי. הדבקה שגויה = חוויה שבורה לעיוורים. תיקון reverse לפני פרסום — חובה אתית, לא רק אסתטיקה.

ארגונים (דוגמאות מעשיות: לפני ואחרי תיקון בתיקלוד): הוסיפו ל-playbook תמיכה — «טקסט הפוך מ-PDF? תיקלוד reverse, לא התקנה מחדש של Windows». חוסך tickets.

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

סיכום ביניים ל-דוגמאות מעשיות: לפני ואחרי תיקון בתיקלוד: שמרו tiklud.com בסימניות, למדו לזהות «םולש» מול «akuo», ובדקו כיוון פסקה ב-Word אחרי כל תיקון. שלושה צעדים — workflow שעובד.

בעיות RTL ו-LTR בהדבקה — לא «עברית שבורה», אלא מפגש בין logical order, visual order, BiDi, ומקורות שונים (PDF, Word, web).

שלושה סוגים: שכבת מקלדת (המרה), סדר תווים (הפוך כיוון), כיוון פסקה (הגדרות אפליקציה).

Unicode BiDi מסדר תצוגה; הוא לא מתקן PDF visual order paste — reverse כן.

PDF ו-OCR — מקור #1 ל-reversed Hebrew. Word paste options — מקור #2 ל-bidi mess. Web — variable.

תיקלוד: tiklud.com — «המרה» + «הפוך כיוון», מקומי, מהיר, חינמי.

Workflow: הדבקה → אבחון A/B/C → כפתור נכון → בדיקה → הדבקה ליעד → RTL paragraph אם צריך.

שמרו bookmark; שתפו עם צוות; prefer DOCX על PDF.

מדריך זה מכסה bidirectional text, Unicode bidi, paste from PDF/Word/web, reversed character order, mixed Hebrew-English — ותיקון עם תיקלוד reverse direction + convert.

שאלות? בלוג תיקלוד — מאמרים נוספים על מקלדת, SI 1452, WhatsApp, ועבודה דו-לשונית.

הצלחה בעבודה דו-לשונית — זה תהליך, לא מזל. זיהוי נכון + כלי נכון = שניות.

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

בנושא סיכום: שלוש שכבות, שני כפתורים, workflow אחד ברור, חשוב לזכור שתיקלוד לא מחליף עורך מסמכים — הוא כלי ביניים. אחרי «הפוך כיוון» או «המרה», תמיד הדביקו ליעד עם כיוון פסקה RTL (ב-Word: Ctrl+Shift+חץ ימין, ב-Google Docs: Format → Paragraph direction). בלי זה, גם טקסט מתוקן עלול «להיראות» LTR.

לגבי סיכום: שלוש שכבות, שני כפתורים, workflow אחד ברור: מפתחים שבונים pipeline לייבוא מסמכים עבריים — הפרידו בין נרמול BiDi לבין היפוך מחרוזת. נרמול ≠ היפוך. בדקו עם «שלום» → «םולש» → reverse → «שלום». regression test ב-CI.

תרחיש יומיומי (סיכום: שלוש שכבות, שני כפתורים, workflow אחד ברור): עורך תוכן מעתיק ציטוט ממאמר PDF לאתר WordPress. הדבקה → «םיללכ םע םולש» → תיקלוד reverse → «שלום עם כללים» → הדבקה לבלוק → RTL → פרסום. דקה אחת.

נגישות (סיכום: שלוש שכבות, שני כפתורים, workflow אחד ברור): קוראי מסך (NVDA, JAWS, VoiceOver) קוראים לפי סדר לוגי. הדבקה שגויה = חוויה שבורה לעיוורים. תיקון reverse לפני פרסום — חובה אתית, לא רק אסתטיקה.

ארגונים (סיכום: שלוש שכבות, שני כפתורים, workflow אחד ברור): הוסיפו ל-playbook תמיכה — «טקסט הפוך מ-PDF? תיקלוד reverse, לא התקנה מחדש של Windows». חוסך tickets.

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

סיכום ביניים ל-סיכום: שלוש שכבות, שני כפתורים, workflow אחד ברור: שמרו tiklud.com בסימניות, למדו לזהות «םולש» מול «akuo», ובדקו כיוון פסקה ב-Word אחרי כל תיקון. שלושה צעדים — workflow שעובד.

שמרו tiklud.com — רשת ביטחון. 21 באוגוסט 2026. slug: arabic-keyboard-israel.

שמרו tiklud.com — רשת ביטחון. 21 באוגוסט 2026. slug: arabic-keyboard-israel.