Global templates/Proposed specification/nl
Dit is een voorstel voor de functionele vereisten voor globale sjablonen en modules.
U kunt ook een beknopte versie van dit voorstel lezen.
Dit is geen project dat wordt uitgevoerd of gepland om door iemand op een bepaald moment in de tijd te worden uitgevoerd, althans nog niet. Dit is slechts een idee, zij het een zeer gedetailleerd idee.
Het uiteindelijke doel is om een team- en projectoverschrijdend betrokkenheid te vormen bij het implementeren van deze dingen, met de juiste architectuur, product- en projectmanagement, betrokkenheid van de gemeenschap, enz.
Dit document probeert niet in te gaan op de details van technische implementatie in termen van opslag, caching, levering, PHP-codeontwerp, enz. Het probeert alleen de vereisten te definiëren van hoe deze functie dient te werken vanuit het oogpunt van de gebruikers:
- Mensen die sjablonen en modules maken en onderhouden.
- Mensen die pagina's maken en bewerken die sjablonen en modules bevatten. Dit omvat alle editors en alle soorten pagina's:
- Alle ervaringsniveaus: van degenen die volledig nieuw zijn tot degenen die duizenden bewerkingen hebben uitgevoerd
- Allerlei bewerkingshulpmiddelen: wiki-syntaxisbewerking, Visual Editor, Content Translation en andere (zelfs botoperators)
- Alle wiki's: Wikipedia, Wikiwoordenboek, Wikivoyage, Wikidata, Incubator, etc., en eventuele nieuwe toekomstige projecten
- Alle talen: Engels, Frans, Russisch, Spaans, Armeens, Perzisch, Zulu, Manipuri, enz.
- Alle soorten pagina's: Wikipedia-artikelen, overlegpagina's met artikelen, overlegpagina's voor gebruikers, discussiepagina's voor de gemeenschap, WikiProject-pagina's, categorieën, sjabloondocumentatiepagina's, enz. {{🌎🌍🌏}}
Moeilijk beginpunt
Een groot deel van de functionaliteit van Wikimedia-sites is geïmplementeerd in sjablonen en Lua-modules. In hun huidige vorm kunnen ze niet worden gedeeld tussen verschillende wiki's en talen. Hierdoor zijn ze moeilijk te integreren met moderne manieren om artikelen te maken en te bewerken, zoals Visual Editor, Wikidata en Content Translation. Ze zijn ook moeilijk aan te passen aan mobiele apparaten. Dit veroorzaakt verspilling van de inspanningen van bijdragers en problemen voor nieuwe redacteuren en kleinere projecten. Het moet mogelijk worden om ze te delen op wikisites, net als Commons-afbeeldingen. Dit zal softwareontwikkeling sneller en robuuster maken, en het zal redacteuren ook in staat stellen zich meer te concentreren op het schrijven. {{🌎🌍🌏}}
Het probleem
Algemene opmerking: Tenzij anders vermeld, zijn alle verwijzingen naar "sjablonen" ook van toepassing op Scribunto Lua modules.
Sjablonen implementeren functies van Wikimedia-sites. Sommige van deze functies zijn zeer prominent, vooral de infoboxen, de referenties, "citatie nodig" en vele anderen. Zie de uitgebreidere lijst met functies die zijn geïmplementeerd met behulp van sjablonen. Alle lezers zien ze en alle redacteuren komen ze tegen in bijna elke bewerkingsactie. Bovendien implementeren ze veel van de interne communitybeheerfuncties van de sites: verzoeken om verwijdering, verzoeken om deblokkering, het uiten van steun in discussies, het sorteren van artikelen voor WikiProjects, enz.
Sjablonen bieden een efficiënt mechanisme om snel repetitieve stukken tekst en markeringen op veel pagina's te ontwerpen, te implementeren en te gebruiken. Sjablonen hebben echter ook verschillende acute bruikbaarheidsproblemen voor allerlei soorten editors.
Moeilijkheden voor veel redacteuren in alle wiki's
Wiki syntaxis editors
Sjablonen zijn vaak moeilijk te begrijpen door de wiki-syntaxis. Mensen die ervaring hebben met het gebruik van een bepaald sjabloon, zullen een pagina kunnen bewerken die deze bevat. Redacteuren die niet bekend zijn met dit sjabloon, moeten echter de documentatie opzoeken wanneer ze het tegenkomen, zelfs als ze over het algemeen ervaring hebben met bewerken en van andere sjablonen. Redacteuren met weinig ervaring zullen staren naar de cryptische tekst met o.a. accolades, verticale streepjes en is-tekens
Als u een functie gebruikt die als sjabloon is geïmplementeerd, moet u de naam van de sjabloon kennen en deze tussen accolades ({{}}) typen of van een andere pagina kopiëren. Dit is niet duidelijk voor nieuwe gebruikers en ervaren gebruikers moeten elke nieuwe sjabloon ook afzonderlijk leren.
Sommige wiki's hebben gadgets waarmee knoppen worden toegevoegd waarmee sjablonen die in dat project gebruikelijk zijn, worden ingevoegd in de werkbalk. Deze zijn verschillend in elke wiki, hoewel veel van de sjablonen vergelijkbare functionaliteit hebben voor projecten en talen.
Visual Editor gebruikers
VisualEditor-gebruikers hebben enkele voordelen met het gebruik van sjablonen, maar er zijn ook veel problemen voor hen. In het bijzonder is er een vergelijkbaar vindbaarheidsprobleem: in Visual Editor is alle functionaliteit van de sjablonen verborgen achter het menu-item "Invoegen → Sjabloon" en moet de gebruiker de sjabloonnaam kennen voordat hij deze kan gebruiken.
Het menu "Invoegen" van Visual Editor bevat items voor wiskundige formules, Egyptische hiërogliefen, muziekpartituren en enkele andere functies die als extensies zijn geïmplementeerd, maar het heeft geen items zoals "Infobox", "Bronvermelding nodig", "Eenheid conversie", "Citeren", enz. Alle sjablonen zijn hetzelfde soort generieke item.
Er is één belangrijke uitzondering: sommige wiki's hebben de knop "Refereer", die voetnoten met referentiesjablonen invoegt. Het is echter de uitzondering die de regel bewijst. Het vereist handmatige configuratie zelfs voor basisfunctionaliteit, deze configuratie is afzonderlijk in elke wiki en als gevolg daarvan hebben veel wiki's deze knop helemaal niet. Een vergelijkbare uitzondering, die eind 2019 werd toegevoegd, is speciale ondersteuning voor sjablonen voor het melden dat bronvermelding nodig is, maar dit vereist ook een aangepaste configuratie op elke wiki om daadwerkelijk te werken.
Moeilijkheden voor redacteuren die in meer dan één project schrijven
Er bestaan veel sjablonen in het ene project, maar niet in een andere, en vaak is er een sjabloon beschikbaar, maar in een andere vorm. Hierdoor is het moeilijk of onmogelijk om vaardigheden die in één project zijn opgedaan opnieuw te gebruiken: de functionaliteit die het sjabloon biedt, is soms niet beschikbaar en soms werkt het anders. Dit geldt niet alleen voor wiki's in verschillende talen, maar ook voor verschillende wiki's in dezelfde taal, bijvoorbeeld de Engelse Wikipedia en de Engelse Wikisource.
Voor mensen die in verschillende talen bewerken, maken sjablonen het vertalen moeilijker. Bij het vertalen van een pagina zijn sjablonen veel moeilijker te hanteren dan de artikeltekst ("proza"), of de vertaling nu handmatig of met inhoudsvertaling wordt gedaan. Gebruikers moeten het sjabloon vaak overslaan of corrigeren nadat het artikel is gepubliceerd. Dit zorgt er ook voor dat lopende vertalingen worden gestopt, omdat sjabloonvertaling er intimiderend uitziet.
De meest gemelde problemen in Content Translation hebben betrekking op sjablonen.
'Content Translation' heeft een sjabloonaanpassingsfunctie, die sommige delen van dit proces automatiseert, maar het werkt alleen als er een overeenkomstige sjabloon in beide talen bestaat en als alle parameters zorgvuldig zijn toegewezen door de sjabloonbeheerders. Dit moet voor elke sjabloon in elke taal afzonderlijk en handmatig worden gedaan en continu worden onderhouden wanneer het bron-sjabloon wordt gewijzigd. Dit gebeurt ook al is de functie van de sjablonen in de talen meestal hetzelfde.
Idealiter zouden de sjablonen en hun parameters bijna volledig automatisch naar de vertaalde pagina moeten worden overgebracht, zodat de vertalers zich kunnen concentreren op het schrijven van het proza, omdat het schrijven van het proza het gebied is waar menselijk werk het meest nodig is.
Een sjabloon kan van de ene wiki naar de andere worden geëxporteerd, maar zodra dit is gebeurd, wordt het sjabloon een gevorkte kopie. Het blijft ofwel in de staat waarin het werd geëxporteerd, of blijft afzonderlijk worden ontwikkeld, waardoor incompatibiliteit ontstaat. Soms blijven mensen de verschillende kopieën onderhouden, maar dit is niet robuust en kan niet worden geschaald voor de honderden wiki's die we hebben.
Sjabloonparameters kunnen dezelfde functionaliteit hebben, maar verschillende namen in verschillende wiki's. Ze kunnen worden aangepast met behulp van TemplateData-aliassen, maar dit is een suboptimale hack: het is niet waar TemplateData oorspronkelijk voor is gemaakt en het moet handmatig worden gedaan voor elk talenpaar.
Sjablonen combineren algoritmische logica, door mensen leesbare tekstreeksen en opmaak. Hierdoor is er geen robuuste manier om de gebruikersinterfacestrings van de sjablonen te vertalen, zoals het wordt gedaan met MediaWiki-kern en extensies.
Moeilijkheden voor redacteuren in kleinere wiki's
Een nieuw wikiproject wordt gemaakt door de kern van MediaWiki te installeren en een standaardset extensies in te schakelen. In de praktijk creëert dit geen gelijk speelveld omdat veel belangrijke functies van grotere wiki's zijn geïmplementeerd in sjablonen: infoboxen, citaten, onderhoudshatnotes (zoals {{Niet-gerefereerd}}), enz.
Moeilijkheden voor softwareontwikkelaars
Het is moeilijk voor ontwikkelaars van MediaWiki-kern, extensies, bots en andere hulpmiddelen die wikipagina-inhoud analyseren, genereren of wijzigen om functies te bouwen die afhankelijk zijn van de aanwezigheid van bepaalde sjablonen in een wiki. Ontwikkelaars van extensies zoals GrowthExperiments, PageTriage, ContentTranslation, sommige componenten van Wikibase en vele anderen, moeten ze ofwel in productie testen, wat een slecht idee is, of de sjablonen importeren in hun lokale wiki's of een online testwiki.
Onderzoekers die gegevens over wiki-inhoud krijgen op basis van sjablonen, moeten hun analysecode voor elke wiki afzonderlijk schrijven, en soms doen ze dat voor slechts één wiki. Een opmerkelijk voorbeeld is het gebruik van de WikiProject-sjablonen van de Engelse Wikipedia om paginaonderwerpen te analyseren en de kwaliteit van het artikel te beoordelen. {{🌎🌍🌏}}
Aannames
Extensies versus sjablonen: overeenkomsten en verschillen
Een van de belangrijkste aannames van dit projectvoorstel is dat sjablonen en modules erg lijken op de kern en extensies van MediaWiki: ze zijn software en ze implementeren functies die de editorsgemeenschap nodig heeft. Met name omdat sjablonen meestal door de redactie zelf worden ontwikkeld, is het duidelijk dat de gemeenschap ze echt nodig heeft. De grote verschillen tussen hen liggen in de manier waarop ze worden ontwikkeld, gelokaliseerd en ingezet.
Sjablonen en modules moeten vergelijkbaar worden met extensies in sommige belangrijke eigenschappen die ze momenteel missen, en een aantal goede eigenschappen behouden die extensies missen. (Voor het gemak van het begrip voor lezers, in de tabel, worden voorbeelden van sjablonen gegeven van de Engelse Wikipedia. Ze kunnen ook afkomstig zijn van elke andere wiki en elke andere taal.)
| Eigenschap | Core en extensies | Sjablonen | Wat moet hieraan gedaan worden met sjablonen? |
|---|---|---|---|
| Implementeer speciale soorten inhoud | Ja.
afbeelding, wiskunde, hiërogliefen, score, basis ref |
Ja. | |
| └ Speciaal soort inhoud is eenvoudig in te voegen in pagina's | Ja (via de werkbalk). | Nee (tenzij u heeft geleerd hoe u het moet doen). | Moet worden veranderd. |
| └ Speciaal soort inhoud is eenvoudig aan te passen voor mobiele apparaten. | Meestal ja. | Soms. | Moet worden veranderd. |
| └ Speciaal soort inhoud is eenvoudig te vertalen als onderdeel van een artikel | Meestal ja. | Nee. | Moet worden veranderd. |
| Implementeert pagina opmaakfuncties | Ja.
gallery, poem |
Ja. | |
| Implementeer workflowprocessen voor gemeenschappen | Ja.
Misbruikfilter, Gebruikerscontrole, Verplaatsen |
Ja. | Moet gemakkelijk te hergebruiken zijn, maar niet afgedwongen. |
| Eenvoudig te implementeren eerste versie | Nee. | Ja. | Moet worden bewaard. |
| Eenvoudig wijzigingen te implementeren | Nee. | Ja. | Moet worden bewaard. |
| Eenvoudig te localiseren | Ja. | Nee. | Moet worden veranderd. |
| Bruikbaar op meerdere wiki's. | Vaak. | Vaak. | |
| Alleen gebruikt op een beperkt aantal wiki's | Soms. | Soms. | |
| Eenvoudig te installeren en te gebruiken op meerdere wiki's | Ja. | Nee. | Moet worden veranderd. |
| Eenvoudig te gebruiken op een nieuwe, recent gemaakte wiki | Ja. | Nee. | Moet worden veranderd. |
Vaardigheden voor het ontwikkelen van sjablonen en modules
Andere belangrijke aannames waarop dit voorstel is gebaseerd, zijn de volgende:
- De vaardigheden voor het ontwikkelen van sjablonen en modules zijn niet triviaal. Zowel sjablonen als modules hebben tal van obscure functies.
- Hoewel veel van de meest opvallende functies van de sites worden geïmplementeerd als sjablonen en modules, worden deze vaardigheden vaak onopgemerkt, ondergewaardeerd en als vanzelfsprekend beschouwd.
- Er zijn tientallen mensen die deze vaardigheden hebben, en ze bewerken veel wiki's. Ze richten zich meestal op hun thuiswiki en communiceren relatief zelden met bijdragers van andere wiki's of andere talen. Hoewel de onderliggende technologie overal hetzelfde is, is er geen echte wereldwijde gemeenschap van sjabloonontwikkelaars die vergelijkbaar zou zijn met de wereldwijde gemeenschap van MediaWiki-kern- en extensieontwikkelaars. Er zijn gevallen van cross-wiki-samenwerking op bepaalde sjablonen, maar ze zijn inconsistent.
- Er zijn ook veel wiki's waarin er geen redacteuren zijn die deze vaardigheden hebben. Ze kopiëren sjablonen en modules van andere wiki's zonder volledig te begrijpen hoe ze werken en zonder de mogelijkheid om ze effectief te lokaliseren en te onderhouden, of ze gebruiken helemaal geen sjablonen.
Deze situatie is verre van optimaal. De vaardigheden van de sjabloon- en moduleontwikkelaars hebben meer waardering nodig. Ze ontwikkelen echt benodigde functies en ze zijn ingebed in hun editorscommunity's. In wiki's in vele talen komen de sjabloonontwikkelaars met innovatieve functies voor gestructureerde inhoud, gegevenspresentatie en modularisering. Deze innovaties zouden nuttig kunnen zijn in veel wiki's, maar momenteel is er geen handig mechanisme om dit te bereiken.
En natuurlijk moet elke oplossing voor deze problemen niet komen met nieuwe technologieën die de vele jaren praktijkervaring die de sjabloonbeheerders hebben opgedaan, zullen weggooien. Daarom moeten er zo min mogelijk wijzigingen zijn in de syntaxis voor het ontwikkelen van sjablonen en modules. De dingen die moeten veranderen, zijn de manier waarop ze worden geïmplementeerd en verspreid over wiki's, en de manier waarop de door mensen leesbare tekenreeksen erin worden gelokaliseerd (vertaald). {{🌎🌍🌏}}
De voorgestelde oplossing: Samenvatting
Er zijn al veel functies van MediaWiki die globaal zijn op wiki's:
- afbeeldingen (via Commons)
- blokkeren
- gebruikersaccounts (CentralAuth)
- voorkeuren
- gebruikerspagina's
- gebruikerspagina's JavaScript en CSS
- Globale volglijst is vanaf eind 2020 actief in ontwikkeling (GlobalWatchlist)
- en enkele andere.
Het moet ook mogelijk zijn om sjablonen en modules op te slaan in een globale repository en ze net zo robuust te lokaliseren als met extensies.
Sjabloonbeheerders in alle wiki's zullen door globale sjablonen en modules gemakkelijker kunnen samenwerken bij het ontwikkelen van de code van de sjablonen.
De vertalers kunnen zich concentreren op het vertalen van alleen de tekenreeksen van de gebruikersinterface ("berichten"), zonder te hoeven zoeken naar tekenreeksen in de code, en door hen in staat te stellen dezelfde vaardigheden en hulpmiddelen te gebruiken voor het vertalen van sjablonen en MediaWiki-extensies.
Inhoudseditors in alle wiki's zullen in staat om inhoud te schrijven en te vertalen die deze sjablonen gebruikt zonder in de verschillen te hoeven duiken en om verschillende regels en vaardigheden in elke wiki opnieuw te leren.
De syntaxis voor het ontwikkelen van sjablonen en modules en de algemene sjabloononderhouds- en implementatiecyclus zullen niet veranderen, dus alle vaardigheden die de sjabloononderhouders in de loop der jaren hebben verworven, blijven relevant.
Alle wiki's kunnen de globale sjablonen gebruiken, maar worden niet gedwongen om dit te doen. Gemeenschappen behouden hun mogelijkheid om alle globale functionaliteit, ontwerp, workflows en gegevens te negeren.
Het lokaliseren van sjablonen wordt net zo handig als het lokaliseren van MediaWiki-extensies. {{🌎🌍🌏}}
De voorgestelde oplossing: Gedetailleerde vereisten
Sjablonen moeten semantisch en globaal kunnen zijn
Semantisch betekent dat andere softwarecomponenten, met name Visual Editor en Content Translation, een algemene manier moeten hebben om te begrijpen dat een sjabloon bestaat en dat het bepaalde functionaliteit biedt, zodat het mogelijk is om het in een pagina in te voegen als een infobox, een citaat, een onderhoudstag, enz., En niet alleen als een generieke sjabloon. Nu komt TemplateData het dichtst in de buurt van het semantisch maken van sjablonen, maar het beschrijft alleen de parameters van het sjabloon. Het helpt Visual Editor bijvoorbeeld niet om een knop "Infobox invoegen" aan de werkbalk toe te voegen.
Globaal betekent dat de code van een sjabloon op één plaats moet worden onderhouden en bruikbaar moet zijn in alle wiki's.
Sjablonen semantisch maken
Sjablonen zijn nooit robuust semantisch geweest, in de zin dat ze gemakkelijk te hanteren zijn door software die pagina's verwerkt.
Er zijn slechts enkele voorbeelden van sjablonen die semantisch zijn gemaakt:
- Verschillende referentiesjablonen, die bruikbaar zijn via de knop op de Visual Editor-werkbalk "Refereer". Ze vereisen het schrijven van veel afzonderlijke code om Citoid te configureren op elke wiki die ze wil gebruiken.
- "Citation needed", dat eind 2019 werd aangepast naar Visual Editor. Het vereist ook configuratie op elke wiki. Bijvoorbeeld: Engels, Hebreeuws, Sloveens. Op het moment van schrijven zijn Frans, Spaans en de meeste andere talen hier niet voor geconfigureerd, ook al hebben ze dit soort sjablonen. (taak T211243)
- Sjablonen voor het vermelden van gebruikers in de extensie Flow, die ook lokale configuratie vereisen.
- Sommige dumpverwerkings- en onderzoekshulpmiddelen kunnen de WikiProject-beoordelingssjablonen van de Engelse Wikipedia parseren, die meestal worden toegevoegd aan overlegpagina's.
- De extensie GrowthExperiments stelt editors voor om bepaalde taken in artikelen uit te voeren op basis van de sjablonen die erin zijn opgenomen. De sjabloonnamen moeten handmatig worden geconfigureerd door JSON-bestanden afzonderlijk in elke wiki te schrijven. Bijvoorbeeld: Tsjechisch, Vietnamees, Koreaans, Arabisch.
- De extensie PageTriage is geconfigureerd om te werken met de hatnote-sjablonen van de Engelse Wikipedia (ook bekend als "tags").
In het geval van PageTriage codeert de extensie in wezen de sjablonen van een enkele wiki, waardoor deze onbruikbaar wordt in andere wiki's zonder een significante herschrijving. Zelfs als de on-wiki configuratiestap klein is, zoals bij Flow, moet het nog steeds worden gedaan. Dit schaalt niet goed voor de 900 wiki's die Wikimedia heeft, en de duizenden die het in de toekomst zal hebben.
Deze dingen moeten standaard globaal zijn, zodat ze onmiddellijk bruikbaar zijn in ten minste een eenvoudige standaardconfiguratie op alle wiki's tegelijk door extensies, bots, dumpanalyzers, enz.
Opslag en levering
De globale templates en modules kunnen worden opgeslagen in een centrale wiki (Meta, Commons of een geheel nieuwe wiki), en het kan zelfs Gerrit of een andere repository zijn.
De beste oplossing is waarschijnlijk het maken van een nieuwe wiki die ze opslaat, zonder verward te raken met afbeeldingen, algemene gemeenschapsdiscussie, enz.
Het gebruik van Gerrit als opslag voor templates en modules code is technisch mogelijk, maar het zou een belangrijk element van toegankelijkheid voor sjabloononderhouders verliezen: het bewerken van een sjabloon in een wiki-pagina is veel makkelijker en vertrouwd voor de overgrote meerderheid van de sjabloononderhouders dan het maken van Git commits en het wachten op code review. Daarom moet Gerrit waarschijnlijk niet gekozen om de sjabloon en modulecode op te slaan, althans niet de primaire.
Algemene sjablonen en modules moeten worden opgeslagen in een gemeenschappelijke repository die door de meeste wiki-editors kan worden bewerkt. Regels over blokkeren en speciale machtigingen moeten in eerste instantie vergelijkbaar zijn met de regels in andere wiki's: alles moet standaard open zijn en het moet mogelijk zijn om zeer gebruikelijke, gevoelige of vaak vernielde sjablonen te beschermen. Meer gedetailleerde regels over beschermingsniveaus kunnen later door de redactiegemeenschap worden ontwikkeld.
De code van de sjablonen in de centrale repository gebruikt de generieke Engelse namen van tags zoals <section>, parserfuncties zoals {{#ifexist}} of {{#invoke}} en magische woorden zoals {{DISPLAYTITLE}}.
Hoe de sjablonen aan de doelwiki's worden geleverd, is een kwestie van interne engineering en architectuur, zolang de andere vereisten worden aangepakt. Deze vragen werden in het verleden door sommige platformontwikkelaars besproken, bijvoorbeeld rond het project Shadow namespaces. Dit document probeert gerelateerde vragen te beantwoorden over hoe het werkt voor de gebruiker die een pagina bewerkt die een sjabloon gebruikt, of die het sjabloon zelf onderhoudt, hoe deze op een lokaliseerbare manier te schrijven; hoe wordt het vertaald; hoe wordt het lokaal aangepast; enz. Deze vragen kwamen onvoldoende aan bod in de eerdere architectuurdiscussies over het onderwerp.
Sjablonen moeten eenvoudig te wijzigen blijven
Een belangrijk kenmerk van hoe sjablonen momenteel werken, is dat ze net als wikipagina's worden bewerkt en onmiddellijk functioneel worden na publicatie zonder beoordeling of implementatie. Dit is enigszins gevaarlijk omdat een slechte bewerking veel pagina's kan verpesten, maar het feit is dat het meestal goed werkt.
Dit gemak moet behouden blijven. Communityleden die sjablonen onderhouden, zullen hoogstwaarschijnlijk de overstap naar een nieuw systeem weigeren waarvoor ze nieuwe vaardigheden moeten leren en elke wijziging door een uitputtende beoordelings- en implementatiefase slepen. Dit betekent waarschijnlijk dat het opslaan van de sjablonen in Gerrit niet gaat werken, tenzij het proces voor beoordeling en implementatie misschien veel eenvoudiger zal zijn dan voor extensies.
Het moet mogelijk zijn om sommige sjablonen niet-globaal te maken
Niet alle sjablonen moeten worden gedwongen om globaal te zijn.
Sommige sjablonen moeten zelfs lokaal zijn omdat ze een functionaliteit implementeren die uniek is voor een bepaalde taal. Door hun aard hoeven dergelijke sjablonen niet te worden vertaald en moet er een manier zijn om zowel menselijke editors als vertaalhulpmiddelen (zoals Content Translation) een hint te geven dat ze niet hoeven te worden aangepast en kunnen worden overgeslagen of vervangen. Dit is een onderdeel van de inspanning om sjablonen semantischer te maken.
Het moet mogelijk zijn om bepaalde functionaliteit of het uiterlijk van een globale sjabloon te overschrijven
Geen enkele gemeenschap zou het gevoel moeten hebben dat een functionaliteit wordt opgelegd door een krachtige externe speler, zoals de Engelse Wikipedia-gemeenschap, de Wikidata-gemeenschap, de WMF of iemand anders. Globale sjablonen moeten worden ontwikkeld en gezamenlijk worden gebruikt voor het algemeen belang. Meestal zou het voor iedereen moeten werken.
Soms hebben sommige gemeenschappen een sterke mening over het willen hebben van bepaalde functionaliteit of ontwerp dat anders zal zijn in hun taal of project, of om een infobox te tonen met informatie die anders is dan wat in andere projecten wordt getoond, of om het helemaal niet te laten zien. De mogelijkheid om dingen lokaal te overrulen, moet vanaf het begin worden toegestaan. (Of beter gezegd, het mag niet worden weggenomen.)
Een globaal sjabloon moet onmiddellijk bruikbaar zijn in elke wiki
Net zoals een globale gebruikerspagina direct beschikbaar is in elke wiki waarin geen lokale gebruikerspagina is, moet elk sjabloon of module die op de globale infrastructuur wordt aangemaakt direct bruikbaar zijn in elke wiki.
Dit mag geen geen extra stappen vereisen, zoals het kopiëren van wikipagina's, het maken van wrappersjablonen met een lokale naam, tussenkomst van de beheerder, urenlang wachten tot caches zijn vernieuwd, enz.
Nadat de centrale versie is bijgewerkt, wordt de bijgewerkte versie onmiddellijk overal weergegeven. Om vandalisme te voorkomen, zal de redactiegemeenschap beleid ontwikkelen over machtigingen en beschermingsniveaus.
Als de tekenreeksen van de gebruikersinterface (ook bekend als "berichten") niet zijn vertaald, is het sjabloon niettemin bruikbaar en worden de tekenreeksen weergegeven in de terugvaltaal. Zie de secties over lokalisatie voor meer informatie.
Lokalisatie van tekenreeksen die de gebruiker ziet
Het moet mogelijk zijn om alle deze tekenreeksen te vertalen
De tekenreeksen (berichten) van de gebruikersinterface van de kern MediaWiki, extensies en sommige externe hulpmiddelen zoals Pageviews worden handig en robuust vertaald op translatewiki.net.
Het is nu niet mogelijk om hetzelfde te doen met sjablonen. Meertalige sites zoals Commons en mediawiki.org hebben het systeem "TNT" voor het vertalen van sommige sjablonen, maar het is erg ingewikkeld en kan niet worden hergebruikt voor Wikipedia, Wikisource, enz. In 2021 werd dit robuuster dankzij de functie "taalbewuste transclusie", maar het heeft nog enkele verbeteringen nodig.
Idealiter zou het mogelijk moeten zijn om sjablonen te vertalen, net als de core en extensies, met behulp van een wiki met de extensie Translate.
De vertaalde tekenreeks moet onmiddellijk bruikbaar worden nadat de vertaling is ingediend met behulp van Translate.
Het kan mogelijk zijn om de tekenreeksen van de gebruikersinterface in onbewerkte wikipagina's te bewerken, maar idealiter moeten ze voornamelijk worden bewerkt via een speciale vertaalinterface.
Vertalers moeten zich kunnen concentreren op het vertalen van niets anders dan tekst. Het zien van code eromheen maakt het moeilijk voor mensen die geen ervaring hebben met programmeren en JSON-bestanden om gemakkelijk bij te dragen. Bovendien is het bewerken van vertalingen in talen die van rechts naar links zijn geschreven in onbewerkte tekstbestanden uiterst onhandig. De extensie Translate lost al deze problemen al op.
De sjabloondocumentatiepagina's moeten ook vertaalbaar zijn. Het is meestal voldoende om het te doen met behulp van de paginavertalingsfunctie van de extensie Translate, maar het kan enkele aanpassingen vereisen.
De taal waarin de tekenreeksen aan de gebruiker worden getoond
Sjablonen worden voornamelijk gebruikt wanneer ze zijn geïntegreerd in inhoud, dus standaard moeten de vertaalde berichten worden weergegeven in de inhoudstaal van de wiki.
Sommige sjablonen worden echter gebruikt als UI-elementen. Daarom is het misschien zinvol om ook het tonen van de vertaalde tekenreeksen in de gebruikerstaal toe te staan, wanneer deze verschilt van de wiki-inhoudstaal. Dit kan met name relevant zijn voor meertalige sites zoals Commons, Wikidata, Meta en mediawiki.org.
MediaWiki's gebruikelijke terugval ketens moeten worden gebruikt wanneer een vertaling niet beschikbaar is. Als een bericht bijvoorbeeld niet in het Quechua of Guarani is vertaald, wordt het in het Spaans weergegeven, als het niet in het Basjkiers of Tsjoevash is vertaald, wordt het in het Russisch weergegeven, enzovoort. De ultieme terugvaltaal is Engels, dus als dit bericht niet in het Spaans of Russisch is vertaald, wordt het in het Engels weergegeven.
Berichten keys
Berichten moeten worden weergegeven als keys, vergelijkbaar met hoe het wordt gedaan wordt in MediaWiki core, extensies en hulpmiddelen.
Het schrijven van vertaalbare tekenreeksen zal waarschijnlijk de grootste verandering zijn in het sjabloonontwikkelingsproces waaraan sjabloononderhouders moeten wennen. Hardgecodeerde tekenreeksen moeten worden gescheiden en verplaatst naar berichten die op key zijn geordend. Het moet zo gemakkelijk mogelijk worden gemaakt, niet alleen voor de vertalers, maar ook voor de sjabloonbeheerders. Anders zullen ze het niet echt doen en zal de functie effectief worden afgewezen.
Om keys eenvoudig globaal uniek te maken, is het waarschijnlijk goed om de algemene sjabloonnaam automatisch op te nemen in de berichtsleutel.
Overgangshulpmiddelen
Er moet een hulpmiddel worden ontwikkeld die helpt bij de overgang van een sjabloon of een module naar centrale opslag. Het kan de volgende stappen uitvoeren:
- Exporteer een sjabloon uit een lokale wiki en importeer deze in de globale wiki.
- Exporteer alle sjablonen die door dit sjabloon worden gebruikt (recursief).
- Identificeer de door mensen leesbare tekenreeksen, converteer ze naar een lijst met keys en vervang ze door deze keys in de broncode van het sjabloon.
- Importeer de documentatiepagina van het sjabloon en de TemplateData.
- Importeer de benodigde CSS-pagina's.
In de meeste gevallen kan dit automatische proces waarschijnlijk geen volledig bruikbaar en robuust sjabloon of module maken, maar het kan helpen het overgangsproces te starten.
Berichten organiseren
De extensie Translate organiseert berichten op groepen, ook bekend als "projecten", die verder kunnen worden georganiseerd door geaggregeerde groepen. Article Placeholder, Score en Poem zijn bijvoorbeeld allemaal groepen die de bijbehorende extensies vertegenwoordigen, en ze zijn allemaal opgenomen in de geaggregeerde groep "Extensies gebruikt door Wikimedia - Geavanceerd", samen met vele andere extensies.
Projecten die MediaWiki-extensies vertegenwoordigen, worden geconfigureerd in YAML-bestanden in de translatewiki-repository en weergegeven in de Translate-gebruikersinterface in een projectkiezer, ook bekend als "message group selector".
Aangezien er veel meer sjablonen dan extensies zijn, kunnen er enkele wijzigingen nodig zijn in de manier waarop de extensie Translate berichtgroepen verwerkt om sjablonenvertaling mogelijk te maken.
Elke sjabloon moet een berichtengroep zijn. Nauw verwante sjablonen moeten worden gegroepeerd in een samengevoegde berichtengroep. Ze kunnen vergelijkbaar zijn met de categorieën waarin ze zijn opgeslagen, en in feite kunnen de categorieën zelfs worden hergebruikt. Het bewerken van bestanden in een Git-repository om deze berichtgroepen te organiseren is waarschijnlijk niet wenselijk, omdat het te complex en traag is.
Het zou leuk zijn om groeps- en sjabloonnamen weer te geven als gelokaliseerd in de selector, maar het is ook OK als ze in het Engels worden weergegeven. Als het goed genoeg is voor extensielokalisaties, is het ook goed genoeg voor sjabloonlokalisaties.
Sjablonen moeten als berichtgroepen worden weergegeven op de speciale pagina Taalstatistieken van de extensie Translate (Special:LanguageStats). Dit helpt vertalers te vinden welke sjablonen moeten worden vertaald. Dit moet over het algemeen vergelijkbaar zijn met alle berichtgroepen, maar er zijn enkele speciale overwegingen voor sjablonen:
- Er zullen duizenden sjablonen zijn, dus het zal leuk zijn als het ontwerp van de tabel hier op de een of andere manier mee overeenkomt.
- De tabel moet laten zien op hoeveel pagina's elke sjabloon is getransclude en het mogelijk maken om de rijen op dit nummer te ordenen, om lokalisaties te helpen prioriteit te geven aan wat belangrijker is om te vertalen.
Hoe een sjabloon te vertalen
Elke sjabloonbeschrijvingspagina moet een directe link hebben om deze te vertalen naar de taal van de gebruiker.
Sommige sjablonen gebruiken Wikidata-labels als onderdeel van hun gebruikersinterface in plaats van hard-gecodeerde strings. Dit gebeurt op dit moment in o.a. Wikidata Infobox op Commons en Infotaula persona (Infobox persoon) in de Catalaanse Wikipedia. Deze labels en waarden kunnen worden gelokaliseerd in Wikidata zelf. Een dergelijk gebruik kan niet alle behoeften van sjabloonlokalisatie dekken, maar het is legitiem en nuttig voor bepaalde doeleinden. Zolang dit goed wordt beschreven in de sjabloondocumentatie, kan dit blijven worden gebruikt en zijn er waarschijnlijk geen speciale infrastructuuraanpassingen nodig. (Misschien kan de vertaling van de relevante labels en waarden op de een of andere manier worden geïntegreerd in de Translate-interface voor het lokaliseren van de sjabloon, maar dit is optioneel.)
Berichtparameters en magische woorden
In de kern MediaWiki en extensies hebben veel berichten parameters, ook bekend als "placeholders". Ze heten $1, $2, enz., En ze worden runtime ingevuld. Parameters zijn vooral belangrijk om berichten robuust vertaalbaar te maken, omdat verschillende talen een verschillende woordvolgorde hebben.
Zoiets is ook nodig in sjablonen, hoewel het mogelijk is dat het formulier niet $1, $2 hoeft te zijn, maar sjabloonachtige parameters met drievoudige accolades ({{{}}}). Dit moet worden bepaald op basis van overwegingen van parsering en lokalisatiegemak.
De magische woorden PLURAL, GENDER en GRAMMAR moeten worden ondersteund in sjabloonberichten zoals in MediaWiki-berichten.
Berichten documentatie
In de kern MediaWiki en extensies wordt elk vertaalbaar bericht gedocumenteerd voor het gemak van ontwikkelaars en vertalers. De documentatie kan informatie bevatten over waar het bericht verschijnt, wat de $1, $2, enz. parameters zijn, of het woord een werkwoord of een bijvoeglijk naamwoord is, enz. Deze documentatie wordt opgeslagen als pseudo-taal met de code qqq.
Dergelijke documentatie zal ook nuttig zijn voor sjabloonvertaling. Hoe het wordt opgeslagen is een kwestie van technische architectuur. Misschien kan het worden gecombineerd met TemplateData, misschien kan het worden opgeslagen als een qqq-taal en misschien kan het iets anders zijn.
Brontaal
Sjablonen worden niet alleen geïmporteerd uit Engelstalige projecten, maar ook uit wiki's in vele talen. Meer dan ooit moeten de lokalisatiehulpmiddelen vertaling vanuit elke taal ondersteunen en niet alleen vanuit het Engels.
Fuzzying
In kern MediaWiki en extensies en in vertaalbare pagina's, als het bronbericht in het Engels verandert, wordt het bericht automatisch gemarkeerd als verouderd of "fuzzy". De bestaande vertalingen blijven werken, maar worden aan vertalers getoond dat ze een update nodig hebben. (De vertaalmanager kan ook markeren dat een bericht niet opnieuw hoeft te worden vertaald als het bijvoorbeeld het verhelpen van een taalfout in het Engels was.)
Een soortgelijk mechanisme is nodig voor sjabloonlokalisatie. Omdat het echter leuk zou zijn om Engels niet als brontaal te forceren, zouden er meer manieren moeten zijn om berichten als fuzzy te markeren.
Lokalisatieoverwegingen voor modules
Lua-modules kunnen vertaalbare MediaWiki-tekenreeksen laden en parseren, maar er is geen gedefinieerde manier om deze tekenreeksen op te slaan voor Lua-modules die worden onderhouden als wikipagina's. Het is mogelijk om Lua-modules te verpakken als onderdelen van extensies en vervolgens kunnen ze berichten laden van de i18 / *.json-bestanden van de extensies, maar dit wordt op dit moment in zeer weinig extensies gedaan. Het herschrijven van sjablonen in Lua kan vanuit technisch oogpunt een robuustere oplossing zijn, maar Lua zal niet noodzakelijkerwijs door alle bestaande sjabloonbeheerders worden omarmd en hun samenwerking zal cruciaal zijn voor het succes van het project, dus dit kan niet voor alle sjablonen worden gedaan.
Sommige zeer interne, technische modules die vaak worden gebruikt, zelden worden gewijzigd en geen internationalisering vereisen, kunnen waarschijnlijk pijnloos naar de Scribunto-extensie zelf worden verplaatst. Enkele voorbeelden zijn Module:No globals en Module:Arguments.
De sjabloonnaam vertalen
De sjabloon kan in elke taal een andere naam hebben, maar moet rechtstreeks verbonden zijn met de centrale repository.
Globale sjablonen en modules moeten onmiddellijk bruikbaar zijn in alle wiki's zonder extra stappen, dus het moet mogelijk zijn om een globaal sjabloon in een lokale wikipagina te transcluderen met behulp van de algemene naam. De cross-wiki editors gemeenschap zal beslissen wat het beleid zal zijn voor deze globale namen.
Net als parameternamen kunnen sjablonen verschillende namen in verschillende talen hebben en dit moet worden bewaard. Er moet een gestructureerde manier zijn om sjabloonnamen te vertalen. Misschien kunnen Wikidata-sitelinks een rol spelen, maar dat hoeft niet.
Als dit niet gebeurt, zullen editors algemene sjablonen vermijden of de algemene sjabloon in een lokale sjabloon met een vertaalde naam verpakken, waardoor de sjabloon waarschijnlijk de verbinding met de globale entiteit verliest. Dit is niet wenselijk en mist het hele punt van het project.
Sjabloonnamen mogen alleen worden vertaald naar talen die inhoudstalen van wiki's kunnen zijn. Vertaling naar formeel Duits of Brits Engels is waarschijnlijk niet nodig. Er kan een manier zijn om aliassen of doorverwijzingen te hebben. Taalvarianten, bijvoorbeeld voor Servisch en Chinees, moeten worden ondersteund op basis van de behoeften van deze talen.
Als een lokale sjabloon in een wiki bestaat en dezelfde naam heeft als een gelokaliseerde naam van een algemene sjabloon, wordt het lokale sjabloon gebruikt. Dit is vergelijkbaar met hoe lokale bestanden met identieke namen globale bestanden op Commons overschrijven en hoe lokale berichten in de MediaWiki-ruimte de lokalisatie van de code overschrijven.
Lua-modulenamen zijn ook vaak gelokaliseerd. Hun namen kunnen worden gelokaliseerd voor direct aanroepen vanaf wikipagina's, maar aangezien code meestal Engels-achtige id's gebruikt, moeten de interne algemene namen waarschijnlijk de voorkeur krijgen voor gebruik in de code zelf, bijvoorbeeld in require-instructies.
Paremeters vertalen
Parameternamen vertalen
Parameternamen zijn in elke taal anders. Ze zijn meestal gebaseerd op woorden in elke taal, dus het is belangrijk om de transclusie in wiki-syntaxis gemakkelijk te bewerken.
Idealiter zou het algemene sjabloon generieke interne parameternamen moeten hebben die vertalingen naar verschillende talen hebben. Dit is enigszins vergelijkbaar met Wikidata-eigenschaplabels, maar het kan eenvoudiger zijn: aangezien Engels een lingua franca is voor softwareontwikkelaars en sjablonen een soort software zijn, is het waarschijnlijk OK om Engels als de standaard brontaal te hebben in plaats van generieke nummers zoals in Wikidata.
Deze algemene parameternamen zijn de algemene standaardnamen. Ze zullen werken in wiki's in alle talen. De gelokaliseerde namen werken in de wiki's die die taal als inhoudstaal hebben.
De vertalingen van parameternamen moeten worden gevalideerd:
- ze mogen geen ongeldige tekens bevatten
- ze mogen niet worden herhaald binnen één sjabloon in één taal
- Nog iets?
Het eigenlijke proces van het vertalen van de parameternamen kan verschillen van het vertalen van tekenreeksen in de gebruikersinterface. Deze namen hebben technische beperkingen die moeten worden afgedwongen. Ze moeten ook stabiel blijven omdat het wijzigen van een parameternaam bestaande transclusies zal breken, dus er moeten enkele waarborgen zijn om ze niet te vaak te wijzigen.
Automatische parametervertaling
Als alle gelokaliseerde sjabloon- en parameternamen centraal worden opgeslagen, is het mogelijk om een eenvoudige service te hebben die een geldige sjabloonaanroep met parameters, een brontaalnaam en een doeltaalnaam ontvangt en een gelokaliseerde sjabloonaanroep uitvoert. Bijvoorbeeld:
Invoer:
{
sourcewiki: "enwiki",
targetwiki: "frwiki",
template: "{{Infobox writer|name=Ľudovít Štúr|birth_date=1815-10-28}}"
}
Uitvoerː
{
template: "{{Infobox Écrivain|nom=Ľudovít Štúr|date de naissance=1815-10-28}}"
}
In Content Translation, is dit de belangrijkste manier om sjablonen aan te passen. In tegenstelling tot de huidige sjabloonaanpassing in Content Translation, zal deze nauwkeurig en volledig zijn, in plaats van gebaseerd op gissingen.
Bij visuele bewerking en in 2017-stijl wiki-syntaxisbewerking wordt de parametervertaling automatisch uitgevoerd door simpelweg een sjabloon van wiki in een andere taal te kopiëren en te plakken.
Voor het bewerken van gewone wiki-syntaxis moet er een eenvoudige manier zijn om deze service te bedienen, bijvoorbeeld een speciale pagina of een dialoogvenster waarin een editor de sjabloon en de brontaal kan plakken en de sjabloon met vertaalde parameters kan krijgen.
In beide gevallen worden alleen de namen van de sjabloon en de parameters vertaald. Het vertalen van de parameterwaarden wordt apart besproken.
Parameters zonder een naam
Naamloze genummerde parameters moeten natuurlijk blijven werken.
Er moet een beslissing worden genomen over hoe hun namen worden vertaald.
Parameterwaarden vertalen
Naast het delen van de functionaliteit en het ontwerp van de sjablonen moet er ook nagedacht worden om de parameters van het sjabloon te delen, evenals over het "niet" delen.
Sommige parameters zijn van nature in alle talen hetzelfde. Voorbeelden zijn een IPA-uitdrukking van de moedernaam van een plaats (bijv. [dɛn ˈɦaːx] voor Den Haag), het jaar van het stichten van een stad, de chemische formule van een verbinding, enz. Ten minste een deel hiervan moet waarschijnlijk worden opgeslagen in Wikidata en gemakkelijk worden geladen in een sjabloon.
Sommige parameters moeten worden vertaald of in een ander alfabet worden gezet, bijvoorbeeld de namen van mensen, vertalingen van motto's van landen, enz.
Globale sjablonen moeten dit mogelijk maken, maar in de praktijk worden deze dingen nog steeds vaak over wiki's gekopieerd, en moet hiermee ook rekening worden gehouden.
Sommige parameterwaarden kunnen op betrouwbare en voorspelbare wijze automatisch worden omgezet, en de globale sjabloon-infrastructuur moet dit ondersteunen. Bijvoorbeeld, de getallenformaten en cijfertekens zijn vaak anders in het Birmaans, in de talen van India en in sommige andere talen, maar ze kunnen betrouwbaar worden omgezet met behulp van eenvoudige software.
Geldige en functionele parametewaarden moeten in meerdere talen gebruikt kunnen worden en niet taal-specifiek zijn. Bijvoorbeeld, het gebruik van "yes" en "no" als boolean waarden is te Engels. Dit vereist waarschijnlijk geen veranderingen in de infrastructuur, maar meestal een overeenkomst in de cross-wiki sjabloon ontwikkeling gemeenschap over goede praktijken voor aanpassing aan alle talen.
Tekstrichting
Sjablonen moeten zich aanpassen aan de tekstrichting (ltr / rtl) van de wiki waarin ze worden weergegeven.
Het moet handig zijn om een sjabloon op een richtingsneutrale manier te schrijven, met zo min mogelijk expliciete rechtse en linkse uitlijning.
Bots
Veel sjablonen in veel wiki's worden regelmatig bewerkt door bots. Deze mogelijkheid moet blijven bestaan.
Dit is niet bedoeld om wijzigingen in de software-infrastructuur te eisen, maar het wordt hier voor de volledigheid vermeld omdat het een belangrijke use-case is.
Verplaatsing van de sjablonen van de grote wiki's naar de centrale repository
De meest populaire brontaal voor vertaling in Content Translation is veruit Engels. Daarna volgen Spaans, Russisch, Frans, Duits, Catalaans, Oekraïens, Italiaans, Chinees en Portugees. Om deze reden is het logisch dat de gemeenschappelijke sjablonen in de edities van Wikipedia in deze meest voorkomende talen, vooral die in het Engels, de belangrijkste zijn om globaal te maken ten behoeve van alle andere talen.
Het is echter enigszins paradoxaal dat de redacteuren in deze grootste talen ook het minst geïnteresseerd zijn in het globaal maken:
- De sjablonen werken al goed voor hen, en de meeste mensen daar geven niet direct om het gemak van vertaling naar andere talen.
- Het omschrijven van de sjablonen zodat de teksten vertaalbaar zijn kan tijdrovend zijn en kan hen dwingen om nieuwe vaardigheden te leren bij het onderhouden van sjablonen.
- Als de sjablonen plotseling door veel meer projecten worden gebruikt, kan het moeilijker worden om consensus te bereiken over het aanbrengen van toekomstige wijzigingen in de manier waarop de sjablonen werken.
- Redacteurs van verschillende grote wiki's zullen moeten werken aan het bereiken van consensus over het samenvoegen van enkele sjablonen met vergelijkbare functionaliteit die al op hun sites bestaan.
Dit is meer een overweging van de praktische werking en de gemeenschapsbetrekkingen dan een overweging van de techniek, maar deze moet in aanmerking worden genomen bij het nemen van technische architectonische beslissingen. Zonder een goede voorbereiding op dit gebied zal het hele project falen.
Zolang er belangrijke gemeenschappelijke sjablonen zijn die niet globaal zijn, moeten Content Translation en andere software die sjablonen van verschillende wiki's op welke manier dan ook behandelt, ze blijven ondersteunen. Als de infrastructuur voor globale sjablonen wordt gecreëerd en de migratie van bestaande sjablonen in een goed tempo verloopt, kunnen ontwikkelaars overwegen de ontwikkeling te stoppen en op een dag de code voor niet-globale aanpassing van de sjablonen te laten ontraden.
Het tempo van het migreren van sjablonen van grote wiki's naar een centrale repository kan een van de succesfactoren van het project zijn.
Het moet mogelijk zijn om sjablonen volledig te gebruiken in zowel wiki syntaxis als in visuele bewerking
Het is duidelijk, maar moet toch worden vermeld: het bewerken van Wiki syntaxis gaat niet snel weg, en het moet mogelijk blijven om sjabloon transclusies in pagina's te bewerken zoals nu. Dit mag niet ingewikkelder worden.
Visual Editor wordt echter steeds vaker omarmd door zowel ervaren als nieuwe redacteurs, dus elk aspect van hoe sjablonen werken moet goed werken in zowel visuele als wiki syntaxis bewerking.
Andere functies met betrekking tot sjablonen
Er zijn enkele functies die met sjablonen in de MediaWiki core en haar extensies omgaan. Alle moeten blijven werken en moeten mogelijk worden bijgewerkt voor de globale sjablonen.
Core MediaWiki
Er moeten on-wiki hulpmiddelen zijn om ten minste basisanalyses van het gebruik van sjablonen en modules op pagina's weer te geven: het aantal transclusies en invocaties gegroepeerd per wiki, en lijsten met pagina's die de sjablonen en de modules gebruiken. De functie die laat zien welke sjablonen een pagina transclueert terwijl deze wordt bewerkt, moet blijven werken met globale sjablonen.
De pagina "Verwijzingen naar deze pagina" moet blijven werken en nog steeds nuttig blijven voor globale transclusies.
TemplateData
- Het is mogelijk om sjabloon- en parameterbeschrijvingen te vertalen in TemplateData, de vertalingen worden weergegeven in de taal van de gebruikersinterface in het dialoogvenster voor het invoegen van sjablonen van de visuele tekstverwerker. Dit is goed en moet behouden blijven. De vertaalinterface kan eventueel worden verbeterd, maar het begin is goed. Het toevoegen van ondersteuning voor TemplateData in de extensie Translate kan hiervoor een oplossing zijn, maar er kunnen ook andere oplossingen zijn.
- De parameter "Voorgestelde wikitext-opmaak" (In de regel, Blok, Aangepast) moet blijven werken. Het moet ook mogelijk zijn om ze per wiki aan te passen, sommige wiki's kunnen een bepaald sjabloon zien dat in de wiki-syntax is geschreven als één regel, en sommige kunnen meerdere regels zien.
Citoid
- Citoid moet op elke wiki afzonderlijk worden geconfigureerd met behulp van JSON-bestanden, zoals Citoid-template-type-map.json. In het globale sjablonen tijdperk moet het mogelijk worden om deze bestanden te delen, zodat de knop "Refereer" in alle wiki's beschikbaar zou zijn en overal standaard identiek zou werken. Net als bij sjablonen moet er een manier zijn om deze standaard in elke wiki te overschrijven waar de gemeenschap ander gedrag wil.
TemplateStyles
- Er moet een mogelijkheid zijn om TemplateStyles-pagina's te schrijven in dezelfde centrale repository als sjablonen. De centrale style moet standaard worden geladen en het moet mogelijk zijn om deze lokaal te overschrijven.
TemplateSandbox
- Special:TemplateSandbox moet blijven werken.
- Het moet mogelijk zijn om een sjabloon in de centrale repository te bewerken en te bekijken op een pagina in de doel wiki.
TemplateWizard
- Het huidige systeem gebruikt de standaard zoekopdracht van een wiki om sjablonen te vinden. De resultaten worden in een lijst gepresenteerd die misschien moet worden gewijzigd om de globale of lokale status zichtbaar te maken.
- TemplateWizard krijgt zijn informatie over sjablonen van de API TemplateData, dus zolang dat dezelfde structuur blijft teruggeven, zouden er geen problemen moeten zijn, en i18n werkt al.
Wikibase
- Wikidata kan worden gebruikt om bepaalde parameterwaarden uit een centrale repository naar de wiki te brengen. Dit wordt productief gebruikt in Wikipedia in verschillende talen, waaronder Frans, Hebreeuws, Baskisch, Russisch, Catalaans, Ests en enkele andere, evenals in Commons, hoewel de daadwerkelijke implementatie kan verschillen. Dit moet natuurlijk blijven werken. Het verenigen van de manier waarop het op verschillende wiki's wordt gedaan, kan een van de belangrijkste impactgebieden van dit project worden.
- Het kan ook veel gemakkelijker zijn om de Wikidata Bridge te implementeren, het project om sjabloonwaarden van binnen wiki's te bewerken. De wijzigingen in de sjablonen zelf moeten slechts één keer in de globale sjablonen worden gedaan, en niet in elke wiki.
VisualEditor
- VisualEditor moet natuurlijk zowel globale als lokale sjablonen kunnen toevoegen.
- VisualEditor toont een link naar de beschrijving van het sjabloon in de dialoog voor het bewerken van het sjabloon. Deze link moet direct naar het globale sjabloon wijzen wanneer deze wordt gebruikt.
Ontwikkeling en implementatie
De ontwikkeling van de infrastructuur voor globale sjablonen en modules is een groot en complex project. Het moet in beheersbare delen worden verdeeld om het te kunnen doen. De meerdere onderdelen van dit project moeten in de volgende volgorde worden ontwikkeld:
- Te vertalen modules (in ontwikkeling): Voordat de modules gedeeld kunnen worden tussen wiki's, moet het kader voor hun internationalisering en lokalisatie worden ontwikkeld. Dit zal onmiddellijk nuttig zijn voor modules op wiki's die al meertalig zijn, met name Commons en Wikidata. Sommige van hen worden vertaald met behulp van Lua-arrays of trucs met vertaalbare pagina's, maar dit is geen volledig geïndustrialiseerd lokalisatiesysteem.
- Globale modules: Modules worden gedeeld tussen wiki's. Dit zou moeten gebeuren voordat sjablonen gedeeld kunnen worden omdat de infrastructuur van de modules minder gekoppeld is aan de core van MediaWiki.
- Vertaalbare sjablonen: Dit is vergelijkbaar met de bovenstaande vertaalbare modules en kan veel van hetzelfde framework hergebruiken, maar het zal ook de mogelijkheid nodig hebben om de namen van het sjabloon zelf en de parameters en enkele andere functies te vertalen. Zie de rubrieken over de lokalisatie in de specificatie.
- Globale sjablonen: Voltooi het project met het globaal maken van de sjablonen.
De ontwikkeling van meer geavanceerde functies, zoals het maken van semantische sjablonen, kan en moet later komen, nadat ze gedeeld kunnen worden. Als ze semantisch worden voordat ze gedeeld kunnen worden, zal de code die ze semantisch beschrijft op verschillende wiki's worden gevorkt, zoals de sjablonen zelf, waardoor het hergebruik van code nog moeilijker wordt dan het nu al is.
Toegang tot globale sjablonen en modules is beschikbaar vanaf alle Wikimedia-wiki's. Dit omvat edities van Wikipedia, Wiktionary, Wikivoyage, enz. in alle talen, evenals Commons, Wikidata, Meta, mediawiki.org, Wikitech, enz., evenals test wiki's (test.wikipedia.org, enz.) Dit is vergelijkbaar met hoe afbeeldingen op Commons beschikbaar zijn op alle wiki's. Hoewel de globale sjablonen en modules beschikbaar zijn voor de wiki's, zullen de wiki's niet verplicht worden om ze te gebruiken.
Het maken van sjablonen die gemakkelijk herbruikbaar zijn op niet-Wikimedia-projecten kan ook wenselijk zijn. Hoewel het niet direct ten goede komt aan Wikimedia-projecten, is het misschien logisch om te overwegen sjablonen te maken die niet alleen in Wikimedia-projecten, maar ook op andere MediaWiki-sites, gemakkelijk herbruikbaar zijn. Dit zal waarschijnlijk meer werk vereisen, maar het kan bijdragen aan een betere modularisatie, en dit kan uiteindelijk ook voor Wikimedia-projecten nuttig zijn. Dit is vergelijkbaar met de mogelijkheid om afbeeldingen van Commons direct op niet-Wikimedia-websites te plaatsen. {{🌎🌍🌏}}
Stel eens dat...
Stelt u zich een wereld voor waarin ieder mens vrij kan delen van de som van alle kennis en het is eigenlijk heel gemakkelijk om te doen omdat sjablonen globaal zijn:
| Taak | Met het huidige sjabloonsysteem | Met globale sjablonen |
|---|---|---|
| Een infobox invoegen met behulp van de Visual Editor |
Let op dat u de sjabloonnaam voor elke wiki apart moet vinden, en in sommige wiki's zal het helemaal niet werken. |
Let op dat het bovenstaande op dezelfde manier werkt in elke wiki en in elke taal, tenzij specifiek overschreven. |
| Een infobox in te voegen met behulp van de wiki syntaxis editor |
|
Als u wilt, kunt u nog steeds dezelfde dingen doen als met het huidige sjabloonsysteem.
Maar u heeft ook deze extra optionele functies:
|
| Gebruik een mooi sjabloon dat u hebt gezien in een wiki in het Engels, Frans, Russisch of Spaans in uw taal |
|
Als het sjabloon in de algemene repository staatː
Dat is het, het sjabloon is volledig bruikbaar in uw taal. (En ja, dit moet ook worden herhaald voor elke taal, maar hetzelfde geldt bij MediaWiki-extensies.) |
| Gebruik de nieuwe functies van een mooi sjabloon die u ooit uit een wiki in het Engels, het Frans, het Russisch of een andere taal naar uw taal hebt geëxporteerd | Drie opties:
|
Vertaal de nieuwe teksten. Alle nieuwe functies zijn al beschikbaar in alle wiki's. |
| Implementeren van Wikidata Bridge (bewerken van de gegevens van Wikidata rechtstreeks in infoboxen) | Dit is een project dat nog in een vroeg stadium is. Het is echter waarschijnlijk dat met de huidige technologie het implementeren ervan waarschijnlijk elke infobox sjabloon "in elke wiki" zal moeten veranderen volgens instructies die door Wikidata-ontwikkelaars zullen worden gepubliceerd. | De sjablooncode van de infobox zal slechts één keer moeten worden gewijzigd en het zal werken voor alle wiki's. |
| Vertaal een artikel uit het Engels, Frans of Russisch in uw taal met behulp van Content Translation |
In dit scenario kunnen stappen 4 en 7 langer duren dan stap 3. |
In dit scenario neemt stap 3 de meeste tijd in beslag, stappen 4 en 7 zijn zeer kort en de totale tijd is korter. |
| Kopieer een nuttige citaat van een academisch artikel van de Deense Wikipedia naar de Duitse Wikipedia (of tussen andere twee talen) |
|
In Visual Editor: kopieer en plak zonder te vragen of het zal werken
In de wiki-syntaxis-editor:
(In de wiki-syntax-editor van 2017 kan het sjabloonconversie hulpmiddel waarschijnlijk worden geïntegreerd in de plak-aktie.) |
| Een tabel met de laatste resultaten van de lopende Tour de France in de Wikipedia in uw taal
Dit scenario is gebaseerd op een werkelijke module, Cycling race Het wordt niet gebruikt in de Engelse Wikipedia vanwege meningsverschillen over het ontwerp van de tabellen, maar de gemeenschap lijkt er voor open te staan om het in de toekomst te adopteren na wat aanpassingen. |
|
Bijna alle talen krijgen de hele tafel cadeau, zonder iets te doen. Het werk wordt allemaal gedaan door de mensen die de sjablonen en modules maken, eenmalig voor iedereen, en door de mensen die de gebeurtenissen volgen en de resultaten bijwerken. Een cross-wiki-platform voor de ontwikkeling en lokalisatie van de module en het sjabloon kan de ontwikkeling van een ontwerp die in alle talen aanvaardbaar is, vergemakkelijken. |
| Begin met schrijven in een nieuwe wiki nadat het domein is gemaakt | Na het importeren van de inhoud van Incubator zijn er geen sjablonen voor infoboxen, referenties, gebruikersvakken, discussiebeheer, verzoekpagina's voor samenvoegen of verwijdering, enz.
Kopieer deze sjablonen één voor één of maak uw eigen sjablonen. Mensen van andere wiki's kunnen u helpen, maar ze kennen waarschijnlijk niet uw taal, dus u moet alle teksten handmatig vertalen (zoals in het scenario "Gebruik een leuke sjabloon die u in een wiki in het Engels, Frans, Russisch of Spaans in de wiki in uw taal heeft gezien"). U kunt het ook opgeven en alleen tekst schrijven, maar dan krijgt u minder functies: geen informatievakken, geen geformatteerde citaten, geen verwijdering en samenvoeging van workflow, enz. |
Al die sjablonen zijn al beschikbaar. Vertaal de teksten in een translatewiki-achtige interface. |
| Gebruik een navigatievak wanneer u een artikel leest op een mobiele telefoon | Onmogelijk.
Navigatievakken zijn moeilijk aan te passen aan mobiele schermen, en zo verschillend van elkaar over wiki's, dat de software ze gewoon verbergt. (Er is wel vraag naar.) |
Mogelijk.
Aangezien de sjabloon-infrastructuur wordt gedeeld over verschillende talen, kunnen de verschillende taalgemeenschappen samenwerken met elkaar en met de ontwikkelaars van de mobiele lees- en bewerkingsinterface en ze responsief maken. |
| Een prachtig ontworpen en mobiel vriendelijke hoofdpagina met regelmatig updates over nieuws, artikelen en afbeeldingen, enz. | Optie 1: Zoek vrijwilligers die uw taal goed kennen, evenals de HTML- en wikisyntaxis (vooral tabellen en sjablonen) en die tijd hebben om liefst elke dag de hoofdpagina te bewerken. Dit gebeurt afzonderlijk en met behulp van verschillende methoden in elke wiki. Dit gebeurt in circa de top 70 wiki's: Engels, Russisch, Frans, Spaans, enz.
Optie 2: Als u niemand kunt vinden die uw taal kent en ook bijna elke dag de HTML-code van de hoofdpagina kan onderhouden, kopieer dan de code van de hoofdpagina uit het Engels of Frans en vraag vrijwilligers van andere wiki's, die uw taal niet kennen, maar wel de wiki-syntaxis, om af en toe de foto van de dag te vervangen. Omdat ze de taal niet kennen, kunnen ze de tekst niet regelmatig bijhouden, u kunt het niet doen omdat u bang bent om de HTML-code te breken, zodat men erg lang vastzit met hetzelfde artikel op de hoofdpagina. Dit gebeurt in sommige van de kleinere talen. Optie 3: Geef het op en zorg voor een statische hoofdpagina, die hoogstwaarschijnlijk niet goed zal werken op mobiele apparaten, ook al is de hoofdpagina meestal de best bekeken pagina in een wiki. Dit gebeurt in veel wiki's, zelfs als er andere bewerkingsactiviteiten zijn. |
Optie 1: Als u mensen hebt die de nodige vaardigheden en tijd hebben om een handgemaakte, aangepaste hoofdpagina in uw taal te onderhouden, en u wilt dat de dingen zo blijven, kunt u dat doen.
Optie 2: Als u niet de mensen hebt die dit handwerk kunnen doen of als uw gemeenschap het goed vindt om een hoofdpagina te hebben die lijkt op die in andere talen, zet dan een eenvoudige, centraal onderhouden sjabloon op uw hoofdpagina. Vervang alleen de tekst van de veranderende items in een eenvoudige vorm, zonder dat u te maken hebt met wiki-syntaxis, tabellen of HTML. Het proces is hetzelfde voor de meeste wiki's, dus dezelfde sjablonen en bots kunnen worden gebruikt door iedereen die geïnteresseerd is. |
| Analyseer hoe artikelen worden gesorteerd door WikiProjects voor een onderzoek naar Wikipedia |
|
|
(Opmerking: de kolom "Met globale sjablonen" veronderstelt dat de infrastructuur in alle Wikimedia-wiki's wordt ingezet en dat de meest gebruikte sjablonen naar de centrale infrastructuur worden verplaatst.) {{🌎🌍🌏}}
Status
Dit deel gaat over de algemene status van het project. Voor details over de laatste ontwikkelingen, evenals een korte geschiedenis van eerdere inspanningen, zie deze pagina.
Zoals hierboven vermeld, is deze pagina vanaf december 2020 slechts een idee en geen plan om een project te implementeren.
In het verleden zijn soortgelijke ideeën voorgesteld. Het oudste bekende voorstel om sjablonen herbruikbaar te maken in wiki's is uit december 2004 in Bugzilla: Interwiki templates (taak T3126). Later werden verschillende andere vergelijkbare ideeën opgevoerd, bijvoorbeeld Phabricator taak T6547. In februari 2017 werd een vergelijkbaar voorstel genaamd Global-Wiki gesloten als "consensus". Sommige van de onderdelen daarvan zijn ingevoerd, zoals de globale voorkeuren, maar niet de sjablonen.
De wens "Central global repository for templates, gadgets and Lua modules" werd gekozen als nummer 3 op de |wenslijst van de gemeenschap 2015 en "Globale gadgets" was de nummer 1 op de wenstlijst van de gemeenschap 2016. Ondanks de steun van de gemeenschap werd geen van beide geïmplementeerd, omdat ze niet geschikt waren voor het Community Tech team, en ze werden ook niet overgedragen naar een ander team.
Het Platform Evolution project (2018) gaf aan dat er in de toekomst de wil is om globale sjablonen te ondersteunen. Op deze pagina is er een discussie over ideeën voor het modulair bijwerken van de inhoud, met de tekst:
- ... "boxen" zijn een ideaal aandachtsgebied voor het creëren van modulariteit. Ze vertegenwoordigen op zichzelf staande functies en ook een kans om het delen van gebruikersfuncties tussen projecten en talen mogelijk te maken, door een projectoverschrijdende service op te zetten om sjablonen te delen. Dit project dwingt ons ook om na te denken over hoe we de lay-out en structuur van de inhoud los van de inhoud van onderliggende delen kunnen aanpakken.
De nauw verwante pagina Platform Evolutie doelen vermeldt dit als een van de doelen:
- Verhogen gelijkheid en kracht van hulpmiddelen voor het bijdragen. We willen het bijdragen van meer inhoudstypen, met inbegrip van media, op meer interactieve manieren en in alle projecten ondersteunen. Dit betekent dat sommige bestaande hulpmiddelen - zoals sjablonen - beschikbaar worden gesteld voor consistent hergebruik in alle projecten en talen. Het betekent ook het verbeteren van vertaalhulpmiddelen om lappen met tekst te verwijderen. Ten slotte willen we ook het voor medewerkers makkelijk maken om nieuwe vertaalhulpmiddelen voor de inhoud te maken.
Abstracte Wikipedia, dat in juli 2020 door de WMF werd goedgekeurd als een nieuw project dat in de nabije toekomst zal worden ontwikkeld, omvat "een cross-wiki repository om sjablonen en modules te delen tussen de WMF-projecten" binnen de Wikifunctions-component als een van de belangrijkste doelen (Wikifunctions was voorheen bekend als "Wikilambda").
Het initiatief Translatable modules werd gelanceerd in september 2020. Het heeft betrekking op een deel van dit voorstel.
In Wensenlijst enquête 2021 ontving de wens "Sjablonen vertalen" het hoogste aantal stemmen. Het was ook de wens met het hoogste aantal stemmen in de geschiedenis van de enquête tot nu toe (december 2020). Deze wens komt nauw overeen met sommige onderdelen van dit voorstel, met name Automatische parametervertaling.
Voor andere voorbeelden van de relatie tussen dit voorstel voor globale sjablonen en verschillende strategische plannen in de bredere Wikimedia-gemeenschap, zie deze pagina.
Er is geen volledig technisch plan voor het implementeren van volledig uitgeruste cross-wiki delen van modules en sjablonen. Deze pagina is een poging om zo'n plan op productniveau voor te stellen en te luisteren naar feedback van redacteuren. {{🌎🌍🌏}}
Bruikbare links
Enkele relevante pagina's die vergelijkbare onderwerpen bespreken:
- Platform evolutie doelen
- Platform evolutie aanbevelingen
- Meertalige sjablonen en modules - Een poging om een vergelijkbare functie te implementeren met behulp van bots
- Wensenlijst 2015 - Centrale globale Repository voor sjablonen, Lua modules en Gadgets kwam binnen als #3 in de Community Wishlist stemming. Vermeld als "In ontwikkeling - Parsing team", maar niet echt gedaan.
- Welke sjablonen moeten globaal zijn - een informele lijst gemaakt door meerdere berwerkers
- Verzoeken om commentaar/Shadow namespace - een slapende RFC over één voorstel voor een technische implementatie van een dergelijke infrastructuur
- Manual:$wgEnableScaryTranscluding - een bestaand rudimentair mechanisme voor het transclueren van inhoud tussen projecten. Beschouwd als inefficiënt en onveilig, en uitgeschakeld op Wikimedia-projecten.
- m:Global-Wiki - een soortgelijk voorstel, met een bredere reikwijdte. Het stond enkele jaren open voor discussie en sloot als "consensus". Sommige dingen daarin zijn geïmplementeerd, zoals algemene gebruikerspagina's en voorkeuren, maar het bevat ook algemene sjablonen, die nog niet zijn gedaan.
- m:Abstract Wikipedia - Een groter voorstel, dat een globale module en template repository bevat (ook bekend als Wikifunctions, en voorheen bekend als "Wikilambda").
- m:Community Wishlist Survey 2021/Translation/Templates translation - Een gemeenschapswens die overeenkomt met sommige delen van dit voorstel, met name Automatische parametervertaling. {{🌎🌍🌏}}