Global templates/Proposed specification/he

  Татары, узбеки и ненцы И весь украинский народ, И даже приволжские немцы К себе переводчиков ждут. И может быть в эту минуту Меня на турецкий язык Японец какой переводит И в самую душу проник. —Осип Мандельштам

זוהי הצעה לדרישות פונקציונליות לתבניות ויחידות גלובליות.

אפשר גם לקרוא גרסה בעמוד אחד של ההצעה הזאת.

'''This is not a project that is being executed or planned to be executed by anyone at any defined point in time, at least not yet. This is just an idea, albeit a very detailed one.'''

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

This document does not try to go into the details of technical implementation in terms of storage, caching, delivery, PHP code design, etc. It only tries to define the requirements of how this feature will work from the point of view of the users:


 * 1) People who create and maintain templates and modules.
 * 2) People who create and edit pages that transclude templates and modules. This is includes all editors and all kinds of pages:
 * 3) * All levels of experience: From those who are completely new to those who have made thousands of edits
 * 4) * All kinds of editing tools: wiki syntax editing, Visual Editor, Content Translation, and others (even bot operators)
 * 5) * All wikis: Wikipedia, Wiktionary, Wikivoyage, Wikidata, Incubator, etc., and any new future projects
 * 6) * כל השפות: אנגלית, צרפתית, רוסית, ספרדית, ארמנית, פרסית, זולו, מניפורי, וכו'
 * 7) * כל סוגי הדפים: ערכי ויקיפדיה, דפי שיחה של ערכים, דפי שיחת משתמש, דפי דיונים של הקהילה, דפי מיזמים, קטגוריות, דפי תיעוד תבניות, וכו'.

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

הבעיה
הערה כללית: אלא אם נאמר אחרת, כל אזכור של "תבניות" מתכוון גם ליחידות לואה (Scribunto).

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

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

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

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

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

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

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

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

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

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

התלונות הנפוצות ביותר בנושא כלי תרגום תוכן נוגעות לתבניות.

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

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

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

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

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

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

Difficulties for software developers
For developers of MediaWiki core, extensions, bots, and other tools that analyze, generate, or modify wiki page content it is difficult to develop features that depend on the presence of certain templates in a wiki. Developers of extensions such as GrowthExperiments, PageCuration, ContentTranslation, some components of Wikibase, and many others, have to either test them in production, which is a bad idea, or to import the templates to their local wikis or an online test wiki.

Researchers who get data about wiki content based on templates have to write their analysis code for each wiki separately, and sometimes they end up doing for only one wiki. A notable example is using English Wikipedia’s WikiProject templates to analyze page topics and assess article quality.

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

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

Templates and modules development skills
Another important set of assumptions on which this proposal is based is the following:
 * The skills for developing templates and modules are non-trivial. Both templates and modules have a lot of obscure features.
 * Even though many of the sites’ most notable features are implemented as templates and modules, these skills are often underappreciated and taken for granted.
 * There are dozens of people who have these skills, and they edit many different wikis. They usually focus on their home wiki and relatively rarely communicate with people from other wikis or other languages. Even though the underlying technology is the same everywhere, there is no true global community of template developers that would be comparable to the global community of MediaWiki core and extensions developers. There are cases of cross-wiki collaboration on certain templates, but they are inconsistent.
 * There are also many wikis in which there are no editors who have these skills. They either copy templates and modules from other wikis without fully understanding how they work and without the ability to localize and maintain them effectively, or they don’t use templates at all.

This situation is far from optimal. The template and module developers’ skills need more appreciation. They develop truly needed features, and they are embedded in their editors communities. In wikis in many languages, the template developers come up with innovative features for structured content, data presentation, and modularization. These innovations could be useful in many wikis, but currently there is no convenient mechanism to achieve this.

And of course, any solution for these problems must not come up with completely new technologies that will discard the many years of hands-on experience that the template maintainers have acquired. Hence, there must be as few changes as possible in the syntax for developing templates and modules. The things that need to change are the way in which they are deployed and propagated across wikis, and the way in which the human-readable strings in them are localized (translated).

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

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

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

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

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

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

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

תרגום תבניות יהיה נוח כמו תרגום הרחבות מדיה־ויקי.

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

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

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

There are few examples of templates that were made semantic:


 * Various reference templates, which are usable from the Visual Editor toolbar “Cite” button. They require writing a lot of separate code to configure Citoid on each wiki that wants to use them.
 * “Citation needed”, which is being adapted to Visual Editor as of September 2019. It also requires configuration on each wiki.
 * Templates for mentioning users in the Flow extension, which require local configuration, too.
 * Some dump processing and research tools can parse English Wikipedia’s WikiProject assessment templates, which are usually added to talk pages.
 * The PageTriage extension is configured to work with English Wikipedia’s hatnote templates (also known as “tags”).

In the case of PageTriage, the extension essentially hard-codes a single wiki’s templates, making it unusable in other wikis without a significant rewrite. Even if the on-wiki configuration step is small, as it is with the Flow example, it still needs to be done. This doesn’t scale well for the 900 wikis that Wikimedia has, and the thousands that it will have in the future.

These things should be global by default, so that they will be immediately usable in at least a basic default configuration on all wikis at once by extensions, bots, dump analyzers, etc.

Storage and delivery
תבניות ויחידות גלובליות יכולות להיות מאוחסנות בוויקי מרכזי (מטא, ויקישיתוף, או ויקי חדש), ואפילו בגריט (Gerrit) או במאגר אחר.

The best solution is probably creating a new wiki that will store them, without getting mixed up with images, general community discussion, etc.

Using Gerrit as storage for templates and modules code is technically possible, but it would lose an important element of accessibility for template maintainers: editing a template in a wiki page is much easier and familiar to the vast majority of template maintainers than making Git commits and waiting for code review. Therefore, Gerrit probably shouldn’t become a way for storing the template and module code, at least not the primary one.

Global templates and modules must be stored in a common repository that can be edited by most wiki editors. Rules about blocking and special permissions should initially be similar to the rules in other wikis: everything should be open by default, and it must be possible to protect very common, sensitive, or frequently-vandalized templates. Further rules about protection levels can be developed by the editors community later.

How the templates are delivered to the target wikis is a question of internal engineering and architecture, as long as the other requirements are addressed. These questions were discussed in the past by some platform developers, for example around the Shadow namespaces project. This document tries to address related questions of how it works for the user who edits a page that uses a template, or who maintains the template itself—how to write it in a localizable way; how is it translated; how is it locally customized; etc. These questions weren’t addressed sufficiently in the previous architectural discussions on the topic.

Templates must remain easy to modify
מאפיין חשוב של איך שהתבניות עובדות כעת הוא שהן נערכות פשוט כמו דף ויקי ונהיות פעילות מייד לאחר הפרסום, ללא סקירה או התקנה. זה מעט מסוכן כי עריכה גרועה יכולה להרוס דפים רבים, אבל העובדה היא שרוב הזמן זה עובד טוב.

This ease must be preserved. Community members who maintain templates will most likely reject moving to a new system that will require them to learn completely new skills and drag every change through an exhausting review and deployment phase. This probably rules out storing the templates in Gerrit, unless, perhaps, the process for review and deployment will be much easier than it is for extensions.

It must be possible to make some templates non-global
אין לכפות על כל התבניות להיות גלובליות.

In fact, some templates should be local because they implement a functionality that is unique to a certain language. By their nature, such templates don’t need to be translated, and there should be a way to give a hint to both human editors and translation tools (such as Content Translation) that they don’t need to be adapted, and can be skipped or substituted. This is a part of the effort to make templates more semantic.

It must be possible to override some functionality or appearance of a global template
שום קהילה לא צריכה לחוש שפונקציונליוּת כלשהי נכפית עליה מטעם שחקן חיצוני חזק כלשהו, כגון קהילת ויקיפדיה האנגלית, קהילת ויקינתונים, קרן ויקימדיה, או מישהו אחר. תבניות גלובליות אמורות להיות מפותחות בשיתוף פעולה למען טובת הכלל. רוב הזמן זה אמור לעבוד טוב לרוב האנשים.

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

A global template must be immediately usable in every wiki
כשם שדף משתמש גלובלי זמין מייד בכל ויקי שאין בו דף משתמש מקומי, כל תבנית או יחידה שנוצרה בתשתית הגלובלית צריכה להיות זמינה מייד בכל ויקי.

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

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

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

It must be possible to translate all user-facing strings
מחרוזות ממשק משתמש (הידועות גם בשם "הודעות מערכת") של תוכנת מדיה־ויקי, ההרחבות שלה, וחלק מהכלים החיצוניים (כגון Pageviews) מתורגמים באופן נוח ויציב באתר translatewiki.net. תהליך התרגום הזה מוכר לפחות לחלק מהעורכים בכל השפות.

It’s currently not possible to do the same with templates. Multilingual sites such as Commons and mediawiki.org have the “TNT” system for translating some templates, but it’s very complicated and cannot be reused for Wikipedia, Wikisource, etc.

Ideally, it should be possible to translate templates just like core and extensions, using a wiki with the Translate extension.

The translated string must become usable immediately after the translation is submitted using the translate interface.

It can be possible to edit the user interface strings in raw wiki pages, but ideally they should be edited primarily through a dedicated translation interface.

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

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

The language in which the strings are shown to the user
תבניות משמשות בעיקר כשהן משולבות בתוכן, ולכן ברירת המחדל צריכה להיות שההודעות תוצגנה בשפת התוכן של הוויקי.

Some templates, however, are used as UI elements, so perhaps it makes sense to also allow showing the translated strings in the user language, when it’s different from the wiki content language. This may be particularly relevant for multilingual sites such as Commons, Wikidata, Meta, and mediawiki.org.

MediaWiki’s usual fallback chains must be used when a translation is not available.

Message keys and message storage
הודעות צריכות להיות מיוצגות עם מפתחות, בדומה לאיך שזה נעשה במדיה־ויקי, הרחבות, וכלים חיצוניים.

Writing translatable strings will probably be the largest change in the template development process that template maintainers will have to get used to. Hard-coded strings will have to be separated and moved to messages organized by key. It must be made as easy as possible not only for the translators, but also for the template maintainers. Otherwise, they won’t actually do it, and the feature will be effectively rejected.

To easily make keys globally unique, it’s probably OK to automatically include the global template name in the message key.

Transitioning tools
A tool can be developed that will help the transitioning of a template or a module to central storage. It can do the following steps:
 * 1) Export a template from a local wiki and import it into the global wiki.
 * 2) Export all the templates that are used by this template (cascading).
 * 3) Identify the human-readable strings, convert them to a list with keys, and replace them with keys in the template’s source code.
 * 4) Import the template’s documentation page and TemplateData.

In most cases, this automatic process probably cannot create a fully usable and robust template or module, but it can help begin the transitioning process.

Organizing messages
ההרחבה Translate מארגנת הודעות בקבוצות (groups), הידועות גם בשם פרויקטים (projects), שיכולות להיות מאורגנות בקבוצות משולבות (aggregate groups). למשל Article Placeholder‏, Score‏, ו־Poem הן קבוצות שמייצגות את הרחבות המדיה־ויקי עם השמות האלה וכולם כלולים בקבוצה המשולבת "Extensions used by Wikimedia - Advanced", יחד עם עוד מספר הרחבות.

Projects that represent MediaWiki extensions are configured in YAML files in the translatewiki repository and shown in the Translate user interface in a project selector, also known as message group selector.

Since there are many more templates than extensions, some modifications may be needed in the way the Translate extension handles message groups to accommodate templates translation.

Each template should be a message group. Closely related templates should be grouped in an aggregate message group. They can be similar to the categories in which they are stored, and in fact, the categories may even be reused. Editing files in a Git repository to organize these message groups is probably not desirable, because it’s too complex and slow.

It would be nice to show group and template names as localized in the selector, but it’s also OK if they are shown in English. If it’s good enough for extension localizers, it’s good enough for template localizers, too.

Templates must be shown as message groups on the Translate extension’s Language statistics special page (Special:LanguageStats). This will help localizers find what templates need translation. This should be generally similar to all message groups, but there are some special considerations for templates:
 * There will be thousands of templates, so it will be nice if the table’s design corresponds to this somehow.
 * The table should show on how many pages is each template transcluded and make it possible to order the rows by this number, to help localizers prioritize what is more important to translate.

Finding how to translate a template
כל דף תיאור תבנית צריך להציג קישור ישיר לתרגומה אל השפה של המשתמש.

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

Message parameters and magic words
In core MediaWiki and extensions, many message have parameters (sometimes also known as placeholders). They are named $1, $2, etc. They are filled in run time. They are particularly important for making messages robustly translatable because different languages have different word order.

Something like this is needed in templates, too, although it is possible that the form does not have to be $1, $2, but template-like parameters with triple curly braces ( { – } ). This is to be decided according to considerations of parsing and localization convenience.

The magic words PLURAL, GENDER, and GRAMMAR must be supported in template messages as in MediaWiki messages.

Message documentation
In core MediaWiki and extensions, every translatable message is documented for the convenience of developers and translators. The documentation may include information about where the message appears, what the $1, $2, etc. parameters are, whether the word is a verb or an adjective, etc. This documentation is stored as pseudo-language with the code qqq.

Such documentation will be useful for template translation, too. How it is stored is a question of technical architecture—perhaps it can be combined with TemplateData, perhaps it can be stored as a qqq language, and perhaps it can be something else.

Source language
Templates will be imported to the global storage not only from English-language projects, but from wikis in many different languages. More than ever, the localization tools must support translation from any language and not only from English.

Fuzzying
In core MediaWiki and extensions and in translatable pages, if the source message in English changes, the message is automatically marked as outdated or “fuzzy”. The existing translations continue to work, but are shown to translators as needing an update. (The translation manager can also mark a message as not needing fuzzying.)

A similar mechanism will be needed for template localization. However, since it would be nice not to force English as the source language, there should be more ways to mark messages as fuzzy.

Localization considerations for modules
יחידות לואה יכולות לטעון ולפענח הודעות מדיה־ויקי, אבל אין דרך מוגדרת לאחסן מחרוזות כאלה עבור יחידות לואה שמאוחסנות בתור דפי ויקי. אפשר לארוז יחידות לואה כחלק מהרחבות ואז הן יכולות לטעון הודעות מקובצי i18n/*.json של הרחבות, אבל כעת זה נעשה בהרחבות מעטות מאוד. שכתוב תבניות בלואה הוא פתרון איכותי מבחינה הנדסית, אבל לא כל מפתחי התבניות יעברו לשימוש בלואה, ושיתוף הפעולה שלהם חיוני להצלחת הפרויקט הזה, אז אי־אפשר לעשות את זה לכל התבניות.

Some very internal, technical modules that are commonly used, rarely changed, and don’t require internationalization can probably be painlessly moved into the Scribunto extension itself. Some examples are No globals and Arguments.

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

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

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

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

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

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

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

Localizing parameter names
שמות של פרמטרים שונים בכל שפה. הם בדרך־כלל מבוססים על מילים בכל שפה, ולכן זה חשוב לעריכה נוחה של הכללות בקוד ויקי.

Ideally, the global template should have generic internal parameter names that have translations to different languages. This is somewhat similar to Wikidata property name labels, but it can be simpler: since English is a kind of a lingua franca for software developers and templates are a kind of software, it’s probably OK to have English as the default source language rather than generic numbers as it is in Wikidata.

These translations of parameter names must be validated:


 * they must not include invalid characters
 * they must not be repeated within one template in one language
 * Anything else?

The actual process of translating the parameter names may be different from translating user interface strings. These names have technical constraints, and they must remain stable because changing a name of parameter will break existing transclusions, so there should be some safeguards against this.

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

קלט:

פלט:

בעריכה חזותית ובעורך קוד מקור 2017 העתקה והדבקה פשוטה מוויקי בשפה אחרת תעשה את תרגום הפרמטרים באופן אוטומטי.

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

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

Nameless parameters
פרמטרים ממוספרים חסרי שם חייבים להמשיך לעבוד, כמובן.

A decision is needed about how will their names be localized.

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

Some parameter values are the same in all languages by their nature. For example an IPA pronunciation of a place’s native name (e.g. [dɛn ˈɦaːx] for The Hague), the year of foundation of a city, the chemical formula of a compound, etc. At least some of these should probably be stored in Wikidata and easily loadable in a template.

Some parameter values have to be translated or transliterated, for example people’s names, translations of country mottos, etc.

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

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

Valid and functional parameter values must be usable in multiple languages and not language-specific. For example, using “yes” and “no” as boolean values is too English-centric. This probably doesn’t require changes in the infrastructure, but mostly an agreement in the cross-wiki template development community on good practices for adaptation to multiple languages.

Text direction
תבניות צריכות להתאים את עצמן לכיוון הטקסט (משמאל לימין / מימין לשמאל, ltr / rtl) של הוויקי שבו הן מוצגות.

It must be convenient to write a template in a direction-neutral way, with as little explicit right and left alignment as possible.

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

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

Transitioning the templates from the large wikis to central storage
 וּמֵעֵבֶר לְשׁוּרַת הַבְּרוֹשִׁים עָבְרָה הָרַכֶּבֶת אֲבָל אֲנַחְנוּ רַק שָׁמַעְנוּ אוֹתָהּ, וְלֹא רָאִינוּ. וְכָל הַדְּבָרִים שֶׁדִּבָּרְנוּ בֵּינֵינוּ הִתְחִילוּ בַּמִּלִּים, „אֲבָל אֲנַחְנוּ”. —יהודה עמיחי שפת המקור הנפוצה ביותר ליצירת ערכים באמצעות תרגום תוכן היא אנגלית, בפער גדול. אחריה באות ספרדית, רוסית, צרפתית, גרמנית, קטלאנית, אוקראינית, איטלקית, סינית, ופורטוגלית. בגלל זה, הגיוני שהתבניות הנפוצות ביותר במהדורות של ויקיפדיה בשפות הנפוצות ביותר, במיוחד באנגלית, הן החשובות ביותר שצריך להפוך לגלובליות לטובת כל שאר השפות.

Somewhat paradoxically, however, the editors in these largest languages are also the least interested in making them global:


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

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

As long as there are important common templates that are not global, Content Translation will have to keep supporting them. If the infrastructure for global templates is created, and migration of existing templates proceeds in a good pace, then Content Translation developers may consider stopping developing and some day deprecating the code for non-global template adaptation.

The pace of migrating templates from large wikis to the central repository can be one of the success metrics for the project.

It must be possible to use templates completely in both wiki syntax and in visual editing
זה מובן מאליו, אבל חייב להיות מוזכר: עריכת קוד ויקי לא תיעלם בקרוב, ולכן זה צריך להמשיך להיות אפשרי לערוך הכללות תבניות בדפים כמו שזה נעשה עכשיו. זה לא צריך להפוך לדבר מסובך יותר.

However, Visual Editor is increasingly embraced by both experienced and new editors, so every feature of how templates work must work well in both Visual Editor and wiki syntax editing.

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

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

דף "דפים המקושרים לכאן" צריך להמשיך לעבוד, ולהישאר שימושי להכללות גלובליות.

נתוני תבנית (TemplateData)

 * It is possible to translate template and parameter descriptions in TemplateData, and the translations are displayed in the user interface language in Visual Editor’s template insertion dialog. This is good and must be preserved. The translation interface could possibly be improved, but the beginning is good. Adding support for TemplateData in the Translate extension can be a solution for this, but there can also be other solutions.
 * פרמטר "עיצוב קוד ויקי מוצע" (בשורה, בפסקה, מיוחד) צריך להמשיך לעבוד. צריך להיות אפשרי גם להתאים אותו לכל ויקי – חלק מאתרי הוויקי יעדיפו לראות תבניות מסוימות כתובות בקוד ויקי בשורה אחת, ואחרים יעדיפו שורות מרובות.

סגנונות תבנית (TemplateStyles)

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

ארגז חול לתבניות (TemplateSandbox)

 * הדף ארגז חול לתבניות (Special:TemplateSandbox) חייב להמשיך לעבוד.
 * צריך להיות אפשרי לערוך תבנית במאגר המרכזי ולעשות תצוגה מקדימה שלה בוויקי היעד.

אשף התבניות (TemplateWizard)

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

ויקיבייס (Wikibase)

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

העורך החזותי (VisualEditor)

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

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

זה בר־השוואה ליכולת להטמיע תמונות מוויקישיתוף ישירות באתרים שאינם ברשת ויקימדיה.

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

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

מצב
 А мы всё молчим, Мы всё считаем и ждём; Мы всё поём о себе, О чём же нам петь ещё? —Борис Гребенщиков כמו שנאמר לעיל, נכון לאוקטובר 2019, הדף הזה הוא רק רעיון, ולא התחייבות ליישם פרויקט.

פרויקט Platform Evolution (משנת 2018) ציין כוונות מסוימות לתמוך בתבניות גלובליות בעתיד. הדף Platform Evolution/Recommendations דן ברעיונות לעדכון המודולריוּת של התוכן ואומר כך:
 * ... "תיבות" הן אזור התמקדות מושלם ליצירת מודולריוּת. הן מייצגות יכולות ארוזות והזדמנות להפעיל שיתוף שוויוני של אפשרויות משתמש שיחצה מיזמים ושפות על־ידי יצירת שירות חוצה־מיזמים לשיתוף תבניות. הפרויקט הזה גם יכריח אותנו לשקול איך לטפל בעימוד תוכן ומבנה בנפרד מרכיבים שאפשר לבנות מהם תוכן.

הדף הקשור Platform Evolution/Goals מכיל את זה בתור אחד מהיעדים:
 * להגדיל את השוויוניות ואת העוצמה של כלי התרומה. אנחנו רוצים לתמוך בתרומה של יותר סוגים של תוכן, בדרכים יותר הידודיות ובכל המיזמים. זה אומר שיהיה צורך להפוך חלק מהכלים הקיימים – כגון תבניות – זמינים לשימוש חוזר עקבי בכל המיזמים והשפות. זה גם אומר שיש לשפר את כלֵי התרגום כדי לסלק מאגרים סגורים של תוכן. לבסוף, אנחנו רוצים להקל על עורכים ליצור כלֵי תוכן חדשים וחוצי־מיזמים שאפשר לתרגם.

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

קישורים שימושיים
מספר דפים רלוונטיים שדנים בנושאים דומים:
 * Platform Evolution/Goals
 * Platform Evolution/Recommendations
 * Multilingual Templates and Modules - ניסיון לממש יכולת דומה באמצעות בוטים
 * meta:Community Wishlist Survey 2015/Results - Central Global Repository for Templates, Lua modules, and Gadgets הצעה לממש דבר כזה הגיעה למקום השלישי בהצבעה על משאלות הקהילה. רשום בתור "בפיתוח - צוות Parsing", אבל לא באמת מתבצע.
 * meta:Which templates should be global? - רשימה בלתי־פורמלית שכתבו מספר עורכים
 * Requests for comment/Shadow namespaces - בקשת הערות (RFC) בלתי־פעילה על הצעה למימוש טכנית של תשתית כזאת
 * Manual:$wgEnableScaryTranscluding - מנגנון בסיסי קיים להכללה של תוכן שחוצה מיזמים. נחשבת לבלתי־יעילה ובלתי־מאובטחת, וכבויה במיזמי ויקימדיה.
 * meta:Global-Wiki - a similar proposal, with a wider scope. Was open for discussion for several years, and closed as "consensus". Some things in it were implemented, such as global user pages and preferences, but it also includes global templates, which are not yet done.