Küresel şablonlar/Alternatif çözümler

This page is a translated version of the page Global templates/Alternative solutions and the translation is 100% complete.

Wikimedia projelerinde şablonlar ve modüller 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 Küresel şablonlar belirtiminin kısa sürümünde daha ayrıntılı ve tam sürümünde 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, küresel kişisel JS ve CSS sayfaları , küresel kullanıcı sayfaları , 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 (görev T224721 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 Küresel ş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.

Ayrıca, gelişen vikimetinin kendi başına, sadece şablon ve modül geliştiricileri üzerinde doğrudan etkisi olacağı unutulmamalıdır. Bu, onların daha verimli çalışmasını sağlar ve daha iyi ve daha kullanışlı şablonlar geliştirmelerine yardımcı olabilir. Bu arzu edilir, ancak daha az görülebilir. Şablonları küresel hale getirmek ise, yalnızca geliştiriciler üzerinde değil, tüm vikilerdeki tüm editörler ve okuyucular üzerinde doğrudan, pozitif ve görünür bir etkiye sahip olacaktır.

Yapısal verileri viki sözdizimine entegre etme

TL;DR: İyi bir uzun vadeli stratejik hedeftir, ancak şimdilik çok ileri getirilmiştir ve küresel bir şablon deposu, bunu uygulamak için gerekli bir adım olacaktır.

“Evrimleşen vikimetin” ,le benzeyen bir başka teklif, viki sözdizimini, mevcut, çoğunlukla yapısız wikitext ve Vikiveri gibi tamamen yapılandırılmış bir depolama alanı arasında orta zemin olarak veri için daha yapılandırılmış hale getirmektir. User:Tgr (WMF)/structured article data sayfasında açıklanmaktadır.

Bu geçerli bir tekliftir ve bazı toplulukların bilgileri sayfalarda yerel olarak kontrol etme isteği ile yapılandırılmış bilgiyi yazılımla anlamsal olarak işleme ihtiyacı arasındaki dengeyi ele alır. Ancak, "Evrimleşen vikimetin" önerisi ve bu sayfada açıklanan diğer bazı teklifler gibi, son derece teknik şablonları korumak için gerekli beceriye sahip olmayan vikilerin ihtiyaçlarını karşılamamaktadır.

Bu teklif Küresel şablonlar teklifiyle çelişmez ve her ikisi de uygulanabilir. Bununla birlikte, bu teklif aynı zamanda şablonlar küresel hale getirilmeden uygulanırsa, en azından öngörülebilir gelecekte büyük olasılıkla yalnızca en büyük vikilerde kullanılacaktır.

JavaScript'te modül yazmaya izin verin

TL;DR: Farklı sorunları çözer, ancak söz konusu olanı çözmez.

Scribunto modüllerinin Lua dışındaki dillerde, özellikle JavaScript'te yazılmasına izin vermek için birkaç teklif var. Bir örnek için yukarıda belirtilen sunumunda görev T61101 ve 18'e Şablonların Çalışma Şeklini Tamamen Değiştirelim! belgesine bakın.

Bu geçerli bir teklif. JavaScript'i Lua'dan daha fazla kişi biliyor, bu nedenle modül geliştirmeyi daha fazla kişi için erişilebilir hale getirmeli ve modül geliştiricilerinin sayısı artabilir.

Ancak yine de, bu sadece üye olarak geliştiricileri olan toplulukları etkileyecektir. Diğer birçok dilde viki topluluklarında hiç geliştirici yoktur, bu nedenle bu özelliğin meyvelerinden zevk almazlar.

Şablonların bir projeden diğerine daha kolay kopyalanması için bir paket yönetim sistemi oluşturun

TL;DR: Kullanıcılar için uygun bir şey gibi görünse de aslında ölçeklenebilir değildir ve bu yolda çok ileri gitmek işleri yalnızca karmaşıklaştırır.

Şu anda, bir şablonu bir vikiden diğerine kopyalamak için düzenleyicinin şablonu, bazı basamaklı sayfalar da dahil olmak üzere kaynak vikiden bir viki sayfası olarak dışa aktarması, hedef vikiye aktarması, insan tarafından okunabilir dizeler için viki sözdizimini araması gerekir. Bunları çevirin ve kalan hataları düzeltin. Sonuç gerektiği gibi çalışabilir, ancak kaynak şablonun bir çatalı olacaktır. Bu son derece manüel ve zor bir süreçtir ve sonuçlar mükemmel olmaktan uzaktır.

Bazen şablonlar ve modüller için paket yönetimi gibi bir şey yapma önerileri vardır, böylece kopyalama daha kolay hale gelir. Ancak, bu da çok kısmi bir çözüm olacaktır. İyi bir şekilde yapılsa bile, her şablon için bu kopyalama işleminin yürütülmesini gerektirirken, küresel bir havuz tüm şablonu sıfır ekstra adımlarla hemen kullanılabilir hale getirecektir. Aslında, Çok Dilli Şablonlar ve Modüller sayfasında açıklanan sistem, gönüllüler tarafından geliştirilen DiBabel aracı ile birlikte zaten buna benzer bir şey uygulamaktadır ve bunu yaparken, Şablonların vikiler arasında kopyalanması ve küresel şablonlara geçiş sayfasında açıklanan diğer adımları gerçekleştirmek daha kolay, her şablon için her zaman tekrarlanan manüel adımlar gerektirecektir. Bu, paylaşılması gereken binlerce şablon için ölçeklenemez.

Küçük araçları küresel yapın

TL;DR: Farklı sorunları çözer, ancak söz konusu olanı çözmez.

Küçük araçlar, vikide tarafından geliştirilen ve kullanıcı tercihleri aracılığıyla bunları kolayca etkinleştirip devre dışı bırakacak şekilde paketlenmiş JavaScript parçalarıdır.

Şablonlar gibi, bunlar teklifin kısa sürümünde açıklandığı gibi Wikimedia yazılımının “Yerel özelleştirmeler” tarafına aittir. Küçük araçlara ilgili sorunlar şablonlardaki soruna benzer: bir vikiden diğerine kolayca taşınamazlar ve ünlü HotCat küçük aracı tarafından kullanılanlar gibi vikiler üzerinde çalışmasını sağlamak için mevcut hackler bile kusurludur. Ek olarak, uzantılar için olduğu gibi, yerelleştirme için uygun ve tekdüze bir çerçeveye sahip değildirler.

Bu nedenle, araçları küresel hale getirmek de mümkün olmalıdır. Aslında, “Küresel küçük araçları” 2016 Topluluk İstek Listesi Anketi de 1 numarada yer aldı, ancak Topluluk Teknik ekibi için çok büyük olduğu için uygulanmadı.

Ancak, küresel küçük araçlar için teknoloji, küresel şablonlar için olan teknolojiden oldukça farklı olacaktır. Küçük araçlar yalnızca ön uç bileşenleridir ve bazen sayfa içeriğini etkilese de, çoğunlukla kullanıcı arayüzünü değiştirirler. Küçük araçların işlevselliği ayrıştırıcı ve MediaWiki arka ucundan neredeyse hiç etkilenmez (belki ResourceLoader hariç).

Şablonlar farklıdır: içerikte güçlü bir şekilde oluşturulmuş ve sunucu tarafında oluşturulmuştur, bu nedenle çekirdek platform ve özellikle ayrıştırıcı ile güçlü bir şekilde birleştirilirler. Buna ek olarak, küçük araçlar öncelikle vikilerin güç kullanıcıları tarafından kullanılırken, şablonların kodu tüm editörler tarafından görülür ve şablonların çıktısı tüm okuyucular tarafından görülür, bu nedenle şablonların etkisi çok daha büyüktür.

Küresel şablonlar ve küçük araçlar için genel olabilecek en alakalı şey, yerelleştirmelerini depolamak ve yönetmektir, ancak bu bile kesin değildir. Kullanıcı arabirimi dizelerinin (mesajlarının) yerelleştirilmesi benzer olabilir, ancak şablonların şablon adının ve parametrelerin yerelleştirilmesi gibi ek ihtiyaçları vardır.

Dolayısıyla evet — küçük araçların, şablonların ve modüllerin tümü küresel olmakla birlikte, küçük araçlarını çoğunlukla modüllerden ve şablonlardan ayrı olarak ele almak mantıklıdır.

Merkezi bir depodan şablon kopyalayan bir bot oluşturun

TL;DR: Zaten var ve aynı sorunu çözüyor, ancak mükemmel değil ve hatta botun bakıcısı bile bunu kabul ediyor.

Multilingual Templates and Modules teklif bununla ilgilidir. Mevcut MediaWiki platformu göz önüne alındığında makul bir yaklaşımdır, ancak bazı dezavantajları vardır. Aslında, bu projenin kendi açıklama sayfası bunun en iyi yaklaşım olmadığını kabul ediyor.

Bot yaklaşımı, her dilde her şablon için birkaç manüel adım gerektirir. Mesajları yerelleştirmek için tam teşekküllü çeviri araçlarına sahip değildir ve bunun yerine JSON dosyalarını düzenlemeyi gerektirir.

Son olarak, şablonları tüm dillerde gerçekten kullanılabilir hâle getirmez. Bu sistem yine de editörlerin her vikideki her şablonu seçmesini gerektirir. Bu katılım süreci, tamamen manüel şablon içe aktarma işleminden biraz daha kolaydır, ancak yine de her şablon için birkaç adım gerektirir.

Yani evet, MediaWiki teknolojisinin 2021'deki durumu göz önüne alındığında muhtemelen en iyi yaklaşım budur. Yazılım platformundaki küresel şablonlar ve modüller için gerçek desteğe doğru bir test alanı ve bir geçiş aşaması olarak hizmet edebilir. Ancak mükemmel değil.

Ön uç geliştirme kitaplığını güncelleyin

TL;DR: Farklı sorunları çözer, ancak söz konusu olanı çözmez.

2019'da (veya daha da önce), MediaWiki'nin ön uç geliştirme kitaplığını jQuery, ResourceLoader ve OOJS kullanıcı arayüzünden yeni bir şeye yükseltmek hakkında ciddi tartışmalar başladı (görev T241180 sayfasına bakın). Bu ayrıca, yapılandırılmış ön uç yazılımını projeler arasında paylaşmak için olası bir çözüm olarak sunulmuştur. Teorik olarak mümkün olsa da, pratikte muhtemelen küçük araçlara şablonlardan daha uygulanabilir. Şablonları tamamen JavaScript'e taşımak, vikimetinden vazgeçmek anlamına gelecektir, bu da yakın gelecekte topluluk için pek mümkün değildir.

Yeni bir ön uç geliştirme kitaplığına geçiş yapmak, JavaScript kodu ve şablonlar arasındaki arabirimi iyileştirmek için bir fırsat olabilir, ancak JavaScript, modernleştirilmiş bir biçimde bile vikimetinin yerini tamamen alamaz. Küresel şablon deposu, vikimetinin (ve Lua) yeni depolanması için bir tekliftir.

Vikiişlevler ve Abstract Wikipedia

TL;DR: Bu projenin daha büyük hedefleri var. Esasen Küresel şablonlarla aynı olan küresel bir kod deposu içerir. Küresel şablonlar önerisi bunun bir parçası olarak uygulanabilir.

"Abstract Wikipedia" veya Vikiişlevler (ve daha önce "Çok Dilli Vikipedi" ve "Wikilambda" olarak) bilinen önerisi, merkezi bir veri kümesinden ve konuların özet tanımları. Bu sayfadaki tüm farklı alternatif teklifler arasında, bu belki de Küresel şablon tekliflerine en yakın olanıdır, ancak onun yerine geçmez.

Vikiişlevler projesinin önerdiği ana işlevsellik, modüller ve şablonlar için mevcut teknolojiye göre doğal dilde metin (düzyazı) oluşturma yeteneklerinde önemli ölçüde daha gelişmiştir. Bununla birlikte, merkezi işlev deposu, Küresel şablonlar ve modüller için gerekli olan şeyle aynıdır. Mayıs 2020 itibarıyla Abstract Wikipedia görev listesi, nasıl yapılacağı konusunda çok daha az ayrıntılı olmasına rağmen, ilk teslim edilebilir öğelerden biri olarak "WMF projeleri arasında şablonlar ve modüller paylaşmak için bir çapraz viki deposu" içeriyor. Aslında Küresel şablonlar önerisinden daha işe yarıyor.

Bu nedenle, hem Vikiişlevler hem de Küresel şablonlar, bir kod deposu olarak hizmet verecek yeni bir vikiye ihtiyaç duyacak: şablonlar, modüller ve metin oluşturma işlevleri. Her ikisi de, "Bağımlılık motoru olarak da bilinen, bağımlılıkları yönetmek ve vikiler arasında değişim yayılımını yönetmek için modern bir mekanizmaya ihtiyaç duyacaktır. Ancak Vikiişlevler ve Küresel şablonlarının nihai hedefleri farklıdır ve birbirlerini tamamlayacaklardır. Editörlere aşinalıklarından dolayı, modüller ve şablonlar önce küresel hâle getirilmeli ve viki editörlerinin kullanımına sunulmalı ve Vikiişlevler düzyazı oluşturma işlevleri takip etmelidir.

Sonuç

Şablonlar ve modüller etrafındaki teknolojinin geliştirilebileceği birçok yol vardır. Bazıları açıkça Wikimedia projelerine çeşitli şekillerde faydalı olacaktır ve gerçekleştirilmelidir. Ancak, bunların hiçbiri teklif bölümünde açıklanan sorunu tamamen veya kısmen çözmez: birden çok viki için yararlı olan ve bunlara ihtiyacı olan herkes için kolayca ve anında şablon olarak uygulanan özelliklere sahip olma ihtiyacı şablon geliştirme ve dağıtımının kolaylığını ve çevikliğini korur. Yalnızca Küresel şablonların uygulanması bu sorunu kapsamlı bir şekilde çözecektir. {{🌎🌍🌏}}

Ayrıca bakınız