Global templates/Alternative solutions/he

תבניות ויחידות במיזמי ויקימדיה הן מקומיות לכל ויקי, וזה יוצר קשיים בשמישות, ביכולת גילוי (discoverability), בצדק הידע, בהפצת תוכן ובעיבוד נתונים מבניים.

הבעיה מתוארת ביתר פירוט בגרסה הקצרה של מפרט התבניות הגלובליות ובפירוט אפילו רב יותר בגרסה המלאה שלו .

הדפים שהוזכרו לעיל מציעים גם את הפתרון: לאפשר להפוך כמה תבניות ויחידות לגלובליות, בדומה לתמונות באתר ויקישיתוף, דפי JS ו־CSS אישיים גלובליים , דפי משתמשים גלובליים וכו'.

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

חלק מההצעות האלו אינן מטפלות בבעיה באופן מקיף, וחלק מהאחרות טובות בפני עצמן, אך מתייחסות לבעיות שונות. כל אחד מהפתרונות המוצעים האחרים האלו נדון בפרק נפרד בדף הזה. אם עדיין קשה לך להסכים עם משהו, אפשר לערוך את הדף הזה או לדון בו בדף השיחה. {{🌎🌍🌏}}

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

אמל"ק: טוב לעשות את זה עבור כמה תבניות ויחידות, אבל זה רחוק מלהיות אפשרי לעשות את זה עבור כולן.

ניתן להמיר כמה תבניות ויחידות להרחבות. יהיו לכך היתרונות הבאים:

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

עם זאת, יש גם כמה בעיות בגישה הזאת:

• שפות התכנות שונות: התבניות כתובות בתחביר ויקי והיחידות כתובות בלואה, ואילו ההרחבות כתובות ב־PHP וב־JavaScript. לפיכך, המרת תבנית דורשת שכתוב מלא, אשר, בתורו, דורש משאבים וזמן ניכרים.
• בעוד שהמוצר הסופי יכול להיות יציב יותר, יכולים להיכנס אליו באגים לאורך הדרך, כפי שקורה בכל שכתוב.
• מתחזקי תבניות רבים אינם יודעים PHP‏, JavaScript ו־Git. הם מעדיפים תחביר ויקי, לואה ועריכת דפי ויקי. ישנם אלפי מתחזקי תבניות וביטול הניסיון והמיומנות שלהם אינו הדבר הנכון לעשות, הן מבחינה חברתית והן מבחינה מעשית. אם התהליך מרחיק את מתחזקי התבניות ואת עורכי הוויקי, הם לא ישתמשו בהרחבות וימשיכו להשתמש בתבניות.
• התהליך הנוכחי של סקירת קוד (code review) והתקנה (deployment) בגריט איטי מאוד, במיוחד בהשוואה לפריסה מיידית של תבניות.

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

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

עם זאת, שכתוב של כל התבניות כהרחבות אינו אפשרי ואינו רצוי. {{🌎🌍🌏}}

למפות את הפרמטרים של התבניות הקיימות זה לזה

אמל"ק: זה כבר נעשה, וזה מועיל במידה מסוימת, אבל לא מסתלם.

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

הפתרון הזה אכן יכול להקל במידה מסוימת על בעיית חוסר ההתאמה. זה כבר נעשה בהרחבה ContentTranslation (תרגום תוכן) כטריק שמשתמש בכינויים שמוגדרים ב־TemplateData כדי למפות את הפרמטרים. זה הפך את תרגום הערכים בוויקיפדיה לקצת יותר יציב. זה משופר עוד יותר בתרגום תוכן באמצעות כמה טכניקות למידת מכונה כדי לחזות אילו פרמטרים צריך למפות (ר' T224721).

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

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

הצעת התבניות הגלובליות ממליצה על מערכת מרכזית ויציבה לתרגום של שמות פרמטרים (בפרק "תרגום פרמטרים"). זה יבטיח שיהיה אפשר להשתמש בכל הפרמטרים בכל ויקי ללא מאמץ כלשהו של העורכים, אף אם הם אינם מתורגמים במפורש. {{🌎🌍🌏}}

לשפר את טכנולוגיית התבניות

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

לשפר את תחביר הוויקי לפיתוח תבניות

אמל"ק: זה פותר בעיות אחרות, אבל לא את הבעיה הנדונה.

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

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

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

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

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

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

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

לאפשר כתיבת יחידות ב־JavaScript

אמל"ק: זה פותר בעיות אחרות, אבל לא את הבעיה הנדונה.

היו כמה הצעות לאפשר כתיבת יחידות Scribunto בשפות אחרות מלבד לואה, בעיקר ב־JavaScript. לדוגמה, ר' T61101 ושקופית 18 במצגת "בואו נשנה לחלוטין את איך שהתבניות עובדות".

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

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

לעדכן את ספריית פיתוח הפרונט־אנד

אמל"ק: זה פותר בעיות אחרות, אבל לא את הבעיה הנדונה.

בשנת 2019 (או אפילו מוקדם יותר), החלו דיונים רציניים על שדרוג ספריית פיתוח הפרונט־אנד של מדיה־וקי משילוב של jQuery‏, ResourceLoader ו־OOJS UI למשהו חדש (ר' T241180). זה גם הוצג כפתרון אפשרי לשיתוף תוכנת פרונט־אנד מבנית בין אתרי ויקי.

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

מעבר לספריית פיתוח פרונט־אנד חדשה יכולה להיות הזדמנות לשפר את הממשק בין קוד JavaScript לבין תבניות, אבל JavaScript, אפילו בצורה מודרנית, לא יכול להחליף את קוד הוויקי לחלוטין. מאגר תבניות גלובלי הוא הצעה לאחסון חדש של קוד ויקי (ולואה). {{🌎🌍🌏}}

ויקיפונקציות

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

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

פונקציות שנוצרות בוויקיפונקציות מקבלות פרמטרים מסוימים ומריצות קוד שאפשר להטמיע את הפלט שלו בדפי ויקי. בכך, הן דומות מאוד לתבניות ויחידות. הן גם מאוחסנות במקום אחד וניתן לקרוא להן מכל ויקי (אם שילוב ויקיפונקציות הותקן שם), כך שהן גלובליות. עם זאת, קיים הבדל מהותי בין אופן הפעולה של פונקציות לאופן שבו פועלות תבניות ויחידות: פונקציות יכולות להפיק רק טקסט רגיל (plain text) או גרסה מסוימת של HTML, שמפוענחת בנפרד משאר הדף שבו הם מוטמעים, בעוד שתבניות ויחידות מפיקות קוד ויקי שמפוענח כחלק מהדף. לפי הדף Wikifunctions:Embedded_function_calls, התוכנית היא שוויקיפונקציות לעולם לא יתמכו בקוד ויקי.

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

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

• תבניות כתובות הקוד ויקי ויחידות כתובות בלואה; פונקציות כתובות ב־JavaScript, בפייתון או בשפת ה"הרכבה" של פרויקט ויקיפונקציות עצמו.
• תבניות ויחידות יכולות להשתמש בהרחבה Translate לתרגום משפטים של ממשק משתמש; לפונקציות אין מערכת תרגום ממשק. הם יכולות לגשת ליחידות מילוניות ולתוויות בוויקינתונים, אולם אלה לא נבנו לשמש משפטים של ממשק משתמש.

לפיכך, פרויקט ויקיפונקציות אינו רלוונטי בתור פתרון למחסור בתבניות ויחידות גלובליות. {{🌎🌍🌏}}

לשלב נתונים מבניים לתחביר ויקי

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

הצעה נוספת שדומה במקצת ל"אבולוציה של קוד ויקי" היא הפיכת תחביר ויקי למובנה יותר עבור נתונים, כנקודת אמצע בין קוד הוויקי הנוכחי, חסר־המבנה ברובו, לבין אחסון מובנה לחלוטין כגון ויקינתונים. זה מתואר בדף User:Tgr (WMF)/structured article data.

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

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

ליצור מערכת ניהול חבילות להעתקה קלה יותר של תבניות מוויקי אחד לאחר

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

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

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

למעשה, המערכת המתוארת בדף Multilingual Templates and Modules, יחד עם הכלי DiBabel שפותח בהתנדבות, כבר הטמיעה משהו כזה, ואף שהיא הקלה ברמה מסוימת על העתקת תבניות בין אתרי ויקי ולבצע שלבים אחרים המתוארים בדף על המעבר לתבניות גלובליות , היא תמיד הייתה דורשת שלבים ידניים חוזרים ונשנים עבור כל תבנית. (נכון לתחילת 2023, מערכת DiBabel אינה פעילה.)

זה לא יכול להסתלם למאות אלפי התבניות שיש לשתף ביותר מאלף אתרי ויקי. {{🌎🌍🌏}}

להפוך את גאדג'טים לגלובליים

אמל"ק: זה פותר בעיות אחרות, אבל לא את הבעיה הנדונה.

גאדג'טים הם קטעי JavaScript שמפותחים בתוך הוויקי ונארזים בצורה המאפשרת הפעלה והשבתה נוחה באמצעות העדפות המשתמש.

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

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

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

עם זאת, הטכנולוגיה של גאדג'טים גלובליים תהיה שונה למדי מהטכנולוגיה לתבניות גלובליות. גאדג'טים הם אך ורק רכיבי פרונט־אנד, ולמרות שהם לפעמים משנים את תוכן העמוד, הם משנים בעיקר את ממשק המשתמש. הפונקציונליות של הגאדג'טים בקושי מושפעת מהמפענח ומהקצה האחורי של מדיה־ויקי (למעט אולי ResourceLoader).

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

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

אז כן – אף שגאדג'טים, תבניות ויחידות צריכים להיות גלובליים, כנראה הגיוני לטפל בגאדג'טים בנפרד מהיחידות ומהתבניות. {{🌎🌍🌏}}

ליצור בוט שמעתיק תבניות ממאגר מרכזי

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

בזה עוסקת ההצעה Multilingual Templates and Modules . זוהי גישה סבירה בהתחשב בפלטפורמת מדיה־ויקי הנוכחית, אך יש לה כמה חסרונות. למעשה, דף התיאור של המיזם עצמו מודה שזאת לא הגישה הטובה ביותר. הוא פותח כבוט בשם DiBabel, עם ממשק וב לסנכרון התבניות והיחידות בין השפות. נכון לתחילת 2023, הבוט DiBabel נטוש ואינו עובד.

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

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

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

(ניסיון אחר לעשות משהו דומה: Synchronizer.) {{🌎🌍🌏}}

סיכום

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

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

רק יישום של תבניות גלובליות יפתור את הבעיה הזאת באופן מקיף. {{🌎🌍🌏}}

ר' גם

• תבניות גלובליות/קשר לאסטרטגיה