Global templates/Alternative solutions/he

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

הבעיה מתוארת ביתר פירוט ב ובפירוט אפילו רב יותר ב.

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

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

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



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

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

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

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



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

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

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

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

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

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



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



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

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

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

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

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

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



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

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

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

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



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

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

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



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

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

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

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

אז, גם ויקיפונקציות וגם תבניות גלובליות יזדקקו לאתר ויקי חדש שישמש כמאגר של קוד: תבניות, יחידות ופונקציות של חילול טקסט. שני המיזמים יזדקקו גם למנגנון מודרני לניהול תלויות (dependency management) והפצת שינויים (change propagation) לאתרי ויקי שונים, הידוע גם בשם "מנוע תלויות" (Dependency engine). אבל המטרות הסופיות של ויקיפונקציות ושל תבניות גלובליות הן שונות, והן ישלימו זו את זו. בגלל ההיכרות של העורכים איתן ובגלל מאגר עצום של קוד קיים ופעיל של יחידות ותבניות, הן צריכות להיות גלובליים וזמינות לעורכי ויקי. ויקיפונקציות אינן תחליף, אלא השלמה, וניתן לפרוס אותן בנפרד.



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

Another proposal that is somewhat similar to “Evolving wikitext” is making wiki syntax more structured for data, as a middle ground between the current, mostly structureless wikitext and a completely structured storage such as Wikidata. It is described on the page User:Tgr (WMF)/structured article data.

This is a valid proposal, and it addresses the need to balance between some communities’ desire to control the information locally in the pages and the need to process structured information semantically by software. However, like the “Evolving wikitext” proposal and some other proposals described on this page, it does not address the needs of the wikis that do not have people who have the necessary skills to maintain highly technical templates.

This proposal does not contradict the Global templates proposal, and both can be implemented. However, if this proposal is implemented without also making templates global, then at least in the foreseeable future it will most likely be used only in the largest wikis.

Make a package management system for easier copying of templates from one project to another
TL;DR: It sounds like a convenient thing for users, but actually, it is not scalable and going too far down this path will only complicate things.

At the moment, to copy a template from one wiki to another, the editor needs to export it as a wiki page from the source wiki, including some cascading pages, import it into the target wiki, search the wiki syntax for human-readable strings and translate them, and then fix any remaining errors. The result may work as needed, but it will be a fork of the source template. This is an extremely manual and difficult process, and the results are far from perfect.

Occasionally, there are proposals to make something like a package management for templates and modules, so that copying will become easier. However, this will also be a very partial solution. Even if it is done well, it will require running this copying process for each template, whereas a global repository will make all templates immediately available with zero extra steps. In fact, the system described on the page Multilingual Templates and Modules, along with the volunteer-developed DiBabel tool, already implemented something like this, and while it made it somewhat easier to copy templates between wikis and perform other steps described on the page about, it would always require repeated manual steps for every template. (As of early 2023, DiBabel is inactive.) This cannot scale for the thousands of templates that have to be shared.

Make gadgets global
אמל"ק: זה פותר בעיות שונות, אבל לא את הבעיה הנדונה.

Gadgets are pieces of JavaScript that are developed onwiki and packaged in a way that allows conveniently enabling and disabling them through user preferences.

Like templates, they belong to the “Local customizations” side of Wikimedia software, as described in the. The problems with gadgets are similar to the problem with templates: they cannot be easily ported from one wiki to another, and even the existing hacks for making them work across wikis, such as those that are used by the famous HotCat gadget, are imperfect. In addition, they do not have a convenient and uniform framework for localization, as there is for extensions.

It should be possible, therefore, to make gadgets global as well. In fact, “Global gadgets” came in at #1 at the 2016 Community Wishlist Survey, but was not implemented because it was deemed too big for the Community Tech team.

However, the technology for global gadgets will be quite different from the technology for global templates. Gadgets are purely frontend components, and even though they sometimes modify the page content, they mostly alter the user interface. The gadgets’ functionality is barely impacted by the parser and the MediaWiki backend (except maybe ResourceLoader).

Templates are different: they are strongly built into the content and rendered server-side, so they are strongly coupled with the core platform and especially the parser. In addition, gadgets are primarily used by power-users of the wikis, whereas the templates’ code is seen by all editors and the templates’ output is seen by all readers, so the templates’ impact is much larger.

The most relevant thing that may be common to global templates and gadgets is storing and managing their localization, but even this is not certain. The localization of their user interface strings (messages) may be similar, but templates have additional needs, such as the localization of the template name and the parameters.

So yes—while gadgets, templates, and modules should all be global, it probably makes sense to handle gadgets mostly separately from modules and templates.

Make a bot that copies templates from a central repository
TL;DR: It was made, and it tried to resolve the same problem, but it was imperfect and hard to maintain, and even the bot’s maintainer admitted it.

This is what the proposal is about. It is a reasonable approach given the current MediaWiki platform, but it has some disadvantages. In fact, that project’s own description page admits that it is not the best approach. It was developed as a bot called DiBabel, with a web-based frontend to synchronize the templates and modules across languages. As of early 2023, however, the DiBabel bot is abandoned and doesn’t work.

This bot approach required multiple manual steps for each template in each language. It did not have full-fledged translation tools for localizing the messages, and required manually editing wiki pages with JSON files instead.

Finally, it did not truly make templates available in all languages. This system still required the editors to opt in for each template in each wiki. This opt-in process is somewhat easier than the fully manual template importing process, but it still requires multiple steps for each template, so it's hardly scalable.

So yes, it may have been the most practical approach given the state of MediaWiki technology in 2021. Something of this kind can be attempted again and serve as a testing ground and a transition phase towards true support for global templates and modules in the software platform. But it cannot be a perfect and fully scalable solution.

Conclusion
There are many ways in which the technology around templates and modules could be improved. Some of them will clearly be beneficial to Wikimedia projects in various ways, and they should be carried out. However, none of them fully or even partially resolves the problem described in : the need to have features that are useful to multiple wikis and implemented as templates easily and immediately available to everyone who needs them, while preserving the ease and the agility of template development and deployment. Only the implementation of Global templates will resolve this problem comprehensively.