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

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

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

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

שמות טבלאות ושמות שדות בסכימה לעולם לא משתנים. 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 = {…}); מונח מובנה שלא שלחתם חוזר למיפוי זהות (מאומת: אחרי Set עם מכירה+פנייה ואז Set עם מכירה בלבד — פנייה חזרה ל“פנייה”).

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. שינוי מינוח בדפים אינו מעדכן אותן רטרואקטיבית (מאומת: _Dictionary לא השתנה)
תוכן תבניות מייל ו‑WhatsApp	נשמר במקום אחר — סקירה ידנית
דפי מובייל	דפים לכל דבר. חייבים להתגלות ולעבור החלפה כמו כל דף
דפים שנוצרו אחרי השינוי	דף שנוצר מתבנית מחזיר את המונחים הישנים. הריצו שוב אחרי כל תוספת דפים משמעותית

אימות

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

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

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

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

ביטול

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

רשימת הדפים שערכתם היא מה שהופך את הביטול לאפשרי — שמרו אותה.

המשך

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