Global templates/Alternative solutions/tr

Wikimedia projelerinde ve  her projede yereldir ve bu kullanılabilirlik, bulunabilirlik, bilgi eşitliği, içerik yayılımı ve yapılandırılmış veri işleme için bir sorundur.

Sorun daha ayrıntılı ve  daha ayrıntılı olarak açıklanmaktadır.

Yukarıda belirtilen sayfalar da çözümü önermektedir: Bazı şablonların ve modüllerin genel yapılmasına izin ver, Commons,, , vb.

Sorunun gerçek olduğunu ve çözülmesi gerektiğini kabul ediyorsanız, ancak şablonları ve modülleri küresel hale getirmenin önerilen çözümü uygun değildir ve bunun yerine başka bir şey yapılması gerekir, bu sayfa tam size göre. Son yıllarda önerilen sorunu çözmenin diğer birkaç yolunu tartışıyor ve neden şablon ve modülleri küresel hale getirmek kadar iyi olmadıklarını açıklıyor.

Bu tekliflerden bazıları sorunu kapsamlı bir şekilde ele almıyor, bazıları ise birbiriyle ilişkili, ancak farklı sorunları ele alıyor. Önerilen diğer çözümlerin her biri bu sayfadaki bir bölümde tartışılmıştır. Hala bir şeye katılmıyorsanız, bu sayfayı düzenlemek veya tartışma sayfasında tartışmaktan çekinmeyin.

Bazı şablonları ve modülleri uzantılara dönüştürün
TL;DR: Bazı şablonlar ve modüller için bunu yapmak iyidir, ancak hepsi için bunu yapmak mümkün değildir.

Bazı şablonlar ve modüller uzantılara dönüştürülebilir. Bunun aşağıdaki avantajları olacaktır:
 * Uzantıların tüm vikilere yüklenmesi kolaydır.
 * Translatewiki'de uzantıların yerini belirlemek kolaydır.
 * Uzantıların kod inceleme, entegrasyon ve dağıtım için sağlam bir süreci vardır ve bu kararlılık, test ve güvenlik için iyidir.

Bununla birlikte, bu yaklaşımla ilgili birkaç sorun da vardır:
 * Programlama dilleri farklıdır: Şablonlar viki sözdizimindedir ve modüller Lua'da ve uzantılar PHP ve JavaScript'tedir. Bu nedenle, bir şablonu dönüştürmek, tam bir yeniden yazma gerektirir ve bu da önemli miktarda kaynak ve zaman gerektirir.
 * Nihai ürün daha sağlam olsa da, hatalar herhangi bir yeniden yazma işleminde olduğu gibi yol boyunca sokulabilir.
 * Çoğu şablon koruyucusu PHP, JavaScript ve Git hakkında bilgi sahibi değildir. Viki sözdizimini, Lua'yı ve viki sayfalarını düzenlemeyi tercih ederler. Yüzlerce şablon sahibi var ve deneyimlerini ve becerilerini atmak hem sosyal hem de pratikte doğru değil. İşlem şablon koruyucular ve wiki düzenleyicilerini yabancılaştıracaksa, uzantıları atar ve şablonları kullanmaya devam eder.
 * Mevcut Gerrit kodu inceleme ve dağıtım işlemi, özellikle şablonların hemen dağıtımına kıyasla son derece yavaştır.

Sorunlara rağmen, bazı şablonların ve modüllerin uzantılar olarak yeniden yazılması, özellikle karmaşık, kararlı, nadiren değiştirilen, birçok vikide açıkça yararlı olan ve yüksek güvenlik, kararlılık ve performans gereklilikleri. Özellikle, bu, uzantılarda nispeten kolayca paketlenebilen modüller için oldukça kolay olabilir. Uzantılarda Lua dosyalarını paketleme yeteneği zaten var, ancak nadiren kullanılıyor. Bununla birlikte, tüm şablonları uzantı olarak yeniden yazmak ne uygun ne de arzu edilir.

Mevcut şablonların parametrelerini birbirleriyle eşleştirin
TL;DR: Zaten yapılıyor ve biraz yardımcı oluyor, ancak ölçeklenebilir değil.

Şablonlar arasında projeler arasındaki uyumsuzluk sorununu gidermek için bazı öneriler şablonların parametrelerinin birbiriyle eşlenmesini önerir.

Bu çözüm gerçekten bir dereceye kadar uyumsuzluk sorununu hafifletebilir. İçerik Çeviri uzantısında, parametreleri eşlemek için TemplateData diğer adlarını kullanan bir saldırı olarak zaten yapılmıştır. Bu, Vikipedi madde çevirisini biraz daha sağlam hale getirdi. Bu, hangi parametrelerin eşlenmesi gerektiğini tahmin etmek için bazı makine öğrenme teknikleri kullanılarak İçerik Çevirisi'nde daha da geliştirilmektedir ( sayfasına bakın).

Ancak, bu gelişmelerle bile, bu asla tam bir çözüm olmayacaktır. Her şeyden önce, tüm sorunu ele almaz. Mevcut şablonlar arasındaki uyumsuzluk sorunun sadece bir yönüdür. Daha geniş bir problem, birçok projede, söz konusu şablonların gerekli olsalar bile, hiç bulunmamasıdır.

Ayrıca, parametre eşlemesinin her dil çiftindeki her şablon için manüel ve sürekli olarak sürdürülmesi gerekir ve bu ölçeklenmez. Bazı yaygın şablonlar için yapılmış olsa bile, yeni şablonlar yerel olarak oluşturulmaya devam edecek ve daha manüel haritalama gerektirecektir. Bunun sonu yok.

Küresel şablon teklifi, parametre adlarını yerelleştirmek için merkezi ve sağlam bir sistem önerir (“Parametreleri yerelleştirme” bölümünde). Bu, tüm parametrelerin, açıkça yerelleştirilmemiş olsalar bile, editörler adına herhangi bir çaba göstermeden tüm vikilerde kullanılabileceğini garanti edecektir.

Şablon oluşturma için viki sözdizimini geliştirin
TL;DR: Farklı sorunları çözer, ancak söz konusu olanı çözmez.

Şablonlar için viki sözdizimi zor, karmaşık, karmaşık ve göz korkutucu. Birçok şablonun kaynak kodu, süslü parantezler, boru karakterleri, eşit işaretler, hash işaretleri vb. ile aşırı yüklenmiştir. Ayrıştırma ekibi bu alanda birkaç iyi teklifte bulunmuştur; bir örnek için Wikimania 2019'dan Gelişen vikimetin: artımlılığı kucaklamak sunumuna bakın.

Bu geçerli bir sorundur ve çözülmesi gerekir, ancak Küresel şablonlar teklifinin ele almaya çalıştığı sorundan farklıdır. “Evrimleşen vikimetin” projesi, şablon dilinin kendisini geliştirmektir, “Küresel şablonlar” projesi ise şablonların nasıl saklandığı ve dağıtıldığı ve editörlere nasıl keşfedilebileceği ile ilgilidir. Gelişen vikimetin, şablonun kendisini geliştirmeyi kolaylaştırıyor ve Global şablonlar, herhangi bir vikide şablon kullanmaya başlamak için gereken adım sayısını sıfıra indirmeye çalışıyor.

İki proje birbiriyle çelişmez ve birbirlerinin başarılı olmasına yardımcı olabilir. Bu, başka bir Wikimania 2019 sunumu tarafından onaylandı, Şablonların çalışma şeklini tamamen değiştirelim, her iki sorunu da ayrı ayrı gösteriyor. Şablonları küresel olarak depolamak mümkün olursa, bir şablonun kaynağında, Gelişen vikimetin girişiminin bir parçası olarak yapılması gereken değişikliklerin yalnızca bir kez yapılması gerekir. Şablonlar küresel olmadığı sürece, her şablon için birden çok kez yapılması gerekir.

It should also be noted that evolving wikitext, by itself, will have direct impact only on the developers of templates and modules. This will enable them to work more efficiently, and may help them develop templates that are better and more usable. This is desirable, but less visible. Making templates global, on the other hand, will have direct, positive, and visible impact on all editors and readers in all wikis, and not only on developers.

Integrate structured data into wiki syntax
TL;DR: It is a good long-term strategic goal, but too far-fetched for now, and a global templates repository will be a necessary step towards implementing it.

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

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

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

Allow writing modules in JavaScript
TL;DR: It resolves different problems, but not the one in question.

There have been several proposals to allow writing Scribunto modules in languages other than Lua, most notably in JavaScript. For an example see and slide 18 in the aforementioned Let's Completely Change How Templates Work! presentation.

This is a valid proposal. More people know JavaScript than Lua, so it should make module development accessible to more people, and the number of module developers may grow.

Yet again, however, this will only affect communities that have developers as members. Wiki communities in many other languages do not have any developers at all, so they will not enjoy the fruits of this feature.

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

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

Occasionally there are proposals to make something like a package management for templates and modules, so that copying will become easier. However, this will also be a very partial solution. Even if it is done well, it will require running this copying process for each template, whereas a global repository will make all template immediately available with zero extra steps.

Developing such a package will require something similar to tools that are described on the page about. If it is done, it is better to just go all the way and make a global repository.

Make gadgets global
TL;DR: It resolves different problems, but not the one in question.

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

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

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

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

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

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

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

Make a bot that copies templates from a central repository
TL;DR: It resolves the same problem, but not perfectly, and the project’s creators admits it.

This is what the Multilingual Templates and Modules proposal is about. It is a reasonable approach given the current MediaWiki platform, but it has some disadvantages. In fact, that project’s own description page admits that it is not the best approach.

The bot approach requires several manual steps for each template in each language. It does not have full-fledged translation tools for localizing the messages, and requires editing JSON files instead.

Finally, it does not truly make templates available in all languages. This system still requires the editors to opt in for each template in each wiki. This opt-in process is somewhat easier than the fully manual template importing process, but it still requires several steps for each template.

So yes, it is probably still the best approach given the state of MediaWiki technology in late 2019. It can serve as a testing ground and a transition phase towards true support for global templates and modules in the software platform. But it is not perfect.

Update the frontend development library
TL;DR: It resolves different problems, but not the one in question.

In 2019 (or even earlier), serious discussions began about upgrading MediaWiki’s frontend development library from a mix of jQuery, ResourceLoader, and OOJS UI to something new (see ). This has also been presented as a possible solution for sharing structured frontend software between projects. While theoretically possible, in practice it is probably more applicable to gadgets than to templates. Completely moving templates to JavaScript will mean giving up on wikitext, which is not really feasible for the community in the foreseeable future.

Switching to a new frontend development library can be an opportunity to improve the interface between JavaScript code and templates, but JavaScript, even in a modernized form, cannot replace wikitext completely. A global templates repository is a proposal for new storage of wikitext (and Lua).

Wikilambda or Abstract Wikipedia
TL;DR: 'This project has bigger goals. It includes a global code repository, which is essentially the same as global templates. The Global templates proposal can be implemented as part of it.'

The Wikilambda proposal, also known as “Abstract Wikipedia” or “Multilingual Wikipedia” is an idea to make a global repository of functions that automatically generate prose for Wikipedia articles in multiple languages from a central set of data and abstract descriptions of topics. Of all the different alternative proposals on this page, this one is perhaps the closest to the Global templates proposals, but it is not a replacement for it.

The main functionality that Wikilambda suggests is considerably more advanced in its capabilities to generate text (prose) in natural language than the current technology for modules and templates. However, its central functions repository is essentially the same thing that is needed for Global templates and modules. The Wikilambda task list as of May 2020 even explicitly includes “A cross-wiki repository to share templates and modules between the WMF projects” as one of the first deliverables, although it is much less detailed in how will it actually work than the.

So, both Wikilambda and Global templates will need a new wiki that will serve as a repository of code: templates, modules, and text generation functions. Both will also need a modernized mechanism for managing dependencies and change propagation across wikis, also known as “Dependency engine”). But the eventual goals of Wikilambda and global templates are distinct, and they will complement each other. Because of their familiarity to the editors, modules and templates should be made global and available to wiki editors first, and Wikilambda prose rendering functions should follow.

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