מינוח והתאמת שפה

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

הכלל שקובע את כל השאר

שמות טבלאות ושמות שדות בסכימה לעולם לא משתנים. Sales נשארת Sales, SaleStatusId נשאר SaleStatusId, וגם נתיב הדף apps/mybusiness/Sales נשאר. מה שמשתנה הוא תוויות: טקסט בדפים, בתפריטים, בכותרות ובמילון הריצה. המשיכו לדבר בשפת הסכימה. מסמך אפיון שכותב “טבלת פרויקטים” שולח את המיישם הבא לחפש טבלה שלא קיימת. הצורה הנכונה: Sales (פרויקטים).

המונחים שמהם מתחילים

הישות	שם המחלקה — לא משתנה	יחיד	רבים
מכירה	Sales	מכירה	מכירות
לקוח	Accounts	לקוח	לקוחות
פנייה	Cases	פנייה	פניות
משימה	Tasks	משימה	משימות
פעילות	Activities	פעילות	פעילויות
איש קשר	Contacts	איש קשר	אנשי קשר
ליד	Accounts עם IsAccount: false	ליד	לידים

---

Get-Terminology-Dictionary

הפרמטר	טיפוס	חובה	המשמעות
siteId	String		האתר

מפה של מונח מקורי → מונח מוצג. דוגמה ממערכת שבה כבר בוצע “מכירה ← פרויקט”:

JSON

{
  "success": true,
  "dictionary": {
    "מכירה": "פרויקט", "מכירות": "פרויקטים",
    "פנייה": "פנייה",  "פניות": "פניות",
    "משימה": "משימה",  "משימות": "משימות",
    "פעילות": "פעילות", "פעילויות": "פעילויות",
    "לקוח": "לקוח",    "לקוחות": "לקוחות",
    "ליד": "ליד",      "לידים": "לידים"
  }
}

מונח שלא השתנה מופיע כמיפוי זהות ("לקוח": "לקוח"). המילון מכיר שנים‑עשר מונחים מובנים בלבד (מכירה/ות, פנייה/ות, משימה/ות, פעילות/יות, לקוח/ות, ליד/ים); מפתח אחר שתכתבו לא יוחזר בקריאה.

Set-Terminology-Dictionary

הפרמטר	טיפוס	חובה	המשמעות
terminology	Object	✔	מפה של מחרוזת → מחרוזת
siteId	String		האתר

זו השכבה המערכתית: המפה שהריצה של ה‑CRM קוראת כדי לפתור תוויות שנוצרות דינמית — בדוחות, בשאילתות, ובמחרוזות שנבנות בזמן ריצה ולא יושבות ב‑HTML של אף דף.

הכתיבה מחליפה את המילון כולו

לא ממזגים. המפה שנשלחת נכתבת כמות שהיא ל‑jsCode של CRMmaster (var terminologyDictionary = {…}); מונח מובנה שלא שלחתם חוזר למיפוי זהות.

1. current = Get-Terminology-Dictionary()
2. merged  = current, עם המונחים שאתם משנים
3. Set-Terminology-Dictionary({ terminology: merged })

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

JSON

{ "terminology": {
    "מכירה": "פרויקט", "מכירות": "פרויקטים",
    "פנייה": "פנייה",  "פניות": "פניות",
    "לקוח": "לקוח",    "לקוחות": "לקוחות",
    "משימה": "משימה",  "משימות": "משימות",
    "פעילות": "פעילות", "פעילויות": "פעילויות",
    "ליד": "ליד",      "לידים": "לידים"
  } }

Replace-Terms

הפרמטר	טיפוס	חובה	המשמעות
pageId	String	✔	ה‑_id של הדף. חובה (בהשמטה — שגיאת ולידציה; נתיב במקום מזהה — Error: Failed to get page)
terms	Object	✔	מפה של מחרוזת → מחרוזת
siteId	String		האתר

החלפה מילולית ב‑HTML השמור של דף אחד: כותרות, טקסט של כפתורים (“מכירה חדשה” ← “פרויקט חדש”), כותרות של גרפים ומונים, כותרות מודאלים, כותרות עמודות ותוויות מסננים.

JSON

{ "pageId": "<pageId>", "terms": { "מכירה": "פרויקט", "מכירות": "פרויקטים" } }

1. התשובה מחזירה ספירת החלפות לכל מונח: { success, pageId, changes: [ { term: "<המונח החדש>", count } ] }. ה‑term המדווח הוא התחליף, לא המקור. כשאף מונח לא נמצא בדף הכלי מחזיר Error: No changes found, וזו לא תקלה. הספירות הן יומן הביקורת שלכם; “No changes found” בכל הדפים פירושו כמעט תמיד מזהי דפים שגויים.
2. מותר כמה זוגות בקריאה אחת — יחיד ורבים ביחד, וזה מה שעושים.
3. הפעולה אידמפוטנטית. הרצה חוזרת מחזירה “No changes found”, ולכן שינוי מינוח שנקטע באמצע פשוט מריצים שוב.

זו החלפת טקסט, ואפשר לשבור בה HTML

הכלי לא מבין מבנה. הוא מחליף מחרוזות בקוד הדף, כולל בתוך שמות מחלקות CSS, בתוך data‑attributes ובתוך מזהים אם המחרוזת שלכם מופיעה שם (החלפת שם מחלקה משנה את data-simbla-class של הטבלה; תחליף עם <b> ו‑& נכנס ל‑HTML כמות שהוא). תיאור הכלי מזהיר: “Be aware no to use terms that may break the html syntax” (הטעות ב‑no היא במקור). לפני כל זוג מונחים:

• האם המונח הוא תת‑מחרוזת של מילה אחרת? מונח קצר מדי יחליף גם באמצע מילים.
• האם המונח מופיע גם בזהות פנימית? לעולם אל תחליפו מזהים באנגלית.
• האם התחליף מכיל תו שמשמעותי ב‑HTML? גרשיים, <, & — בדקו על דף אחד לפני שמריצים על עשרים.

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

---

ארבע השכבות

שינוי מינוח שלם נוגע בארבעה מקומות, ורק אחד מהם הוא הכלי הזה:

מה המשתמש רואה	המנגנון
תוויות דינמיות בזמן ריצה — דוחות, שאילתות	Set-Terminology-Dictionary
כותרות דפים, כפתורים, כותרות עמודות, דשבורדים	Replace-Terms על כל דף
תוויות שדות בטופס (SaleId ← “משויך לפרויקט”)	Edit-Page בפעולה change-existing-field-label
כותרות בתפריטים	Set-Menu-Items
כותרת לשונית הדפדפן	Set-Page-Settings(pageId, title)
כותרת או פסקה בודדת ש‑Replace-Terms לא יכול לכוון אליה בבטחה	Add-Edit-Text-Element עם elemId

כלים מקוריים בלבד. כולם משנים HTML או מילון שמור, ולכן השינוי מיידי ואין הבהוב של הטקסט הישן. עקיפה ב‑JS שמחליף טקסט בזמן ריצה היא מוצא אחרון שדורש אישור מפורש.

סדר הפעולות

1. גילוי הדפים המושפעים
2. Set-Terminology-Dictionary          (Get → מיזוג → Set)
3. Replace-Terms על CRMmaster           ← חובה
4. Replace-Terms על Timeline            ← חובה, בנפרד
5. Replace-Terms על כל שאר הדפים
6. Edit-Page — תוויות שדות בדפי הכרטיס
7. Set-Menu-Items — כותרות התפריטים
8. אימות מקצה לקצה עם רענון קשיח

1. גילוי הדפים

• לפי שם: Get-Site-Pages וסינון לפי שם המחלקה. עבור Sales: Sale, Sales, SaleRows, Pipeline, DashboardSales, DashboardSalesManager, DashboardSalesRep, System-Tables-Sale-Statuses, Mobile-Sale, Mobile-Sales.
• לפי סכימה: Get-Schema → אילו טבלאות מחזיקות Pointer לישות → הדפים שלהן נושאים את המונח בתוויות ובכותרות סקשן. כרטיס הצעת המחיר שמצביע למכירה הוא דוגמה קלאסית.

ומעליהם הסט הקבוע שתמיד בהיקף: CRMmaster, Timeline, MasterTicket, Account, settings, DashboardLeads.

2–4. שתי התחנות שאי אפשר לדלג עליהן

• CRMmaster — דף המאסטר המשותף לכל הדפים (כותרת, מודאלים). המילון המוטבע שלו (terminologyDictionary ב‑jsCode) מנוהל ב‑Set-Terminology-Dictionary, לא ב‑Replace-Terms.
• Timeline — שמות ישויות מקודדים בתוך תבניות האירועים (“מכירה עודכנה”). דף נפרד, קריאה נפרדת. במערכת vanilla ה‑HTML של הדף אינו מכיל את המחרוזות האלה — הן מגיעות מתבניות חיצוניות; הריצו ובדקו את הספירה.

Replace-Terms על CRMmaster לבדו אינו מתפשט לדפים: אחרי החלפת “פניות”→“קריאות” במאסטר בלבד, דף Cases הציג עדיין “פניות” בכותרת, בתפריט ובגוף. המעבר פר דף הוא חובה.

מין דקדוקי בעברית

כשהמין מתהפך — “מכירה” (נקבה) ל“פרויקט” (זכר) — הפעלים בציר הזמן חייבים ללכת אחריו. רק בדף Timeline:

JSON

{ "pageId": "<TimelineId>", "terms": {
    "מכירה": "פרויקט", "מכירות": "פרויקטים",
    "עודכנה": "עודכן", "נוצרה": "נוצר"
} }

החלפת פעלים היא לדף הזה בלבד

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

מה לא משתנה

השכבה	ההתנהגות
סכימה — שמות טבלאות, שמות שדות, targetClass	לעולם לא. כל הגדרות ה‑API, ה‑MCP, הטריגרים והדוחות ממשיכות באנגלית
נתיבי דפים	לא משתנים. ה‑URL עדיין אומר Sales. מחלקות CSS ו‑data‑attributes כן מוחלפים אם המונח מופיע בהם (ראו האזהרה על Replace-Terms); מונחים בעברית כמעט אף פעם לא מופיעים שם
שמות תפקידים (role:Sales)	לעולם לא לשנות — מפתחות ה‑CLP נשברים. ראו הרשאות
תוויות השדות בסכימה (_Dictionary)	מנגנון נפרד: ה‑label ב‑Add-Field-to-Table. שינוי מינוח בדפים אינו מעדכן אותן רטרואקטיבית
תוכן תבניות מייל ו‑WhatsApp	נשמר במקום אחר — סקירה ידנית
דפי מובייל	דפים לכל דבר. חייבים להתגלות ולעבור החלפה כמו כל דף
דפים שנוצרו אחרי השינוי	דף שנוצר מתבנית מחזיר את המונחים הישנים. הריצו שוב אחרי כל תוספת דפים משמעותית

אימות

רענון קשיח (Ctrl+F5), ואז מסלול קבוע: תפריט צדדי ← דף רשימה (כותרת, כפתור, כותרות עמודות) ← דף כרטיס (כותרת ותוויות) ← כרטיס הלקוח (שמות הלשוניות) ← ציר הזמן (המסנן וגם טקסט האירועים) ← מודאל “הוספה” ← דשבורדים ← הגדרות.

בסוף — טבלה של דפים מול מספר החלפות.

כל שינוי דורש רענון

המינוח נטען עם הדף. משתמש שהמסך שלו פתוח ימשיך לראות את המונחים הישנים.

ביטול

השינוי סימטרי: המילון חוזר למיפויי זהות, Replace-Terms עם {"פרויקט": "מכירה", …} על כל הדפים שנגעתם בהם, והתפריטים ותוויות השדות חוזרים ידנית. שמרו את רשימת הדפים שערכתם — היא מה שהופך את הביטול לאפשרי.

המשך

• תפריטים — הכותרות שהמינוח לא מגיע אליהן לבד
• עריכת דפים ואלמנטים — change-existing-field-label
• הגדרות דף, קוד וגרסאות — כותרת הדף, וגרסאות כרשת ביטחון
• כלי סכימה — טבלאות ושדות — ה‑label שנכתב ל‑_Dictionary
• אתרים ודפים — קריאה — גילוי הדפים המושפעים
• אינדקס הכלים המלא