Global templates/Alternative solutions/nl
Sjablonen en modules in Wikimedia projecten zijn lokaal per project, dat is een probleem voor de bruikbaarheid, vindbaarheid, kennis, inhoud vermeerdering en gestructureerde gegevensverwerking.
Het probleem is met meer details beschreven in de korte versie van de Global templates specificatie, er is ook een volledige versie.
Deze genoemde pagina's beschrijven ook de voorgestelde oplossing: Toestaan dat enkele sjablonen en modules globaal worden, dit is vergelijkbaar met afbeeldingen op Commons, globale persoonlijke JavaScript en CSS pagina's, globale gebruikerspagina's, enz.
Als u instemt dat dit een echt probleem is en dat het opgelost moet worden, maar denkt dat het voorstel om bepaalde sjablonen en modules globaal te maken niet optimaal is, en een ander idee heeft, dan kunt u deze pagina gebruiken. Het beschrijft meerdere manieren om dit probleem op te lossen, voorstellen uit recente jaren met verklaringen waarom deze oplossingen minder zijn dan ons voorstel.
Enkele van deze voorstellen geven niet uitgebreid het probleem aan, andere gaan over een ander probleem. Elk van deze voorstellen is besproken in een discussie in een sectie op deze pagina. Als u het er niet mee eens bent, voel u vrij om deze pagina te bewerken en op de overlegpagina dit mee te bespreken. {{🌎🌍🌏}}
Converteren van enkele sjablonen en modules naar extensies
Conclusie: het is voor sommige sjablonen en modules te doen, maar het is niet uitvoerbaar om het voor alle te doen.
Enkele sjablonen en modules kunnen omgezet worden naar een extensie. Dat zou de volgende voordelen hebben:
- Een extensie is eenvoudig te installeren.
- Een extensie is eenvoudig te vertalen op translatewiki.
- Bij extensies is er een echt proces voor het beoordelen van de code, integratie en in productie name. Dit is natuurlijk voor het bereiken van stabiliteit, testen en beveiliging.
Deze aanpak heeft ook nadelen:
- De programmeertalen zijn verschillend: Sjablonen zijn in wiki-syntax en modules zijn in Lua, extensie zijn in PHP en JavaScript. Voor het converteren van een sjabloon zou daardoor het herschrijven nodig zijn en dat zal een aanzienlijke inspanning en tijd kosten.
- Het eindproduct kan dan wel robuuster worden, het is onvermijdelijk dat er fouten worden gemaakt bij de conversie, dat gevaar is er bij elke wijziging.
- Veel mensen die sjablonen onderhouden hebben geeb of beperkte kennis van PHP, JavaScript of Git. Zij hebben een voorkeur voor wiki-syntax, Lua en het bewerken van wiki-pagina's. Er zijn honderden van die mensen en wij kunnen en willen hun kennis en inzet niet missen. Als er door het proces een scheiding komt tussen de sjabloononderhouders en wiki-bewerkers, dan zullen zij de extensies negeren en de sjablonen blijven gebruiken.
- Het huidige proces in Gerrit voor het beoordelen van code en het in gebruik nemen van nieuwe software duurt erg lang, vooral als men het vergelijkt met het invoeren van sjablonen.
Ondanks de problemen is het herschrijven van enkele sjablonen en modules als extensies een goed idee, vooral voor die sjablonen die complex, stabiel en veel gebruikt worden op veel wiki's. Deze stellen hoge eisen aan de security, stabiliteit en performance. Dit kan in het bijzonder voor modules gemakkelijk zijn, deze kunnen in een package in een extensie relatief gemakkelijk worden gedaan. De mogelijkheid voor het inpakken van Lua bestanden in extensies bestaat al, al wordt dat zelden gedaan. Het herschrijven van alle sjablonen als extensies is echter niet haalbaar en ook niet de wens om dat te doen.
Koppel de parameters van bestaande sjablonen aan elkaar
Conclusie: Dit wordt al wel gedaan en het helpt wat, maar het is niet schaalbaar.
Enkele voorstellen voor het aanpakken van de incompatibiliteit van sjablonen tussen projecten stellen het koppelen van parameters van sjablonen met elkaar voor.
Die oplossing kan tot een bepaalde hoogte het probleem oplossen, het is al gedaan bij de extensie Content Translation door het gebruiken van TemplateData aliassen voor het koppelen van de parameters. Hierdoor is het vertalen van Wikipedia artikelen wat robuuster. Dat is zelfs wat verhoogd door wat machine-lerende technieken om te voorspellen welke parameters moeten worden gekoppeld. (taak T224721).
Ook met deze verbeteringen wordt het echter nooit een volledige oplossing. Het pakt niet het hele probleem aan. De incompatibiliteit tussen bestaande sjablonen is maar een aspect van het probleem. Een groter probleem is dat op veel projecten deze sjablonen niet eens bestaan, ook al zijn ze nodig.
Daarnaast is het koppelen van de parameters iets handmatig dat blijvend en per sjabloon ondersteund moet worden voor elk taalpaar. Ook al doen we dat voor enkele gebruikelijke sjablonen, er blijven lokaal sjablonen aangemaakt worden, wat dan nog meer koppeling nodig maakt. Er komt geen eind aan.
Het voorstel met Globale sjablonen beveelt een centraal en robuust systeem voor vertaling parameternamen aan (in de sectie over het vertalen van parameters). Er is dan de garantie dat alle parameters gebruikt kunnen worden, zonder inspanning van de bewerkers, ook al zijn ze niet expliciet vertaald.
Verbeteren van de sjabloontechnologie
Meerdere voorstellen stellen in het algemeen voor de sjabloontechnologie te verbeteren of een andere programmeertaal te gebruiken voor een vergelijkbare taak. Deze voorstellen worden hier besproken, ze hebben allemaal een ding gemeen: er wordt geprobeerd andere problemen op te lossen, niet het probleem om de sjablooncode te delen tussen de de wiki's. Het voorstel "Global templates" beveelt alleen het wijzigen van de opslaan van de sjablonen aan, met gebruik van dezelfde wikitext (en dezelfde Lua code bij modules). De bestaande code wordt dus behouden en daarmee de kennis en kunde van de gemeenschap in die talen. Er kunnen verbeteringen in de technologie van sjablonen en modules worden aangebracht, dit zijn gescheiden problemen die een eigen oplossing vereisen. Die vallen voor ons buiten het project "Global templates".
Het verbeteren van de wiki syntaxis voor het maken van sjablonen
Conclusie: het lost diverse problemen op, maar niet het gevraagde.
De wiki-syntaxis voor sjablonen is moeilijk en complex. De broncode van veel sjablonen bevatten veel accolades, verticale streepjes, gelijktekens, hash-tekens, enz. Het Parsing team heeft hier wat voorstellen voor gedaan; bekijk deze presentatie over wikitext uit Wikimania 2019.
Dit is echt een probleem dat opgelost moet worden, maar het is niet een probleem wat in ons voorstel wordt meegenomen. Het project “Evolving wikitext” gaat over het verbeteren van de taalsjablonen zelf, waar eht het project “Global templates” gaat over het opslaan en leveren van sjablonen en hoe de bewerkers ze kunnen vinden. Het beter maken van wikitext is het proberen het ontwikkelen van het sjabloon gemakkelijker te maken, bij Globale sjablonen is het een poging het aantal stappen om gebruik te maken een sjabloon in een wiki terug te dringen tot nul.
Deze twee projecten bijten elkaar niet, zij kunnen elkaar zelfs helpen om de ander te laten slagen. Dit is een vergelijkbare opvatting in een andere Wikimania 2019 presentatie, Laten we de werking van sjablonen compleet veranderen, daar worden de beide problemen ook apart bekeken. Als het mogelijk wordt om sjablonen lokaal op te slaan, dan hoeft een wijziging in de broncode van dat sjabloon die ten gevolge van het initiatief 'Evolving wikitext' maar eenmalig gedaan te worden. Zolang de sjablonen niet globaal zijn moet het meerdere keren voor elk sjabloon gedaan te worden.
Daarbij zullen enkele wijzigingen in de syntaxis de performance van het verwerken van sjablonen verbeteren, dat zal bijdragen aan het succes van globale sjablonen.
Het verbeteren van de wikitext zelf zal enkel direct van invloed zijn voor de ontwikkelaars van sjablonen en modules. Dat werk kan dan efficiënter worden gedaan, het zal ook een beter en een beter bruikbaar product opleveren. Het globaal maken van sjablonen zal positieve en zichtbare gevolgen hebben voor alle bewerkers en lezers in alle wiki's, dus niet alleen voor de ontwikkelaars.
Toestaan dat modules in JavaScript mogen worden geschreven
Conclusie: het lost diverse problemen op, maar niet het gevraagde.
Er zijn meerdere voorstellen gedaan om toe te staan dat Scribunto modules in andere talen dan Lua mogen schrijven, meestal in JavaScript. Voorbeeld: taak T61101 en de presentatie met dia-18 in het eerder genoemde Let's Completely Change How Templates Work!.
Dit is een geldig voorstel. Er zijn meer mensen met kennis van JavaScript dan van Lua, het ontwikkelen zou dus door meer mensen gedaan kunnen worden, een groei van het aantal module ontwikkelaars ligt dan voor de hand.
Maar opnieuw, dat is alleen van belang bij gemeenschappen waar onder de leden ook ontwikkelaars zitten. De Wiki gemeenschappen in andere talen hebben meestal geen ontwikkelaars, dus dan is er minder kans op groei van het aantal ontwikkelaars.
Wijzig het frontend van de ontwikkel bibliotheek
Conclusie: het lost diverse problemen op, maar niet het gevraagde.
In 2019 (of was het al eerder) waren er discussies over het upgraden van het frontend van MediaWiki met een combinatie van jQuery, ResourceLoader en OOJS UI naar iets nieuws (zie: taak T241180). Dit is ook gepresenteerd als een mogelijke oplossing voor het delen van gestructureerde frontend software tussen projecten. Hoewel technisch mogelijk is dit in de praktijk waarschijnlijk meer geschikt voor gadgets dan voor sjablonen. Het compleet verplaatsen van sjablonen naar JavaScript zou het opgeven van wikitext betekenen, dat is voor de gemeenschap iets wat in de te overziene tijd onhaalbaar is.
Het gaan naar een nieuwe frontend ontwikkel bibliotheek kan een mogelijkheid geven om de interface tussen JavaScript en sjablonen te verbeteren, maar ook een meer moderne JavaScript, kan wikitext niet geheel vervangen. Een globale sjablonen repository is een voorstel voor een nieuwe opslag van wikitext (en Lua).
Wikifunctions en Abstract Wikipedia
Conclusie: Dit project heeft hogere doelen. Het bevat een globale code repository, wat eigenlijk hetzelfde is als globale sjablonen. Men zou globale sjablonen als deel van de implementatie hiervan kunnen zien.
Het project Wikifunctions, ook bekend als "Abstract Wikipedia" (en voorheen als "Multilingual Wikipedia" en "Wikilambda") is een idee om een wereldwijde repository van functies te maken die automatisch proza genereren voor Wikipedia-artikelen in meerdere talen uit een centrale set gegevens en abstracte beschrijvingen van onderwerpen. Van alle verschillende alternatieve voorstellen op deze pagina komt deze misschien het dichtst in de buurt van de voorstellen voor algemene sjablonen, maar het is geen vervanging ervoor.
De belangrijkste functionaliteit die het project Wikifunctions suggereert, is aanzienlijk geavanceerder in zijn mogelijkheden om tekst in natuurlijke taal te genereren dan de huidige technologie voor modules en sjablonen. De centrale repository voor functies is echter in wezen hetzelfde als wat nodig is voor globale sjablonen en modules. De Abstracte Wikipedia-takenlijst vanaf mei 2020 bevat zelfs expliciet "Een cross-wiki repository om sjablonen en modules te delen tussen de WMF-projecten" als een van de eerste producten, hoewel het veel minder gedetailleerd is hoe het daadwerkelijk zal werken dan in het Voorstel voor globale sjablonen.
Het belangrijkste verschil is dat er vanaf begin 2023 vrijwel geen bruikbare Wikifuncties meer zijn, terwijl er een enorme bestaande codebase is geschreven als wikitekstsjablonen en Lua-modules. Deze codebase is stabiel en getest, het werkt al jaren in productie en het heeft bekwame mensen die het onderhouden. Het biedt belangrijke functies, die op miljoenen wikipagina's worden gebruikt en die gebruikers in veel meer wiki's willen gebruiken. In theorie zouden deze functies kunnen worden herschreven als Wikifuncties, maar gezien het feit dat het ongeveer twintig jaar duurde om ze te schrijven, kan het nog vele jaren duren om ze te herschrijven.
Dus zowel Wikifunctions als Globale sjablonen hebben een nieuwe wiki nodig die zal dienen als een repository van code: sjablonen, modules en functies voor tekstgeneratie. Beide hebben ook een gemoderniseerd mechanisme nodig voor het beheren van afhankelijkheden en het wijzigen van de verspreiding over wiki's, ook bekend als " Afhankelijkheidsengine". Maar de uiteindelijke doelen van Wikifunctions en Globale sjablonen zijn verschillend, ze zullen elkaar aanvullen. Vanwege hun bekendheid bij de moderatoren en vanwege de enorme en werkende codebase van modules en sjablonen, moeten ze wereldwijd worden gemaakt en beschikbaar zijn voor wiki-moderatoren. Wikifunctions zijn geen vervanging, maar een aanvulling, ze kunnen afzonderlijk worden ingezet.
Integreer gestructureerde gegevens in de wiki syntaxis
Conclusie: dit is op de lange termijn een mooi doel, maar nu niet praktisch op deze termijn. Ook zal een repository voor globale sjablonen dan toch hierbij ook een noodzakelijk stap zijn.
Een ander voorstel dat wat vergelijkbaar is met "Evolving wikitext" is het meer gestructureerd maken van wiki-syntaxis voor gegevens, als een middenweg tussen de huidige, meestal structuurloze wikitekst en een volledig gestructureerde opslag zoals Wikidata. Het wordt beschreven op deze pagina.
Dit is een interessant voorstel en het komt tegemoet aan de noodzaak om een evenwicht te vinden tussen de wens van sommige gemeenschappen om de informatie lokaal op de pagina's te beheren en de noodzaak om gestructureerde informatie semantisch door software te verwerken. Echter, net als het voorstel "Evolving wikitext" en enkele andere voorstellen die op deze pagina worden beschreven, gaat het niet in op de behoeften van de wiki's die geen mensen hebben die over de nodige vaardigheden beschikken om de zeer technische sjablonen te onderhouden.
Dit voorstel is niet in tegenspraak met het voorstel voor globale sjablonen, beide kunnen worden uitgevoerd. Als dit voorstel echter wordt geïmplementeerd zonder ook de sjablonen globaal te maken, dan zal het in ieder geval in de nabije toekomst hoogstwaarschijnlijk alleen in de grootste wiki's worden gebruikt.
Maak een beheersysteem voor packages voor het eenvoudiger kopiëren van sjablonen naar een ander project
Conclusie: dit lijkt voor gebruikers gemakkelijk, maar het is niet schaalbaar en het lijkt ver af te wijken van wat we willen en het zal de zaken gecompliceerder maken.
Om nu een sjabloon van de ene wiki naar de andere te kopiëren, moet de editor het exporteren als een wikipagina van de bronwiki, inclusief enkele trapsgewijze pagina's, het importeren in de doelwiki, de wikisyntaxis doorzoeken op door mensen leesbare tekenreeksen en deze vertalen, en vervolgens eventuele fouten oplossen. Het resultaat kan naar behoefte werken, maar het is een afsplitsing van het bronsjabloon. Dit is een handmatig en moeilijk proces.
Af en toe zijn er voorstellen om iets als een pakketbeheer voor sjablonen en modules te maken, zodat het kopiëren gemakkelijker wordt. Dit zal echter ook een zeer gedeeltelijke oplossing zijn. Zelfs als het goed wordt gedaan, moet dit kopieerproces worden uitgevoerd per sjabloon, terwijl een wereldwijde repository alle sjablonen onmiddellijk beschikbaar maakt zonder extra stappen. In feite heeft het systeem dat wordt beschreven op de pagina Meertalige sjablonen en modules, samen met het door vrijwilligers ontwikkelde DiBabel-tool, al zoiets geïmplementeerd, hoewel het het iets gemakkelijker maakte om sjablonen tussen wiki's te kopiëren en andere stappen uit te voeren die op de pagina worden beschreven over de overgang naar algemene sjablonen, zou het altijd herhaalde handmatige stappen vereisen voor elk sjabloon. (Vanaf begin 2023 is DiBabel inactief.) Dit kan niet worden geschaald voor de duizenden sjablonen die moeten worden gedeeld.
Maak gadgets globaal
Conclusie: het lost diverse problemen op, maar niet het gevraagde.
Gadgets zijn stukjes JavaScript die in de wiki zijn ontwikkeld en verpakt op een manier die het gemakkelijk maakt om ze in en uit te schakelen via gebruikersvoorkeuren.
Net als sjablonen behoren ze tot de kant "Lokale aanpassingen" van Wikimedia-software, zoals beschreven in de korte versie van het voorstel. De problemen met gadgets zijn vergelijkbaar met die met sjablonen: ze kunnen niet gemakkelijk van de ene wiki naar de andere worden geporteerd, en zelfs de bestaande hacks om ze over wiki's te laten werken, zoals die worden gebruikt door de beroemde HotCat-gadget, zijn onvolmaakt. Ook hebben ze geen handig en uniform kader voor lokalisatie, zoals er is voor extensies.
Het moet dus mogelijk zijn om gadgets ook globaal te maken. In feite kwam "Globale gadgets" binnen op # 1 op de enquête over de wensenlijst van de gemeenschap 2016, maar werd niet geïmplementeerd omdat het te groot werd geacht voor het Community Tech-team.
De technologie voor wereldwijde gadgets zal echter heel anders zijn dan de technologie voor wereldwijde sjablonen. Gadgets zijn puur frontend-componenten en hoewel ze soms de pagina-inhoud wijzigen, veranderen ze meestal de gebruikersinterface. De functionaliteit van de gadgets wordt nauwelijks beïnvloed door de parser en de MediaWiki-backend (behalve misschien ResourceLoader).
Sjablonen zijn anders: ze zijn sterk ingebouwd in de content en server-side gerenderd, dus ze zijn sterk gekoppeld aan het core platform en vooral de parser. Bovendien worden gadgets voornamelijk gebruikt door power-users van de wiki's, terwijl de code van de sjablonen door alle editors wordt gezien en de uitvoer van de sjablonen door alle lezers wordt gezien, dus de impact van de sjablonen is veel groter.
Het meest relevante dat gemeenschappelijk kan zijn voor wereldwijde sjablonen en gadgets is het opslaan en beheren van hun lokalisatie, maar zelfs dit is niet zeker. De lokalisatie van hun tekenreeksen in de gebruikersinterface kan vergelijkbaar zijn, maar sjablonen hebben aanvullende behoeften, zoals de lokalisatie van de sjabloonnaam en de parameters.
Dus hoewel gadgets, sjablonen en modules allemaal globaal moeten zijn, is het waarschijnlijk logisch om gadgets meestal los van modules en sjablonen te behandelen.
Maak een bot die sjablonen uit een centrale repository kopieert
Conclusie: Dat bestaat al, het lost hetzelfde probleem op, maar niet perfect en moeilijk te onderhouden, dat geeft ook de onderhouder van de bot toe.
Dit is de kern van het voorstel Multilingual Templates and Modules. Het is een redelijke aanpak gezien het huidige MediaWiki-platform, maar het heeft enkele nadelen. In feite geeft de eigen beschrijvingspagina van dat project toe dat het niet de beste aanpak is. Het werd ontwikkeld als een bot genaamd DiBabel, met een webgebaseerde frontend om de sjablonen en modules in verschillende talen te synchroniseren. Vanaf begin 2023 is de DiBabel-bot echter verlaten en werkt deze niet.
Deze benadering vereiste meerdere handmatige stappen voor elke sjabloon in elke taal. Het had geen volwaardige vertaalhulpmiddelens voor het lokaliseren van de berichten en vereiste in plaats daarvan het handmatig bewerken van wikipagina's met JSON-bestanden.
Ten slotte heeft het niet echt sjablonen in alle talen beschikbaar gemaakt. Dit systeem vereiste nog steeds dat de redacteuren zich in elke wiki moesten aanmelden voor elk sjabloon. Dit opt-in-proces is iets eenvoudiger dan het volledig handmatige proces om sjablonen te importeren, maar het vereist nog steeds meerdere stappen voor elk sjabloon, dus het is nauwelijks schaalbaar.
Dus ja, het was misschien wel de meest praktische aanpak gezien de staat van MediaWiki-technologie in 2021. Iets dergelijks kan opnieuw worden geprobeerd en dienen als een proeftuin en een overgangsfase naar echte ondersteuning voor wereldwijde sjablonen en modules in het softwareplatform. Maar het kan geen perfecte en volledig schaalbare oplossing zijn.
(Nog een soortgelijke opzet: Synchronizer.)
Conclusie
Hierboven is per alternatief ook een conclusie gegeven. Eigenlijk is het meer een beoordeling van TL en DR van de eerst niet vertaalde tekst per alternatief. Het was eerst niet vertaald omdat het wel erg gedetailleerd is en het zaken zijn die alleen als alternatieven besproken zijn. Later is het toch maar vertaald. Als conclusie over het geheel kunnen we het zeggen dat er zijn veel manieren waarop de technologie rond sjablonen en modules verbeterd kan worden. Enkele kunnen zeker op meerdere punten voordelig zijn voor Wikimedia projecten, die punten zouden opgepakt kunnen worden. Er is er echter geen die ook maar deels het probleem oplost wat in het voorstel is beschreven: de noodzaak om functies te hebben die op meerdere wiki's bruikbaar zijn en als sjablonen eenvoudig kunnen worden gemaakt en die dan direct beschikbaar voor iedereen die ze nodig heeft. Dit terwijl het gemak en de flexibiliteit bewaard blijft van het ontwikkelen en toepassen van sjablonen. Alleen de implementatie van Globale sjablonen zal dit probleem afdoende oplossen. {{🌎🌍🌏}}