Global templates/Proposed specification/he

  Татары, узбеки и ненцы И весь украинский народ, И даже приволжские немцы К себе переводчиков ждут. И может быть в эту минуту Меня на турецкий язык Японец какой переводит И в самую душу проник. —Осип Мандельштам זוהי טיוטת הצעה לדרישות פונקציונליות לתבניות ויחידות גלובליות.

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

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

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

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


 * 1) אנשים שיוצרים ומתחזקים תבניות ויחידות.
 * 2) אנשים שיוצרים ועורכים דפים שמכלילים תבניות ויחידות. זה כולל את כל העורכים ואת כל סוגי הדפים:
 * 3) * כל רמות הניסיון: מאלה שלגמרי חדשים עד כאלה עשו אלפי עריכות
 * 4) * כל סוגי כלי העריכה: עריכה בקוד ויקי, עורך חזותי, תרגום תוכן, ואחרים (אפילו מפעילי בוטים)
 * 5) * כל אתרי הוויקי: ויקיפדיה, ויקימילון, ויקימסע, ויקינתונים, אינקובטור, וכו', ומיזמים עתידיים
 * 6) * כל השפות: אנגלית, צרפתית, רוסית, ספרדית, ארמנית, פרסית, זולו, מניפורית, וכו'
 * 7) * כל סוגי הדפים: ערכי ויקיפדיה, דפי שיחה של ערכים, דפי שיחת משתמש, דפי דיונים של הקהילה, דפי מיזמים, קטגוריות, דפי תיעוד תבניות, וכו'.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

יש רק דוגמאות מעטות לתבניות שנעשו סמנטיות:


 * תבניות הערות שוליים מגוונות, ששמישות דרך כפתור "הערות שוליים" בסרגל עורך החזותי. נדרש לכתוב קוד נפרד ורב כדי להגדיר את Citoid בכל ויקי שרוצה להשתמש בהן.
 * "דרוש מקור", שנמצאת בתהליך אימוץ לעורך החזותי בספטמבר 2019. גם זה דורש הגדרות בכל אתר ויקי.
 * תבניות לאזכור משתמשים באמצעות ההרחבה Flow, שגם דורשות הגדרות מקומיות.
 * כלים לניתוחים ומחקרים בהיטלים (dumps) יכולים לפענח תבניות מיון והערכת איכות של דפים של מיזמים בוויקיפדיה האנגלית, שבדרך־כלל נוספות לדפי שיחה.
 * ההרחבה PageTriage מוגדרת לעבוד עם תבניות תחזוקה של ויקיפדיה האנגלית.

במקרה של PageTriage, ההרחבה למעשה רושמת במפורש בקוד שלה (hard-coded) שמות של תבניות בוויקי אחד, מה שגורם לה לא ראויה לשימוש באתרי ויקי אחרים ללא שכתוב מהותי. אף אם הצעד של ההגדרות המקומיות בוויקי הוא צעד קטן, כמו בדוגמה של Flow, זה עדיין חייב להיעשות. זה לא מסתלם (scalable) ל־900 אתרי הוויקי שיש לוויקימדיה, ולאלפים שיהיו בעתיד.

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

אחסון ואחזור
The global templates and modules can be stored in a central wiki (Meta, Commons, or a whole new wiki), and it can even be Gerrit or another repository.

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

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

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

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 people, among them Kunal Mehta (in the “Shadow namespace” project), Greg Grossmeier, Brion Vibber, Tim Starling, and others. 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.

There should be on-wiki tools for showing at least basic analysis of templates’ and modules’ usage on pages: the number of transclusions and invocations grouped by wiki, and lists of pages that use the templates and the modules. The feature that shows which templates does a page transclude while it’s being edited must continue working with global templates.

Templates must remain easy to modify
An important feature of how templates currently work is that they are edited just like wiki pages and immediately become functional after publishing without review or deployment. This is somewhat dangerous because a bad edit can ruin many pages, but the fact is that it works mostly well.

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
Not all templates should be forced to be 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.

It must be possible to override some functionality or appearance of a global template
No community should feel that a functionality is imposed on it by some powerful external player, like the English Wikipedia community, the Wikidata community, the WMF, or anybody else. Global templates should be developed and used collaboratively for the common benefit. Most of the time it should work for everybody. Sometimes some communities will have strong opinions about wanting to have particular functionality or design that will be different in their language or project, or to show an infobox with information that is different from what is shown in other projects, or not to show it at all. The capability to override things locally must be allowed from the start. (Or rather, it must not be taken away.)

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.

A global template must be immediately usable in every wiki
Just like a global user page is immediately available in every wiki in which there is no local user page, a template or a module that is created on the global infrastructure must be immediately usable in every wiki. This must not require copying wiki pages, creating wrapper templates with a local name, administrator intervention, waiting for hours for caches to refresh, etc.

It must be possible to translate all user-facing strings
Core MediaWiki, extensions, and some tools are translated conveniently and robustly on translatewiki.net. This localization process is familiar to at least some editors in all languages.

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.

The template documentation pages must be translatable as well. It's mostly enough to do it using the page translation feature of the Translate extension, but it may require some adaptations.

The language in which the strings are shown to the user
Templates are primarily used when they are integrated into content, so by default the translated messages must be shown in the wiki’s content language.

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.

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

Message keys and message storage
Messages should be represented as keys, similarly to how it is done in MediaWiki core, extensions, and tools.

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.

Organizing messages
The Translate extension organizes messages by groups, which can be further organized by aggregate groups. For example, Article Placeholder, Score, and Poem are all groups that represent the corresponding MediaWiki extensions, and they are all included in the “Extensions used by Wikimedia - Advanced” aggregate group, along with many other extensions.

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.

Finding how to get a template to translate
Every template description page needs to have a direct link to translating it to the user’s language.

Considerations for modules
Lua modules can load and parse translatable MediaWiki strings, but there is no defined way for storing these strings for Lua modules that are maintained as wiki pages. It is possible to package Lua modules as parts of extensions, and then they are able to load translatable strings from the extensions’ i18/*.json files, but this is done in very few extensions at the moment. Rewriting templates in Lua may be a more robust solution from the engineering point of view, but Lua will not necessarily be embraced by all existing template maintainers, and their cooperation will be crucial to the project’s success, so this cannot be done to all templates.

Localizing the template name
The template may have a different name in every language, but it must be directly connected to the central storage

Global templates and modules are supposed to be immediately usable in all wikis without any extra steps, so it must be possible to transclude a global template in a local wiki page using its global name. The cross-wiki editors community shall decide what will be the policy for these global names.

Similarly to parameter names, templates may have different names in different languages, and this must be preserved. There must be a structured way to translate template names. Perhaps Wikibase sitelinks can play a role, but not necessarily.

If this is not done, editors will either avoid global templates, or wrap the global template in a local template with a translated name, and this will probably cause the template to lose the connection to the global entity. This is not desirable and misses the whole point of the project.

Template names must only be translated to languages that can be content languages of wikis. Translation to Formal German or British English are probably unnecessary. There may be a way to have aliases or redirects. Language variants, for example for Serbian and Chinese, must be supported according to these languages’ needs.

If a local template exists in a wiki and it has the same name as a localized name of a global template, the local template will be used. This is similar to how local files with identical names override global files on Commons, and how local messages in the MediaWiki space override the localization coming from the code.

Lua module names are often localized, too. Their names can be localized for direct invoking from wiki pages, but since code usually uses English-like identifiers, the internal global names should probably be preferred for use in the code itself, for example in  statements.

Localizing named parameters
Parameter names are different in every language. They are usually based on words in each language, so it’s important for editing the transclusion in wiki syntax conveniently.

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?

Automatic parameter translation
If the localized template names and all the localized parameter names are stored centrally, it will possible to have a simple service that gets a valid template with parameters, a source language name, and a target language name, and outputs a localized template. For example:

Input:

Output:

In visual editing and in 2017-style wiki syntax editing, simply copying and pasting a template from wiki in another language will do the parameter translation automatically.

For plain wiki syntax editing, there should be a simple way to operate this service, for example a special page or a dialog box where an editor can paste the template and the source language, and get the template with translated parameters.

In both cases only the names of the template and the parameters will be translated. Translating the parameter values is discussed separately.

Nameless parameters
Nameless numbered parameters must continue working, of course.

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

Translating parameter values
In addition to making the templates’ functionality and design shared, some thought must be given to making the template parameter values shared, as well as not shared.

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.

Global templates must make this possible, but in practice, these things are still often copied across wikis, and this must be taken into account as well.

Some parameter values can be reliably and predictably converted automatically, and the global templates infrastructure must support this. For example, number formats and digit characters are often different in Burmese, in languages of India, and in some other languages, but they can be reliably converted using simple software.

Text direction
Templates must adapt themselves to the text direction (ltr / rtl) of the wiki in which they are displayed.

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

For easier translation of content, templates that are common in the largest projects must become global
The most popular source language for translation in Content Translation is English, by far. After it come Spanish, Russian, French, German, Catalan, Ukrainian, Italian, Chinese, and Portuguese. Because of this, it makes sense that the common templates in the most common languages, especially those in English, are the ones that are the most important to make global for the benefit of all other languages.

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


 * The templates already work well for them and most people there don’t directly care about the convenience of translation to other languages.
 * Rewriting the templates so that the strings will be translatable may be time-consuming and may force them to change their template maintenance skills.
 * Making the templates suddenly used by many more projects may make it harder to achieve consensus about making future changes in how the templates work.

This is more a consideration of practicality and community relations than a consideration of engineering, but it must be taken into account when making technical architectural decisions. Without doing proper preparation in this area, the whole project may fail.

It must be possible to use templates completely in both wiki syntax and in visual editing
It’s obvious, but should be mentioned anyway: Wiki syntax editing is not going away soon, and it must be possible to keep editing template transclusions in pages as it is done now. This must not become more complicated.

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.

Extra templates features
There are some extra features of core and extensions around templates. All of them must continue working, and may need updating for the global templates age.

TemplateData

 * Template description must be translatable, just like other user interface strings.
 * Parameter names, aliases, and descriptions must be centrally translatable.
 * Wikitext format parameter (inline, block, custom) must keep working.

TemplateStyles

 * There must be a possibility to write Template Styles pages in the same central repository as templates. The central style must be loaded by default, and it must be possible to override it locally.

TemplateSandbox

 * Special:TemplateSandbox must keep working.
 * It must be possible to edit a template in the central repository and preview it in a page in the target wiki.

TemplateWizard

 * Uses a wiki’s standard search to find templates. The results are presented in a list that might need to be changed to make the global/local status visible.
 * TemplateWizard gets its information for templates from the TemplateData API, so as long as that keeps returning the same structure there shouldn’t be any issues, and i18n is already working.

Wikibase

 * Wikidata can be used to bring in some parameter values from a central repository to the wiki. This is used productively in several wikis, among them French, Hebrew, Basque, Catalan, Estonian, and some others, although the actual implementation may differ. This must continue working, of course. Unifying the way in which it is done across different wikis may become one of this project’s most significant impact areas.
 * It may also affect the project of editing template values from within wikis.

VisualEditor

 * VisualEditor obviously needs to be able to insert both global and local templates.
 * VisualEditor shows a link to the template description page in the template editing dialog. This link should point directly to the global template when it is used.

Making templates easily reusable on non-Wikimedia projects may be desirable, too
Even though it doesn’t directly benefit Wikimedia projects, it may make sense to consider making templates easily reusable not only across Wikimedia projects, but also on other MediaWiki sites. Doing this will probably require some more work, but it may contribute to better modularization, and this may eventually benefit Wikimedia projects, too.

This is comparable to the capability of direct embedding of images from Commons on non-Wikipedia websites.

Imagine a world
Imagine a world in which every single human being can freely share in the sum of all knowledge and it's actually a really easy thing to do because templates are global:

(Note: The "With global templates" column assumes that the infrastructure is deployed in all Wikimedia wikis, and that the most often used templates are moved to the central infrastructure.)

Status
As noted above, as of October 2019, this page is only an idea, and not a commitment to implement a project.

The Platform Evolution project (2018) indicated some intentions to have support for global templates in the future. The page Platform Evolution/Recommendations discusses ideas for updating content modularity, and says:
 * ... “boxes” are an ideal focus area for creating modularity. They represent self contained features and also an opportunity to enable equitable sharing of user features across projects and languages be establishing a cross-project service to share templates. This project will also force us to consider how to handle content layout and structure separately from composable pieces content.

The closely related page Platform Evolution/Goals lists this as one of the goals:
 * Increase equity and power of contribution tools. We want to support the contribution of more content types of content, including media, in more interactive ways and across all projects. This means making some existing tools - like templates - available for consistent reuse across all projects and languages. It also means improving translation tools to remove silos of content. Finally, we also want to make it easy for contributors to create new cross-project, localizable content tools.

Other than these goals, however, there is no detailed plan for how such a feature will work. This page is an attempt to propose such a plan and listen to feedback from editing communities.

Useful links
Some relevant pages that discuss similar topics:
 * Platform Evolution/Goals
 * Platform Evolution/Recommendations
 * Multilingual Templates and Modules - An attempt to implement a similar feature using bots
 * meta:Community Wishlist Survey 2015/Results - Central Global Repository for Templates, Lua modules, and Gadgets came in as #3 in the Community Wishlist vote. Listed as “In development - Parsing team”, but not actually done.
 * meta:Which templates should be global? - an informal list made by various editors