This page is a translated version of the page Global templates/Proposed specification and the translation is 72% complete.

這是一項針對全域模板和全域模組的功能需求的提案。

你也可以閱讀本提案的一頁式版本

这不是任何人在任何定义的时间点正在执行或计划要执行的项目,至少现在还没有。这尽管非常详细,都只是一个想法。

最终目标是通过适当的架构、产品、项目管理和社群参与等方面,来实现一个跨团队和跨项目的承诺。

本文档不試圖深入探討關於存储、缓存、传送和PHP程式碼设计等技術實現的細節。它只是尝试从用户的角度定义如何讓此功能可以起作用的必要條件:

  1. 创建和维护那些模板和模块的人們。
  2. 创建和编辑那些包含模板和模块的页面的人們。这包括所有的编辑者和各种页面:
    • 所有级别的经验:从那些对模板完全陌生的新手到那些已编辑过数千次的老手
    • 所有種類的编辑工具:维基语法编辑、可视化编辑器、内容翻译器、及其它(包括机器人的操作者)
    • 所有的维基:维基百科、维基词典、维基导游、维基数据、孵化场等等,以及任何未来的新计划
    • 所有的语言:英语、法语、俄语、西班牙语、亚美尼亚语、波斯语、祖鲁语、马尼普里语等。
    • 所有種類的页面:维基百科条目、条目的讨论页面、用户的讨论页面、社群的讨论页面、维基專題的页面、分类、模板文档的页面等。 {{🌎🌍🌏}}

电梯短講

有一大部份的維基媒體網站功能都是靠模板和Lua模組中實現的。在目前的形式下,它們無法在不同的維基和語言間共用。因此,它們很難與現代的文章的創建和編輯方式整合,例如可视化编辑器、維基數據、和內容翻譯。它們也很難適應行動裝置。這浪費了貢獻者的辛勞、對新的編輯者和小型專案造成困難。我們必須讓跨維基網站上共用的這件事,化不可能為可能,就像是在共享資源上的圖片一樣。這將使軟體開發更快、更穩健,也能讓編輯者更專注在寫作上。 {{🌎🌍🌏}}

難題

一般注释:除非另有说明,否则所有对“模板”的引用也适用于Scribunto Lua模块。

模板實現了維基媒體網站的功能。其中一些功能非常突出,尤其是信息框、參考文獻、“來源請求”等等。有關使用模板實現的更全面的功能列表,請參閱分類 。所有讀者都會看到它們、所有編輯者幾乎在每次的編輯操作中都會遇到它們。此外,它們還實現了許多網站的內部社群管理功能:刪除請求、解鎖請求、在討論中表達支持、為維基專題整理文章等等。

模板提供了一种有效的机制,可以在许多页面中快速设计、部署、和使用重复的文本和标记。然而,对于所有类型的编辑者來說,模板也存在一些严重的可用性问题。

在所有维基中所有编辑者的困难

维基语法编辑者

對於編輯者來說,wiki語法的模板通常是很難理解的。有使用特定模板經驗的人很可能會識別出它、然後能夠編輯有包含它的頁面。然而,不熟悉此模板的編輯者在遇到此模板時,即使對編輯和其他模板有一般的經驗,也不得不查閱其說明文件。而經驗較少的編輯,則會被帶有大括弧、管道符號、等號等等鬼畫符的文字搞得暈頭轉向。

要使用以模板形式实现的功能,需要知道模板的名称并以大括号({{}})键入或从另一个页面复制它。对于新手用户而言,这并不明显,老手用户也必须分别学习每个新模板。

某些维基上有一些小工具,这些小工具添加了一些按钮,这些按钮可将该项目中常见的模板插入到编辑工具栏中。尽管许多模板在项目和语言之间具有相似的功能,但每个维基中的这些都不同。

可视化编辑器的用户

可視化編輯器使用者在使用模板時具有一些優勢,但同時也存在許多問題。特別是,存在類似的易尋性:在可視化編輯器中,所有模板的功能都隱藏在“插入 → 模板”菜单的项後面,使用者必須事先知道模板名稱才能使用。

可視化編輯器的“插入”菜单包含有數學公式、埃及象形文字、樂譜、以及一些作為擴充功能實現的其他功能,但不包含“信息框”、“來源請求”、“單位轉換”、“引文”等項目。所有的模板都是同一類的通用項目。

有一個明顯的例外: 有些維基有「引用」按鈕,它可插入附帶有參考模板的腳註。然而,這是一個證明規則的例外。它甚至需要手動設定組態才能實現基本功能,這種組態設定在每個維基中都是獨立的,因此許多維基根本沒有這個按鈕。另一個可比較的例外是在2019年底新增的,對「來源請求」模板的特殊支援,但這也需要在每個 wiki 上進行一些自訂的組態設定才能實際運作。

编写多个项目的编辑者的困难

多個模板存在於一個專案之中,但不存在於其他專案之中,而且常常是某個模板是可用,但卻以不同的形式存在。有鑑於此,很難或無法重複使用那些已從某個專案中獲得的技能:模板所提供的功能有時不可用,有時工作的方式不同。這樣的情形不僅是套用到不同語言的維基、也同樣套用到同一語言中的不同維基,例如英語的維基百科和英語的維基文庫。

對於使用不同語言進行編輯的人來說,模板會讓翻譯更困難。在翻譯頁面時,無論採用手動翻譯還是內容翻譯,模板都比條目的文本(「白話文」)更難處理。用戶通常需要跳過模板或在條目發佈後進行修正。這也導致了正在進行的翻譯被放棄,因為模板的翻譯看起來令人望而生畏。

内容翻译中最常被舉报的问题都与模板有关。

內容翻譯具有模板適應的功能,可自動完成部份的流程,但僅在兩種語言中均存在相應模板且模板的維護者已一絲不苟地映射所有參數的情況下才能使用。這必須針對每種語言的每個模板分別手動完成,並且在來源模板發生變化時持續維護。即使模板在各種語言中的功能在大部份的時間中皆相同,也仍然需要這樣做。

理想情況下,模板及其參數應幾乎完全自動轉移到翻譯頁面,以便翻譯人員能夠專注於撰寫白話文,因為撰寫白話文是最需要人類工作的領域。

模板可以從一個維基匯出到另一個維基,但一旦完成,該模板就會成為一個分支副本。它要么保持匯出時的狀態,要么繼續獨立開發,從而導致不相容。有時人們會繼續維護不同的副本,但這種做法並不穩健,且無法讓我們所擁有的數百個維基網站依樣畫葫蘆。

模板參數可以在不同的維基中具有相同的功能、但名稱不同。它們可以使用TemplateData別名進行改寫,但這是一個次優的解決方案:這不是TemplateData最初的用途,而且每一對的語言必須手動操作。

模板混合了算術邏輯、人類可讀的文本字符串、和編排格式化。因此,沒有一種保證可靠的方法可以像翻譯MediaWiki核心和擴充功能一樣翻譯模板的用戶界面字符串。

小型维基编辑者的困难

創建一個新的維基项目是透過安裝MediaWiki核心並啟用預設的擴充功能集。實際上,這並沒有創造出一個平等競爭的環境,因為許多大型維基的關鍵功能都是透過模板實現的:信息框、引用、維護頂註(例如{{Unreferenced}})等等。

软件开发人员的困难

對於開發MediaWiki核心、擴充功能、機器人、以及其他用於分析、生成或修改維基頁面內容的工具的開發人員來說,要構建那些依賴於在某個維基中存在特定模板的功能,是非常困難的。GrowthExperiments、頁面鑑別分類、內容翻譯、Wikibase的一些組件、以及許多其他擴充功能的開發者,要么在量產環境中進行測試(這是一個爛主意),要么將模板匯出到他們的本地維基或某個在線測試維基。

獲取基於模板的維基內容數據的研究人員必須為每個維基分別編寫分析代碼,有時他們最終只對一個維基進行分析。一個值得注意的例子是使用英語維基百科的維基專題模板來分析頁面主題和評估條目的質量。 {{🌎🌍🌏}}

假设

扩展對模板:相似与相異

本项目提案的主要假設之一是,模板和模組這二者與MediaWiki核心和擴充功能非常相似:它們都是軟體、而且實現了編輯者社群所需的功能。尤其是,由於模板通常是由編輯者自己開發的,因此顯而易見的是社群「真正」需要它們。它們之間的最大的區別在於開發、本地化和部署的方式不同。

模板和模組在某些關鍵屬性上與擴充功能應開始變得是相似的,這些屬性是模板和模組目前所缺乏的,同時又保有一些擴充功能所欠缺的良好屬性。(為了方便英語讀者理解,表中列出了英語維基百科中的模板示例。這些示例也可以來自任何其他維基和任何其他語言。)

属性 核心和扩展 模板 對此,該如何處理模板?
实施特殊的内容 是。

图像、数学、象形文字、乐谱、基本参考

是。

Chess diagram

└ 特殊類型的內容是易於插入到頁面中 是(使用工具栏)。 否(除非你学会了如何做)。 应该要改變。
└ 特殊類型的內容是易於適應移動設備 通常是。 有时。 应该要改變。
└ 特殊類型的內容是易於翻譯以作為條目的一部份 通常是。 否。 应该要改變。
實作頁面格式化的功能 是。

gallery, poem

是。

Image array, Columns, Quote, Navbox, Infobox

實作社群工作的流程 是。

防滥用过滤器、用户查核、移动

是。

Admincheck, Proposed deletion

應該易於被重覆使用,但非強制。
易於部署初始版本 否。 是。 应该保留。
易於佈署變更 否。 是。 应该保留。
易于本地化 是。 否。 应该要改變。
在多个wiki上实用 经常。 经常。
只在少数维基使用 有时。

Josa, TocTree

有时。

New Zealand English, Units attention

易於安裝和使用在多個維基上。 是。 否。 应该要改變。
易於在一个新创建、近期创建的维基上使用 是。 否。 应该要改變。

模板和模块开发技巧

本提案基於的另一組重要假設如下:

  • 開發模板和模組所需的技能並非易事。模板和模組都有許多含糊不清的功能。
  • 儘管許多網站最顯著的功能都是以模板和模組的形式實現的,但這些技能往往被忽視、低估、並視為理所當然。
  • 有數十人具備這些技能,且他們編輯許多的維基網站。他們通常專注於自己的主維基網站,很少與其他維基網站或使用其他語言的貢獻者交流。儘管底層技術在各地都是相同的,但並未形成一個與MediaWiki核心和擴充功能開發者全域社群相媲美的模板開發者全域社群。雖然在某些模板上存在跨維基協同運作的案例,但這些合作並不一致。
  • 還有許多維基網站沒有具備這些技能的編輯者。他們要麼從其他維基網站複製模板和模組,卻沒有完全了解其運作方式、也無法有效地本地化和維護它們,要麼根本就沒使用模板。

這種情況遠非理想。模板和模組開發者的技能需要得到更多認可。他們開發了真正需要的功能,並且融入了他們的編輯者的社群。在許多語言的維基中,模板開發者為結構化內容、數據呈現、和模組化設計了創新的功能。這些創新功能在許多維基中都可能派上用場,但目前尚無便捷的機制來實現這一目標。

當然,解決這些問題的方案不能光提出新的技術,而放棄模板維護者多年來積累的實踐經驗。因此,在開發模板和模組時,語法上的變更應盡可能少。需要變更的是它們在橫越維基網站的部署和傳播的方式,以及其中可供人類閱讀的字串的本地化(翻譯)的方式。 {{🌎🌍🌏}}

提议的解决方案:摘要

MediaWiki已经具有许多跨维基全域的功能:

必须能够将模板和模块存储在全域存储库中,并像扩展一样强大地本地化它们。

全域模板和模块将使所有维基的模板维护者能够更轻松地协作来开发模板的程式碼,从而为他们提供支持。

全域模板和模块将使翻译人员和本地化人员能够专注于仅翻译用户界面字符串(“消息”),而无需在程式碼中寻找字符串,并允许他们使用相同的技能和工具来翻译模板和MediaWiki扩展。

全域模板和模块将使所有维基中的内容编辑者能够编写和翻译使用这些模板的内容,而不必深入研究每个维基中的差异并重新学习不同的规则和技能。

开发模板和模块的语法以及一般的模板维护和部署周期不会改变,因此模板维护者多年来积累的所有技能将保持相关性。

所有维基都将能够使用全域模板,但不必强制这样做。社群将保持其覆盖任何全域功能、设计、工作流和数据的能力。

本地化模板将与本地化MediaWiki扩展一样方便。 {{🌎🌍🌏}}

提议的解决方案:详细要求

模板必须能夠具有语义性且适用全域

语义是指尤其是可视化编辑器和内容翻译器的其他软件组件,必须具有一种通用的方式来理解模板的存在和理解它提供有特定的功能,以便可以将模板作为信息框、参考来源、维护标记等插入页面中,而不仅仅是通用模板。目前,讓模板具有語義性最接近的東西是TemplateData,但它只描述了模板的參數。例如,它並不能幫助可視化編輯器在工具欄中添加“插入信息框”按鈕。

「全域」是指模板的程式碼必须在一个地方維護,然後在所有的维基中使用。

使模板具有语义性

模板未曾有過強健的語義化,也就是說,它們不容易被處理頁面的軟體所處理。

只有少數幾個模板被賦予了語義:

  • 各种引用的模板,可从可视化编辑器工具栏的“引用”按钮中使用。它們需要編寫大量獨立的程式碼來配置每個想要使用它們的維基上的Citoid。
  • “来源请求”于2019年末已在可视化编辑器上使用(T211243)。它还需要在每个Wiki上进行配置。例如:英语希伯来语斯洛文尼亚语。在撰写本文时,即使法语,西班牙语、以及大多数其他语言都尚未为此配置,即使它們已具有此类的模板。
  • Flow扩展中用于提及用户的模板,也同樣需要本地的配置。
  • 某些转储(dump)处理和研究工具可以解析英语维基百科的维基專題页面评级模板,该模板通常添加在讨论页面中。
  • GrowthExperiments擴充功能會根據條目中嵌入的模板,建議編輯者執行某些任務。模板名稱必須通過在每個維基中分別編寫JSON文件來手動配置。例如:捷克語越南語韓語阿拉伯語
  • 擴充功能頁面鑑別分類已配置為與英語維基百科的頂註模板(也稱為“標籤”)一起使用。

就頁面鑑別分類這個例子的情況下,擴充功能基本上將單個維基的模板硬編碼,因此如果不進行大幅改寫,則無法在其他維基中使用。如同像Flow的示例那樣,即使維基上的配置步驟很簡單,但仍然需要進行配置。對於維基媒體現有的900個維基以及未來將擁有的數千個維基而言,這不適合依樣畫葫蘆。

這些內容應預設為全域性,以便擴充功能、機器人、转储(dump)分析器等工具能在所有維基網站上至少是能立即使用基本的預設配置。

储存和传送

全域模板和模块可以存储在中央维基(元维基、维基共享资源或一个全新的维基)中,甚至可以是Gerrit 或其他存储库。

最好的解决方案可能是创建一个新的维基,将其存储起来,而不会与图像、一般社群讨论等混淆在一起。

使用Gerrit作为模板和模块程式碼的存储空间在技术上是可行的,但是它将失去模板维护者可访问性的重要元素:对于大多数模板维护者而言,在维基页面中编辑模板要比使用Git提交和等待程式碼审阅轻松得多。因此,Gerrit可能不应该成为存储模板和模块程式碼的一种方式,至少不是主要的一种。

全域模板和模块必须存储在可以由大多数维基编辑者编辑的公共存储库中。有关阻止和特殊权限的规则最初应与其他维基中的规则相似:默认情况下应打开所有内容,并且必须保护非常常见、敏感或经常被破坏的模板。编辑社群後續會制定有关保护级别的更详细规则。

中央存儲庫中的模板代碼將使用通用英文名稱的標籤(如 <section>)、解析函數(如 {{#ifexist}}{{#invoke}})以及魔術字(如 {{DISPLAYTITLE}})。

如何傳送模板至目標wiki是內部工程與架構的問題,只要其他的需求得到解決即可。一些平台開發者過去曾討論過這些問題,例如圍繞在影子命名空間專案的問題。本文檔嘗試解決那些編輯已使用模板的頁面的使用者或維護模板本身的使用者如何運作的相關問題--如何以可本地化的方式撰寫模板;如何讓模板可以被翻譯;如何讓模板可以本地自訂等。這些問題在之前有關此主題的架構討論中並沒有得到充分的解決。

模板必须保持易于修改

模板在当前工作方式的一个重要特征是,它们像维基页面一样被编辑,并且在发佈后无需審核或部署即可立即生效。这有点危险,因为不正确的编辑可能会破坏许多页面,但事实是,它大部分都能工作得很好。

這種便利性必須保留。維護模板的社群成員大部份都很可能會拒絕轉移到新的系統,因為新系統需要他們去學習新的技能,然後拖著每一個沈重的系統變更、穿越重重折磨人的審核與部署階段。這大概就是代表著將模板存放在Gerrit中是行不通的,除非、或許,審核和部署的流程可以比擴充功能「更」容易得多。

必须可以使某些模板非全域

并非所有模板都应强制为全域模板。

实际上,某些模板应该是本地的,因为它们实现了特定语言所独有的功能。从本质上讲,此类模板不需要翻译,应该有一种方法可以向人工编辑和翻译工具(例如“内容翻译”)提示它们不需要进行改寫,并且可以跳过或替换。这是使模板更具语义的工作的一部分。

必须有可能覆盖全域模板的某些功能或外观

任何社群都不应该感覺到有某些强大的外部参与者(例如英语维基百科社群、维基数据社群、WMF、或其他任何人)对其強加某個功能。全域模板应该是为了共同利益而开发并协作使用。在大多数情况下,它应该為每个人工作。

有時,某些社群會對擁有某個特定功能或設計有強烈意見,希望在他們的語言或專案中有所不同、或者希望顯示與其他專案不同的信息框或甚至是完全不顯示。從一開始就必須允許本地覆寫這些設定(或者更確切地說,不能取消這種功能)。

全域模板必须在每个维基立即可用

就像全域用戶頁面可以在每個沒有本地用戶頁面的維基中立即使用一樣,在全域的基礎設施上創建的每個模板或模塊都必須可以在每個維基中可以立即使用。

這絕不能需要「任何」額外的步驟,例如複製維基的頁面、創建本地名稱的封裝模板、管理員的干預、等待數小時以刷新緩存等。

在中央版本更新之後,更新的版本就會立即顯示在所有地方上。為防止破壞行為,編輯者社群將制定權限和保護級別的政策。

如果使用者介面的字串(也稱為「訊息」)未被翻譯,模板仍然是可以使用,且該字串將以備用語言顯示。請參閱本地化部分以了解詳情。

面向用户的字符串的本地化

必须可以翻译所有面向用户可见的字符串

MediaWiki核心、擴展功能、以及某些外部工具例如頁面預覽)用户界面字符串(消息)在translatewiki.net上可以方便地、可靠地翻譯。至少所有語言的某些編輯者都對這種本地化流程有所了解。

目前尚無法對模板進行同樣的操作。共享資源和 mediawiki.org 等多語言網站採用了“TNT”系統來翻譯某些模板,但該系統非常複雜,無法在維基百科、維基文庫等網站上重複使用。在2021年,歸功於“語言感知轉錄”,該功能得到了強化,但仍需進一步改進。

理想情況下,應該可以使用帶有「翻譯」擴充功能的維基,就像翻譯核心和擴充功能時一樣翻譯模板。

使用「翻譯」介面提交翻譯後,翻譯後的字串必須立即可使用。

可以直接在原始的維基頁面中編輯用戶介面字串,但理想情況下應主要通過專用翻譯介面進行編輯。

翻譯人員應該能夠專注於翻譯文本。如果周圍有任何代碼,對於沒有編程和 JSON 文件經驗的人來說,就很難輕鬆地進行貢獻。此外,在原始文本文件中編輯從右到左書寫的語言的翻譯非常不方便。「翻譯」擴充功能已經解決了所有這些問題。

模板文檔頁面也必須是可翻譯的。使用Translate擴充功能的頁面翻譯功能來做,大多數都已足夠,但可能需要做一些改寫。

向用戶顯示字串的語言

模板主要是用在整合進內容之中,因此預設情況下,翻譯的訊息必須是以wiki內容的語言來顯示。

然而,有些模板被使用作為UI的元素。因此,當用戶的語言與維基內容的語言不同時,或許允許以用戶的語言來顯示翻譯的字串也是合理的。這對於共享資源、維基數據、元維基、和mediawiki.org等多語言網站來說尤其重要。

當MediaWiki沒有翻譯可用時,就必須使用常用的備用語言鏈。例如,如果一則訊息沒有翻譯成蓋楚瓦語或瓜拉尼語,它就會以西班牙文顯示;如果沒有翻譯成巴什基爾語或楚瓦什語,它就會以俄文顯示,以此類推。英文是最終的後備語言,所以如果這則訊息未翻譯成西班牙文或俄文,就會用英文顯示。

消息键

訊息應該以鍵來表示,類似於MediaWiki核心、擴充功能和工具中的做法。

撰寫可翻譯的字串可能就是模板維護者在模板開發過程中必須去習慣的最大改變。寫死的字串將必須被分開、並移到按照鍵字所組織出來的訊息之中。這不僅是對翻譯者需儘可能簡便、對模板維護者也是一樣。否則,他們就不會實際上去做,而這個功能也會實質上被拒絕。

為了要輕鬆地使各個鍵都具有全域唯一性,在訊息鍵中自動包含全域模板的名稱應該是沒問題的。

翻译的工具

某個工具應該被開發,其可以協助模板或模組轉換到中央儲存。它可以執行下列步驟:

  1. 從本地wiki匯出某個模板、然後將其匯入全域的wiki。
  2. 匯出此模板所使用到的所有模板(級聯)。
  3. 識別出人類可讀取的字串,將其轉換為具有鍵字的清單、然後以模板原始碼中的鍵字取而代之。
  4. 匯入模板的說明文件頁面和TemplateData。
  5. 导入需要的CSS页面。

在大多數情況下,這個自動流程可能無法建立一個完全可用且強健的模板或模組,但它有助於啟動轉換的流程。

組織出消息

Translate擴充功能是以群組(也稱為「專案」)來組織訊息,而群組又可以進一步被集合群組所組織。例如,Article Placeholder、Score和Poem都是代表相應MediaWiki擴充功能的群組,它們都包含在「維基媒體所使用的擴充功能--進階」的集合群組中,還有許多其他的擴充功能也在一起。

象徵MediaWiki擴充功能的各個專案是以YAML檔案配置在translatewiki的儲存庫之中、且顯示在Translate專案選擇器的使用者介面之內,也稱為「訊息群組選擇器」。

由於模板的數量比擴充功能多很多,因此可能需要對Translate擴充功能處理訊息群組的方式進行一些修改,以適應模板的翻譯。

每個模板都應該是一個訊息群組。彼此關係密切的模板們應歸類為一個集合式訊息群組。它們可以類似於它們被儲存所在的類別的樣子,事實上,類別甚至可以被重複使用。編輯Git儲存庫裏的檔案來組織這些訊息群組應非良方,因為這過於错综复杂且曠日廢時。

如果能在選擇器中顯示群組和模板的本地化名稱就更好了,但若以英文顯示亦可。如果這已可以讓擴充功能的本地化人員滿意的話,那這也一定會讓模板的本地化人員滿意。

在Translate擴充功能的特殊頁面語言統計(Special:LanguageStats)上,模板必須顯示為訊息群組。這將有助於本地化人員找到哪些模板需要翻譯。這應該與所有的訊息群組雷同,但模板其特殊的考量:

  • 將會有成千上萬的模板,所以如果表格的設計以某種方式與此一致,這豈不是太好了。
  • 該表格應顯示每個模板轉錄在多少的頁面上,並可根據此數字排序,以幫助本地化人員優先翻譯更重要的內容。

找出如何翻譯模板

每個模板的描述頁面都需要有一個直接的連結,將其翻譯成使用者的語言。

有些模板使用維基數據標籤作為其UI的一部分、而不是寫死字符串。目前在共享資源上的維基數據資訊框、加泰隆尼亞維基百科中的Infotaula persona(人物資訊框)、以及其他幾個模板中都是這樣做的。這些標籤和值可以在維基數據中進行本地化。這種用法無法涵蓋模板本地化的所有需求,但對於特定目的而言,它是正當且有用的。只要在模板文件中加以適當說明,就可以繼續使用,而且可能不需要特別的基礎架構調整。(也許可以將相關的標籤和值的翻譯以某種方式整合到Translate介面中,以進行模板的本地化,但這是可選的)。

訊息參數與魔法字

在MediaWiki核心和擴充功能中,許多訊息都有參數,有時也稱為「占位符」。它們被命名為 $1, $2, 等等,並在執行時被填入。由於不同的語言有不同的字順,因此參數對於使訊息具有強韌的可翻譯性特別重要。

模板中也需要類似這樣的東西,儘管有可能在形式上不必然非$1, $2不可, 而是帶有三個大括弧 ({{{}}})的類似模板式的參數。這將根據解析和本地化便利性的考量來決定。

模板中的訊息必須像MediaWiki的訊息一樣,支援PLURAL、GENDER、和GRAMMAR這些魔法字。

訊息文档

在MediaWiki核心和擴充功能中,每條可翻譯的訊息都有文檔記錄,以方便開發人員和翻譯人員。該文件可能包括訊息出現的位置、$1、$2等參數是什麼、單詞是動詞還是形容詞等資訊。此文檔以偽語言代碼qqq儲存。

這樣的文檔對模板翻譯也會很有用。如何儲存它是技術架構的問題。也許它可以與TemplateData結合、也許它可以儲存為某個qqq語言、也許它可以是其他東西。

來源的语言

模板不僅會從英文專案匯入全域儲存空間、也會從許多語言的wiki匯入。本地化的工具比以往任何時候都更需要支援任何語言的翻譯,而不只是英文。

模糊化

在MediaWiki核心和擴充功能以及可翻譯的頁面中,如果英文的來源訊息發生變化,該訊息會自動被標記為過時的或 「模糊的」。既有的翻譯仍然有效、但會對翻譯人員顯示需要更新。(翻譯管理員也可以將某個訊息標示為不需要模糊化)。

模板的本地化也會需要類似的機制。然而,由於最好不要硬性要求英文為來源語言,因此應該有更多方法將訊息標示為模糊語言。

模組的本地化考量

Lua模組可以載入與解析可翻譯的MediaWiki字串,但對於做為wiki頁面來維護的Lua模組而言,並沒有明确界定的方式來儲存這些字串。有可能將那些Lua模組包裝成擴充功能的一部份,這樣它們就能夠從擴充功能的i18/*.json檔案載入訊息,但目前只有極少數的擴充功能有做到。從工程的觀點來看,用Lua重寫模板應該是一個較穩健的解決方案,但現有的模板維護者不一定會全然接受Lua,而他們的合作對於專案的成功與否至關重要,因此無法對所有的模板都這麼做。

某些非常內部的、技術性的模組,因其常用、鮮少改變、不需要國際化,本身大概可以無痛地移入Scribunto擴充功能。禁止全域變數參數就是這些例子。

本地化模板名稱

雖然模板可能在每種語言中有不同的名稱,但是它必須直接鏈接至中央儲存空間。

全域模板和模組應該可以在所有維基中立即可用,而不需要任何額外的步驟,因此必須可以在本地維基頁面中使用全域名稱來嵌入全域模板。跨維基編輯者的社群將決定這些全域名稱的政策。

類似於參數的名稱,模板在不同的語言中可能有不同的名稱,這一點必須保留。必須有一種結構化的方式來翻譯模板名稱。也許維基數據的網站連結可以發揮作用,但未必一定是。

如果不這樣做,編輯者要嘛避開使用全域模板、要嘛將全域模板包裝在具有翻譯名稱的本地模板中,這樣很可能會導致模板失去與全域實體的連接。這並不可取、也忽略了專案的整個重點。

模板名稱必須翻譯成可以成為維基內容語言的語言。翻譯成正式德語或英式英語可能是不必要的。可能有別名或重定向的方法。語言的變體,例如塞爾維亞語和中文,必須根據這些語言的需求來支援。

如果本地模板存在於某個維基中,並且與全域模板的本地化名稱相同,則會被使用的是本地模板。這與共享資源上具有相同名稱的本地檔案覆蓋全域檔案、以及MediaWiki空間中的本地訊息覆蓋來自代碼的本地化相似。

Lua模組的名稱通常也會本地化。它們的名稱可以本地化,以便從wiki頁面直接調用,但由於程式碼通常使用類似英文的識別碼,因此內部的全域名稱可能更適合在程式碼本身使用,例如在 require 語句中。

本地化参数

本地化参数名称

每種語言的參數名稱都不同。它們通常是基於每種語言中的單詞,因此能方便地在wiki語法中編輯嵌入包含是很重要的。

理想的情況是,全域模板應該有通用的內部參數名稱,這些名稱有不同語言的翻譯。這有些類似維基數據的屬性名標籤,但可以更簡單:由於英文是軟體開發者的「通用語」,而模板也是軟體的一種,所以以英文為預設來源語言,而不是像維基數據中的通用數字,大概也沒問題。

這些通用的參數名稱將成為常用的預設名稱。它們會在所有語言的wiki中運作。本地化名稱將只在以該語言為內容語言的 wiki中運作。

這些參數名稱的翻譯必須經過驗證才能生效:

  • 不得包含無效字元
  • 不得在同一語言的同一模板中重複出現
  • 還有其他的嗎?

翻譯參數名稱的實際過程可能與翻譯使用者介面字串不同。這些名稱有技術上的限制,必須被強制堅持。它們也必須保持穩定,因為變更參數名稱會破壞現有的嵌入包含,所以應該有一些防範措施,避免變更太頻繁。

自動參數翻譯

如果所有的本地化模板和參數名稱都集中儲存,就可以有一個簡單的服務,取得一個帶有參數的有效模板呼叫、一個來源語言名稱、和一個目標語言名稱,並輸出一個本地化的模板呼叫。舉例來說:

输入:

{
	sourcewiki: "enwiki",
	targetwiki: "frwiki",
	template: "{{Infobox writer|name=Ľudovít Štúr|birth_date=1815-10-28}}"
}

输出:

{
	template: "{{Infobox Écrivain|nom=Ľudovít Štúr|date de naissance=1815-10-28}}"
}

在內容翻譯中,這將會是改寫模板的主要方式。與目前內容翻譯中的模板改寫不同,這將是精確和完整的,而不是基於猜測。

在可視化編輯和2017風格的wiki語法編輯中,只需從其他語言的wiki中複製並貼上模板,就能自動完成參數翻譯。

對於普通的wiki語法編輯,應該有一個簡單的方法來操作這個服務,例如一個特殊的頁面或對話框,編輯者可以貼上模板和來源語言,然後就得到帶有翻譯參數的模板。

在這兩種情況下,僅會翻譯模板和參數的名稱。參數值的翻譯將另行討論。

无名参数

無名的已編號參數必須要繼續工作,這是無庸置疑的。

需要決定如何將其名稱本地化。

翻譯參數值

除了使模板的功能和設計共用外,還必須考慮使模板參數值的共用、以及「不」共用。

有些參數值,緣自其本質而在所有的語言中都是相同的。例子有:某個當地地名(例如海牙的[dɛnˈɦaːx]發音)的國際音標發音、城市的建城年份、化合物的化學式等。至少這些資料中有一部份應該是有儲存在維基數據中,並且可以輕易地載入到模板之中。

某些參數值必須翻譯或音譯,例如人名、國家格言的翻譯等。

全域模板必須讓這一點成為可能,但實際上,這些事物還是經常會複製到不同的維基上,這一點也必須考慮到。

某些參數值可以被確實且可預測地自動轉換,而全域模板的基礎架構必須支援這一點。例如,數字的格式和數字的字符在緬甸語、印度語和某些其他語言中常常是不同的,但可以使用簡單的軟體而被可靠地轉換。

合法的且具功能性的參數值必須可用於多種語言、且不得是某個語言特有。例如,拿「yes」和「no」作為布林值就太以英文為中心了。這應該不至於需要去變更基礎架構,而主要是需要在跨維基模板開發社群中就適應所有語言的良好作法達成一致。

文字方向

模板必须讓适应在它们自身中所顯示的维基文本的方向(左到右/右到左)。

必須便於編寫與文字方向無關的模板,盡可能少使用明確的右對齊和左對齊。

机器人

機器人會常態性地去編輯wiki中的許許多多模板。此能力必須能被保留下來。

這應該不需要在軟體基礎架構中做任何變更,但為完整起見而在此提及,此乃因為這是一個重要的使用個案。

將模板從大型wiki轉移到中央儲存庫

到目前為止,內容翻譯中最受歡迎的來源語言是英文。之後是西班牙文、俄文、法文、德文、嘉泰羅尼亞文、烏克蘭文、義大利文、中文、和葡萄牙文。正因為如此,維基百科中這些最常見語言版本的共用模板,尤其是英文版的模板,是最有必要使其全域化,以利於所有其他語言的使用,這也是合情合理的。

然而,有點自相矛盾的是,這些最大語言的編輯者也是最沒有興趣想要讓這些模板成為全域的:

  • 對他們來說這些模板已經很好用了,而且那邊的大多數人並不會直接在乎它翻譯成其他語言是否便利。
  • 重新編寫模板以便讓各個字串都可供翻譯,這可能曠日持久,而且可迫使他們學習新的模板維護技巧。
  • 突然讓更多專案使用這些模板可能會讓日後在修改模板的運作方式上更難達成共識。
  • 那些來自不同主要維基的編輯者們,在這個合併某些已存在他們網站上的具有類似功能的模板議題上,必須努力達成共識。

但在做技術性架構的決策時,與其說是工程上的考量,不如說是實用性與社群關係的考量,這是必須考慮到的。如果不在這方面做好適當的準備,整個專案就會失敗。

只要有某些重要的共用模板不是全域的,以任何方式處理來自不同維基的模板的內容翻譯或其他軟體,就必須持續支援這些模板。如果建立了全域模板的基礎架構、且現有模板遷移的步伐良好,開發人員可能就會考慮停止開發、然後在將來的某一天將適應非全域模板的程式碼廢棄。

將模板從大型wiki遷移到中央儲存庫的步伐,可視為是該專案的成功指標之一。

必須能在wiki語法和可視化編輯器中完全使用模板

雖這是顯而易見但仍不免提一下:Wiki語法的編輯難以在短期內就消失,而且必須能繼續像現在這樣編輯頁面中的模板嵌入。這件事絕對不能越弄越複雜。

然而,可視化編輯器越來越受到有經驗編輯者和新進編輯者的歡迎,因此每個模板工作的功能都必須在可視化編輯器中和維基語法的編輯中良好運作。

其他與模板相關的功能

在MediaWiki核心及其擴充功能中會有一些處理模板的功能。所有這些功能都必須能繼續運作,而且可能會需要為全域模板時代進行更新。

MediaWiki核心

應該要有一些維基上的工具,其至少可以顯示在頁面上使用的模板和模組的基本分析:按維基分類的嵌入和引用數量、以及使用模板和模組的頁面清單。在頁面被編輯時,這個可顯示出頁面嵌入了哪些模板的功能必須繼續使用全域模板。

“链入页面”頁面必須繼續運作,並對全域嵌入維持有用。

TemplateData

  • TemplateData中的模板和參數說明是可以翻譯的,翻譯結果會以使用者介面的語言顯示在可視化編輯器的模板插入對話框中。這很棒且必須保留下來。翻譯介面可能還能再改進,但其起因是好的。在翻譯的擴充功能中加入對TemplateData的支援是一個解決辦法,但也可能有其他的解決方法。
  • “推荐的wikitext格式”參數(行内、代码块、自定义)必須持續運作。也必須能夠依維基自訂它們--有些維基可能喜歡看到某個模板以維基語法寫成一行,有些則喜歡寫成多行。

Citoid

  • Citoid必須在每個維基上使用JSON文件(例如 Citoid-template-type-map.json)分別配置。在全域模板的時代,必須讓共享這些文件成為可能,以便讓“引用”按鈕在所有維基上都可用,並且“默認”在所有地方都以相同的方式工作。與模板類似,必須有一種方法可以在每個維基中覆蓋此預設值,以便社群需要不同的行為。

模板樣式

  • 必須有可能在與模板相同的中央儲存庫中寫入模板的樣式頁面。中央樣式必須預設是載入,而且必須可以在本機覆寫。

TemplateSandbox

  • 模板Sandbox必須保持運作。
  • 它必須能夠編輯中央資源庫中的模板、並能在目標維基的頁面中預覽。


TemplateWizard

  • 目前的系統是使用wiki的標準搜尋來尋找模板。搜尋結果會以清單的方式呈現,可能需要修改才能讓全域或本地的狀態顯現。
  • TemplateWizard可從TemplateData API取得模板的資訊,因此只要該API一直傳回相同的結構,應該就不會有任何問題,而且i18n已經在運作了。

Wikibase

  • 維基數據可以用來把一些參數值從一個中央資料庫帶到維基上。這在維基百科的多種語言中得到了有效運用,其中包括法語、希伯來語、巴斯克語、俄語、嘉泰羅尼亞語、愛沙尼亞語、和其他一些語言,在共享資源中也是如此,儘管實際的執行方式可能有所不同。這當然必須繼續運作。統一不同維基的方式,可能會成為這個專案最重要的影響領域之一。
  • 這也可能讓维基数据橋接器 的實作更容易,也就是允許在wiki內編輯模板值的專案。對模板本身的修改只需要在全域模板中進行一次,而不需要在每個wiki中進行。

可视化编辑器

  • 可视化编辑器很顯然地必需要能夠插入全域和本地的模板。
  • 可视化编辑器會在模板編輯對話框中顯示模板描述頁的連結。使用時,此連結應直接指向全域模板。

开发和部署

開發全域模板和模組的基礎架構是一項大且複雜的專案。它必須分割成數個可管理的部份才能完成。粗略來說,這個專案的多個部份應該依下列順序開發:

  1. 可翻譯模組 (開發中):在使得模組可以跨維基共享之前,應該先開發國際化和本地化的框架。這對已經多國語言的維基上的模組會立即有用,最顯著的是共享資源和維基數據。其中有些是使用Lua陣列或可翻譯頁面的技巧來翻譯的,但這並不是一個完整的本地化系統。
  2. 全域模組:模組可以在不同的維基共享。這應該發生在模板可共享之前,因為模組的基礎架構與核心MediaWiki的耦合程度較低。
  3. 可翻譯模板:這與上面的可翻譯模組類似,可以重複使用許多相同的框架,但它也需要翻譯模板本身及其參數名稱、以及其他一些功能的能力。請參閱規格中關於本地化的部分。
  4. 全域模板:將模板全域化,完成專案。

開發更先進的功能,例如讓模板語意化,可以也應該稍後才進行,也就是在可分享之後。如果它們在可分享之前就變成有語意性的,那麼用語意描述它們的程式碼就會在不同的 wiki 上分叉,就像模板本身一樣,這會讓程式碼重複使用比現在更困難。

Access to global templates and modules will be available from all the Wikimedia wikis. This includes editions of Wikipedia, Wiktionary, Wikivoyage, etc. in all the languages, as well as Commons, Wikidata, Meta, mediawiki.org, Wikitech, etc., as well as test wikis (test.wikipedia.org, etc.) This is similar to how images on Commons are available on all the wikis. Even though the global templates and modules will be available to the wikis, the wikis won’t be obliged to use them.

Making templates easily reusable on non-Wikimedia projects may also be desirable. 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-Wikimedia websites.

{{🌎🌍🌏}}

想象這樣一個世界

想像一下,在這個世界上,每個人都可以自由分享所有知識的總和,而且這其實是一件非常容易的事情,因為模板是全域的:

任务 使用目前的模板系統 使用全域模板
使用可視化編輯器插入一個信息欄
  1. 转到“Insert”。
  2. 转到“Template”。
  3. Find the template name somehow.
  4. 输入模板名称。
  5. 填写字段。

Note that you will have to find the template name for each wiki separately, and in some wikis it will not work at all.

  1. 转到“Insert”。
  2. 转到“Infobox”。
  3. Select the infobox type you want.
  4. Get most or all of the fields filled automatically from Wikidata, and add anything that is missing or that has to be overridden.

Note that the above will work the same way in every wiki and in every language, unless specifically overridden.

Insert an infobox using the wiki syntax editor
  1. Totally manual: Find the template description page and type the template into the wiki syntax editor according to the instructions.
  2. Mostly manual: Copy from a similar article and change the parameter values.
  3. Use TemplateWizard (hoping that it is configured for your wiki):
    1. Click the puzzle piece button.
    2. Find the template name somehow.
    3. 输入模板名称。
    4. Fill the parameters one by one using the form.
If you want, you can still do all the same things as with the current template system.

But you will also have these additional optional features:

  1. To select a suggested infobox from a list instead of typing the name manually.
  2. To have the parameter values auto-filled.
  3. To have the same process for every wiki.
Use a nice template that you saw in a wiki in English, French, Russian, or Spanish in the wiki in your language
  1. If you have time and necessary skills:
    1. Copy the code of this template to your wiki. If this is a complex template, you will have to use exporting and importing.
    2. Copy the underlying modules, if necessary.
    3. Copy the TemplateStyles, if necessary.
    4. Copy the documentation and translate it in the wiki syntax editor.
    5. Go through all the wiki syntax you copied, find all the human-readable user interface strings that have to be translated, and translate them.
    6. Go through all the wiki syntax you copied, find all the parameter names and where they are used, and change them to your language.
    7. Check that the template actually works and does what you need. If it does not, you may have to search for CSS or JS pages on which it depends.
  2. If you don’t have time or necessary skills, you have two options:
    1. Make a simpler template with fewer features.
    2. 放弃。
  3. 重复每种语言和维基的过程。
If the template is in the global repository, then:
  1. 转到模板文档页面。
  2. Click the button “Translate”, and translate all the messages using a translatewiki-like interface.

That’s it, the template is fully usable in your language.

(And yes, this also has to be repeated for every language, but the same is true for MediaWiki extensions.)

Use the new features of a nice template that you once exported into your language from a wiki in English, French, Russian, or another language 三种选择:
  1. Repeat the process for exporting the template, hoping not to break anything along the way.
  2. 自己開發。
  3. 放棄而繼續使用舊版本。
Just translate the new strings. All the new features are already available in all wikis.
Implement 维基数据橋接器 (editing Wikidata’s data directly from infoboxes) This is a project in a very early stage of design. However, it can probably be said already that with the current technology, implementing it will probably require changing every infobox template in every wiki according to instructions that will be published by Wikidata developers. The infoboxes’ template code will only have to be changed once, and it will work for all the wikis.
Translate an article from English, French, or Russian into your language using Content Translation
  1. Open the article in Content Translation.
  2. Click the Infobox.
    1. If someone imported the infobox template into your language, fill all the parameters. (They are occasionally pre-filled, but most of the time they are not.)
    2. If no-one imported the infobox into your language, skip it.
  3. Translate the prose of the first paragraph.
  4. Carefully check that all of these templates were correctly adapted:
    1. IPA发音模板
    2. 母语名称模板
    3. 需要引用
    4. 单位换算
    5. Blockquote
    6. 国旗
    7. Various others
  5. Repeat steps 3 and 4 until everything you want is translated.
  6. 发布文章。
  7. Clean up incorrectly published wiki syntax.

In this scenario, steps 4 and 7 may take more time than step 3.

  1. Open the article in Content Translation.
  2. Click the Infobox. The Infobox is adapted and all the parameter values are pre-filled automatically. Correct their values if needed.
  3. Translate the prose of the first paragraph.
  4. All the templates are automatically adapted with correct parameters, but check that they are correct, just in case.
  5. Repeat steps 3 and 4 until everything you want is translated.
  6. 发布文章。
  7. (Cleaning up incorrectly published wiki syntax is probably not needed.)

In this scenario, step 3 takes most of the time, steps 4 and 7 are very short, and the total time is shorter.

Copy a useful citation of an academic article from the Danish Wikipedia to the German Wikipedia (or between any other two languages)
  1. Check that a corresponding template exists in the target language. If it does:
    1. Check that the template in the target language has the same parameters with the same names. If it does, you’re lucky! Just copy and paste. You can stop here.
    2. If they do not have the same names, check what are the corresponding parameter names in the target language and copy them one by one.
  2. If the wiki in the target language doesn’t have this citation template, you have the following options:
    1. Create it (as in the scenario called “Use a nice template that you saw in a wiki in English, French, Russian, or Spanish in the wiki in your language”).
    2. Find a similar citation template and use it.
    3. Just copy the text of the citation without formatting and structure.
    4. Give up and publish the article without the reference.
In Visual Editor: Copy and paste without having to wonder whether it will work

In the wiki syntax editor:

  1. 复制。
  2. Paste to template parameter conversion tool. It automatically changes parameter names between languages.
  3. 粘贴结果。

(In the 2017 wiki syntax editor, the template conversion tool can probably be integrated into the pasting action.)

Have a table of the latest results of the ongoing Tour de France in the Wikipedia your language

This scenario is based on an actual module, Cycling race. It is not used in the English Wikipedia because of disagreements about the design of the tables, but the community appears to be open about adopting it in the future if necessary changes are made.

  1. Once: Develop a template and a module that build a table of results, and document how to copy it and translate them.
  2. In every language (optional): Translate the user interface strings of the module by editing the Lua code.
  3. In every language (optional): Translate the labels of the necessary Wikidata items.
  4. In every wiki: Copy the module from the central storage to your wiki.
  5. In every wiki, repeatedly: Update the module in your wiki every time the central module is changed.
  6. In every wiki: Create an article about this year’s event and add the template that invokes the module to this article.
  7. Once: Wait for the results to come in, and add them to the relevant Wikidata item. Articles in all the languages get them automatically.
  1. Once: Develop a template and a module that build a table of results. The template becomes available everywhere.
  2. In every language (optional): Click the button “Translate”, and translate all the messages using a translatewiki-like interface (not by editing Lua code or wiki syntax).
  3. In every language (optional): Translate the labels of the necessary Wikidata items.
  4. In every wiki: Create an article about this year’s event and add the template that invokes the module to this article.
    • In the further future, even this step may become optional thanks to an extension such as ArticlePlaceholder, which may be able to auto-create start-level articles of this kind.
  5. Once: Wait for the results to come in, and add them to the relevant Wikidata item. Articles in all the languages get them automatically.

Practically all the languages get the whole table for free, without doing anything. All the work is done by the people who create the templates and the modules, once for everybody, and by the people who follow the events and update the results. A cross-wiki platform for developing and localizing the module and the template may facilitate the development of a design that is acceptable in all languages.

Start writing in a new wiki after the domain is created After the content is imported from Incubator, there are no templates for infoboxes, references, userboxes, discussion management, marking pages for merging or deletion, etc.

Start copying these templates one by one, or create your own.

Nice people from other wikis may help you, but they probably do not know your language, so you will have to manually translate all the strings (as in the scenario called “Use a nice template that you saw in a wiki in English, French, Russian, or Spanish in the wiki in your language”).

You can also just give up and only write text, but then you will get fewer features: no infoboxes, no formatted citations, no deletion and merging workflows, etc.

All those templates are already available. Just translate the strings in a translatewiki-like interface.
Use a navigation box while reading an article on a mobile phone 不可能。

Navigation boxes are so difficult to adapt to mobile screens, and so different from each other across wikis, that the software just hides them. (And yes, there is demand for it.)

可能。

Since the templates’ infrastructure is shared across languages, the different language communities can work with each other and with the developers of the mobile reading and editing interface and make them responsive.

Have a beautifully designed and mobile-friendly main page with regularly updating news, featured articles and images, etc. Option 1: Find volunteers who know your language, as well as HTML and wiki syntax (especially tables and templates) very well and who have time to edit the main page every day. This is done separately and using different methods in every wiki. This happens in the top 70 wikis or so: English, Russian, French, Spanish, etc.

Option 2: If you can’t find anyone who knows your language and can also maintain the HTML code of the main page every day, copy the code from the main page from English or French and ask volunteers from other wikis, who don’t know your language, but know wiki syntax, to replace the picture of the day occasionally. Since they don’t know the language, they cannot maintain the text regularly, and you cannot do it because you are afraid of breaking the HTML code, so you get stuck with the same featured article on the main page for months or years. This happens in some of the smaller languages.

Option 3: Give up and have a static main page, which most likely doesn’t work well on mobile devices, even though the main page is usually the top viewed page in a wiki. This happens in a lot of wikis, even if there’s other editing activity.

Option 1: If you have people with the needed skills and time to maintain a manually crafted custom main page in your language, and you want to keep things that way, you can do it.

Option 2: If you don’t have the people who can do this manual work or if your community is fine with having a main page that looks similar to the one in other languages, put a simple centrally maintained template on your main page. Replace only the text of the changing items in an easy form, without having to deal with wiki syntax, tables, or HTML. The process is the same for most wikis, so the same templates and bots can be used by everyone who is interested.

Analyze how articles are sorted by WikiProjects for a research about Wikipedia
  1. Write code that parses English Wikipedia’s WikiProject sorting templates on talk pages and run it.
  2. Discover that you cannot run the same code on other languages. At this point, you have two options:
    1. 重写每个维基的程式碼。
    2. Give up, and research only the English Wikipedia.
  1. Write code that parses WikiProject sorting templates on talk pages and run it in all languages.

(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.)

{{🌎🌍🌏}}

状态

This section is about the general status of the project. For details about the latest developments, as well as a brief history of past efforts, see the page Global templates/Status.

As noted above, as of December 2020, this page is only a big idea, and not a commitment to implement a project.

Similar ideas were suggested in the past. The oldest known suggestion to make templates reusable across wikis was raised in December 2004 in Bugzilla: Interwiki templates (T3126). Several other similar ideas were raised later, for example Phabricator T6547. In February 2017 a similar proposal called Global-Wiki was closed as “consensus”. Some of its components were implemented, such as global preferences, but not the templates.

The wish “Central global repository for templates, gadgets and Lua modules” was voted #3 at the Community Wishlist Survey 2015 and “Global gadgets” was voted #1 in Community Wishlist Survey 2016. Despite the community support, neither was implemented, because they weren’t appropriate for the Community Tech team, and they weren’t transferred to another team either.

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.

Abstract Wikipedia, which was approved by the WMF in July 2020 as a new project to be developed in the near future, includes “a cross-wiki repository to share templates and modules between the WMF projects” inside its Wikifunctions component as one of its major goals (Wikifunctions was previously known as “Wikilambda”).

The Translatable modules initiative was launched in September 2020. It addresses a part of this proposal.

In Community Wishlist Survey 2021, the wish titled “Templates translation” received the highest number of votes. It was also the wish with the highest number of votes in the history of the survey to date (December 2020). This wish closely corresponds with some parts of this proposal, especially Automatic parameter translation.

For other examples of the relationship between this Global templates proposal and various strategic plans in the wider Wikimedia community, see the page Global templates/Relationship to strategy .

There is no complete technical plan for implementing full-featured cross-wiki sharing of modules and templates. This page is an attempt to propose such a plan on a product level and listen to feedback from editors.

{{🌎🌍🌏}}

外部链接

一些讨论相似主题的相关页面: