Global templates/Proposed specification/he

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

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

ניתן למצוא תיאור של ההצעה הזאת באורך של עמוד אחד בדף Global templates/Draft spec/TLDR.

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

המצב הרצוי ביותר הוא לתרגם תבניות בדיוק כמו את מדיה־ויקי ואת ההרחבות באמצעות ויקי עם ההרחבה Translate.

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

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

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

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

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

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

שרשראות הגיבוי (fallback) הרגילות של מדיה־ויקי צריכות לשמש כאשר אין תרגום זמין.

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

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

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

כלֵי העברה
ניתן לפתח כלי שיעזור להעביר תבנית או יחידה לאחסון מרכזי. הוא יכול לבצע את הצעדים הבאים:
 * 1) לייצא תבנית מוויקי מקומי ולייצא אותה אל הוויקי הגלובלי.
 * 2) לייצא את את כל התבניות שמופיעות בתבנית הזאת (באופן מדורג, cascading).
 * 3) לזהות מחרוזות בשפה אנושית, להמיר אותם לרשימה עם מפתחות, ולהחליף אותם במפתחות בקוד המקור של התבנית.
 * 4) לייבא את דף התיעוד של התבנית ואת נתוני התבנית (TemplateData).

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

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

פרויקטים שמייצגים הרחבות מדיה־ויקי מוגדרות בקובצי YAML במאגר translatewiki בגריט ומוצגות בממשק המשתמש של Translate בבורר הפרויקטים, הידוע גם כבורר קבוצות הודעות.

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

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

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

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

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

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

משהו כזה נחוץ גם בתבניות, אם כי ייתכן שזה לא חייב להיות בצורה של $2, $2, אלא בצורה של פרמטרים של תבניות, עם סוגריים מסולסלים משולשים ( { – } ). זה יוחלט בהתאם לשיקולי נוחות פענוח ותרגום.

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

תיעוד הודעות
בליבת מדיה־ויקי ובהרחבותיה, כל הודעה מתועדת לשם נוחות המפתחים והמתרגמים. תיעוד כזה יכול לכלול מידע על איפה ההודעה מופיעה, מהן הודעות $1, $2, האם מילה היא פועל או שם־תואר, וכו'. התיעוד הזה מאוחסן בתור שפת־דמה עם הקוד qqq.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

התרגומים של שמות הפרמטרים צריכים לעבור בדיקות תקינות:


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

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

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

קלט:

פלט:

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

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

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

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

צריכה להתקבל החלטה על שיטת התרגום שלהם.

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

חלק מערכי הפרמטרים יהיו זהים בכל השפות מטבעם. למשל, הגייה של שם מקום באלפבית פונטי בין־לאומי (למשל [dɛn ˈɦaːx] עבור העיר האג), שנת הייסוד של היער, נוסחה של תרכובת כימית, וכו'. לפחות חלק מאלה יכולים להתאכסן בוויקינתונים ולהיטען בתבנית.

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

סגנונות תבנית (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 - מנגנון בסיסי קיים להכללה של תוכן שחוצה מיזמים. נחשבת לבלתי־יעילה ובלתי־מאובטחת, וכבויה במיזמי ויקימדיה.