Manual:एक्सटेंशन विकसित करना

This page is a translated version of the page Manual:Developing extensions and the translation is 96% complete.

Outdated translations are marked like this.

Extensions:

अगर आप विकिमीडिया साइटों पर अपना एक्सटेंशन तैनात करना चाहते हैं, Writing an extension for deployment पढ़ें

हर एक्सटेंशन में तीन भाग होते हैं:

सेटअप
कार्यान्वयन
स्थानीयकरण

एक मिनिमल एक्सटेंशन में यह संरचना मौजूद होगी:

MyExtension/extension.json: सेटअप के निर्देश का संग्रहण। फ़ाइल के नाम को 'extension.json' होना चाहिए। (मीडियाविकि 1.25 से पहले सेटअप के निर्देश एक्सटेंशन के अनुसार नामित एक MyExtension/MyExtension.php फ़ाइल में थे। कई एक्सटेंशन अभी भी इस PHP फ़ाइल में पीछे की ओर की संगतता शिम हैं।)
MyExtension/includes/ (or MyExtension/src/): एक्सटेंशन के लिए PHP निष्पादन कोड रखता है।
MyExtension/resources/ (or MyExtension/modules/): एक्सटेंशन के लिए क्लाइंट-मुखी जानकारी जैसे जावास्क्रिप्ट, CSS, LESS आदि रखता है।
MyExtension/i18n/*.json: एक्सटेंशन के लिए स्थानीयकरण की जानकारी रखता है।

जब आप एक एक्सटेंशन विकसित करेंगे, MyExtension को आपके एक्सटेंशन के नाम से बदल दीजिएगा। उसकी डिरेक्ट्री और PHP फ़ाइल(ओं) के नाम 'अपर कैमल केस' में रखें; यह साधारण फ़ाइल नामकरण प्रथा है।^[1] (BoilerPlate एक्सटेंशन आपके एक्सटेंशन के लिए शुरुआत की एक अच्छी जगह है।)

विकसित करते समय आप $wgMainCacheType = CACHE_NONE और $wgCacheDirectory = false सेट करके कैशिंग अक्षम कर सकते हैं, वरना सिस्टम संदेश और दूसरे बदलावों को दिखने में समय लग सकता है।

सेटअप

सेटअप का हिस्सा लिखने के दौरान आपका उद्देश्य है एक्सटेंशन को स्थापित करने में यथासंभव आसान बनाना, ताकि सदस्यों को बस LocalSettings.php पर यह पंक्ति जोड़नी पड़े:

wfLoadExtension( 'MyExtension' );

अगर आप चाहते हैं कि सदस्य आपके एक्सटेंशन को कॉन्फ़िगर कर पाएँ, आपको कुछ कॉन्फ़िगरेशन पैरामीटरों को परिभाषित और प्रलेखित करना होगा, और आपके सदस्य का सेटअप कुछ ऐसा नज़र आएगा:

wfLoadExtension( 'MyExtension' );
$wgMyExtensionConfigThis = 1;
$wgMyExtensionConfigThat = false;

इस सरलता तक पहुँचने के लिए आपके सेटअप फ़ाइल को कई कार्य करने होंगे (जिन्हें निम्न अनुभागों में विस्तार से वर्णित किया गया है):

आपके एक्सटेंशन द्वारा उपयुक्त किसी भी मीडिया हैंडलर, पार्सर फ़ंक्शन, विशेष पृष्ठ, अनुकूलित XML टैग, और वेरिएबल को पंजीकृत करना।
आपके एक्सटेंशन के लिए परिभाषित किसी भी कॉन्फ़िगरेशन वेरिएबलों को परिभाषित और/या वैलिडेट करना।
स्वतः लोड करने के लिए आपके एक्सटेंशन द्वारा उपयुक्त वर्गों को तैयार करना।
यह तय करना कि आपके सेटअप का कौन-सा हिस्सा तुरंत किया जाना चाहिए और कौन-सा हिस्सा मीडियाविकि मूल के शुरू होने और कॉन्फ़िगर किए जाने के बाद किया जाना चाहिए।
आपके एक्सटेंशन द्वारा उपयुक्त किसी भी अतिरिक्त हुक को पंजीकृत करना।
आपके एक्सटेंशन द्वारा उपयुक्त किसी भी नए डेटाबेस टेबल को बनाना या जाँचना।
आपके एक्सटेंशन के लिए स्थानीयकरण सेटअप करना।

एक्सटेंशन को कैसे स्थापित और कॉन्फ़िगर करना है, यह बताते हुए एक README फ़ाइल जोड़ देना एक अच्छी प्रथा है। आप सादे टेक्स्ट या फिर Phabricator मार्कअप सिनटैक्स का इस्तेमाल कर सकते हैं। उदाहरण के लिए Extension:Page Forms के लिए Phabricator Diffusion पृष्ठ देखें। अगर आप मार्कडाउन का इस्तेमाल करते हैं, .md फ़ाइल एक्सटेंशन जोड़ें। उदाहरण के लिए Phabricator Diffusion पर Parsoid के लिए README.md फ़ाइल देखें।

मीडियाविकि पर सुविधाएँ पंजीकृत करना

मीडियाविकि के Special:Version पृष्ठ पर सभी स्थापित एक्सटेंशनों को सूचीबद्ध किया जाता है। उदाहरणस्वरूप, आप Special:Version पर, इस विकि पर स्थापित सभी एक्सटेंशन देख सकते हैं।

मीडियाविकि संस्करण:

≥ 1.25

ऐसा करने के लिए एक्सटेंशन की जानकारी extension.json पर जोड़ दें। एंट्री कुछ ऐसी दिखेगी:

{
	"name": "Example",
	"author": "John Doe",
	"url": "https://www.mediawiki.org/wiki/Extension:Example",
	"description": "This extension is an example and performs no discernible function",
	"version": "1.5",
	"license-name": "GPL-2.0-or-later",
	"type": "validextensionclass",
	"manifest_version": 1
}

कई फ़ील्ड्स वैकल्पिक हैं, मगर उन्हें भर देना एक अच्छी प्रथा है। manifest_version उस स्केमा का संस्करण है जिसके विरुद्ध extension.json फ़ाइल को लिखा गया है। उपलब्ध संस्करण हैं 1 और 2। इस सुविधा के बारे में प्रलेख के लिए यहाँ देखें। अगर आपको मीडियाविकि के किसी अधिक पुराने संस्करण को समर्थित करने की ज़रूरत नहीं, नवीनतम संस्करण चुनें।

उपरोक्त पंजीकरण के साथ, आपको अपनी सुविधा को मीडियाविकि पर "हुक" भी कराना होगा। उपरोक्त विधि सिर्फ Special:Version पृष्ठ को सेटअप करती है। आप यह काम किस तरह से करेंगे, यह आपके एक्सटेंशन के प्रकार पर निर्भर होगा। विस्तार के लिए कृपया हर प्रकार के एक्सटेंशन का प्रलेख देखें:

Extensions:

अपने एक्सटेंशन को कॉन्फ़िगर करने योग्य बनाना

अगर आप चाहते हैं कि सदस्य आपके एक्सटेंशन को कॉन्फ़िगर कर पाएँ, आपको एक या एकाधिक कॉन्फ़िगरेशन वेलिएबल्स प्रदान करने होंगे। उन वेरिएबलों को अनूठे नाम देना अच्छा होगा। उन्हें मीडियाविकि की नामकरण प्रथाओं का भी पालन करना होगा (जैसे ग्लोबल वेरिएबलों की शुरुआत $wg से होनी चाहिए)।

उदाहरणस्वरूप, अगर आपके एक्सटेंशन का नाम "MyExtension" है, आप अपने सभी कॉन्फ़िगरेशन वेरिएबलों की शुरुआत में $wgMyExtension जोड़ सकते हैं। यह सुनिश्चित करना ज़रूरी है कि मीडियाविकि मूल में से कोई भी वेरिएबल इस तरह से शुरू नहीं होता है, और आपको यह भी जाँचना चाहिए कि कोई भी प्रकाशित एक्सटेंशन इस तरह से वेरिएबलों की शुरुआत नहीं करता है। अगर ओवरलैप होने वाले वेरिएबलों के नामों की वजह से सदस्यों को आपके या किसी दूसरे एक्सटेंशन के बीच किसी एक को चुनना पड़े, आपकी खैर नहीं होगी।

अपनी स्थापना की टिप्पणियों में हर कॉन्फ़िगरेशन वेरिएबल के लिए विस्तृत प्रलेख शामिल करना भी एक अच्छी प्रथा है।

यह रहा शुरुआत करने के लिए एक बॉइलर प्लेट का उदाहरण:

{
	"name": "BoilerPlate",
	"version": "0.0.0",
	"author": [
		"Your Name"
	],
	"url": "https://www.mediawiki.org/wiki/Extension:BoilerPlate",
	"descriptionmsg": "boilerplate-desc",
	"license-name": "GPL-2.0-or-later",
	"type": "other",
	"AutoloadClasses": {
		"BoilerPlateHooks": "includes/BoilerPlateHooks.php",
		"SpecialHelloWorld": "includes/SpecialHelloWorld.php"
	},
	"config": {
		"BoilerPlateEnableFoo": {
			"value": true,
			"description": "Enables the foo functionality"
		}
	},
	"callback": "BoilerPlateHooks::onExtensionLoad",
	"ExtensionMessagesFiles": {
		"BoilerPlateAlias": "BoilerPlate.i18n.alias.php"
	},
	"Hooks": {
		"NameOfHook": "BoilerPlateHooks::onNameOfHook"
	},
	"MessagesDirs": {
		"BoilerPlate": [
			"i18n"
		]
	},
	"ResourceModules": {
		"ext.boilerPlate.foo": {
			"scripts": [
				"resources/ext.boilerPlate.js",
				"resources/ext.boilerPlate.foo.js"
			],
			"styles": [
				"resources/ext.boilerPlate.foo.css"
			]
		}
	},
	"ResourceFileModulePaths": {
		"localBasePath": "",
		"remoteExtPath": "BoilerPlate"
	},
	"SpecialPages": {
		"HelloWorld": "SpecialHelloWorld"
	},
	"manifest_version": 2
}

ध्यान रखें कि wfLoadExtension( 'BoilerPlate' ); को कॉल करने के बाद ग्लोबल वेरिएबल $wgBoilerPlateEnableFoo मौजूद नहीं होता। अगर आप वेरिएबल को सेट करते हैं, मान लीजिए LocalSettings.php पर, तब extension.json में निर्दिष्ट डिफ़ॉल्ट वैल्यू का इस्तेमाल नहीं किया जाएगा।

अनुकूलित एक्सटेंशनों के अंदर ग्लोबल वेरिएबलों के बारे में अधिक जानकारी के लिए Manual:Configuration for developers देखें।

स्वतः लोडिंग के लिए वर्ग तैयार करना

अगर आप अपने एक्सटेंशन को लागू करने के लिए वर्ग का इस्तेमाल करते हैं, मीडियाविकि पर एक सरलीकृत तंत्र है जिससे PHP उस स्रोत फ़ाइल को आसानी से ढूँढ़ पाएगा जहाँ पर आपका वर्ग स्थित है। ज़्यादातर मामलों में इस कारण आपको अपना __autoload($classname) साधन लिखने की ज़रूरत नहीं पड़ेगी।

मीडियाविकि के स्वतः लोडिंग तंत्र का इस्तेमाल करने के लिए आपको AutoloadClasses फ़ील्ड में एंट्रियाँ जोड़नी होंगी। हर एंट्री की कुँजी वर्ग का नाम होगी; वैल्यू उस फ़ाइल का नाम होगा जिसमें वर्ग की परिभाषा मौजूद होगी। किसी साधारण एक-वर्ग-वाले एक्सटेंशन के लिए वर्ग को आम तौर पर एक्सटेंशन का नाम दिया जाता है, तो आपका स्वतः लोडिंग अनुभाग कुछ इस तरह का नज़र आएगा (एक्सटेंशन का नाम है MyExtension):

{
	"AutoloadClasses": {
		"MyExtension": "includes/MyExtension.php"
	}
}

फ़ाइल का नाम उस डिरेक्ट्री के सापेक्ष है जिसमें extension.json फ़ाइल मौजूद है।

अधिक जटिल एक्सटेंशनों के लिए नामस्थानों का इस्तेमाल किया जा सकता है। विस्तार के लिए Manual:Extension.json/Schema#AutoloadNamespaces देखें।

अतिरिक्त हुक्स परिभाषित करना

Manual:Hooks देखें।

डेटाबेस टेबल्स जोड़ना

सुनिश्चित करें कि एक्सटेंशन मूल डेटाबेस टेबलों को बदलता नहीं है। इस बजाय, एक्सटेंशन को प्रासंगिक MW टेबलों तक बाहरी कुँजियों वाले नए टेबल्स बनाने चाहिए।

चेतावनी:

अगर आपके एक्सटेंशन का इस्तेमाल WMF द्वारा होस्ट किए जाने वाले किसी विकि पर किया जा रहा है, कृपया स्केमा बदलाव गाइड का पालन करें।

अगर आपके एक्सटेंशन को अपने डेटाबेस टेबल्स जोड़ने की ज़रूरत है, LoadExtensionSchemaUpdates हुक का इस्तेमाल करें। उपयोग के बारे में अधिक जानकारी के लिए मैन्युअल पृष्ठ देखें।

स्थानीयकरण सेटअप करें

देखें:

लॉग्स जोड़ें

मीडियाविकि पर पारदर्शिता और सहयोग के लिए विकि पर सदस्यों द्वारा सभी कार्यों को ट्रैक किया जाता है। ऐसा करने के लिए Manual:Logging to Special:Log देखें।

निर्भरताएँ हैंडल करना

मान लें कि एक्सटेंशन को किसी दूसरे एक्सटेंशन की उपस्थिति की ज़रूरत होती है, उदाहरणस्वरूप क्योंकि कार्यक्षमताएँ या डेटाबेस टेबल्स का इस्तेमाल किया जाता है और गैर-उपस्थिति के मामले में त्रुटि संदेशों से बचा जाता है।

उदाहरणस्वरूप, CountingMarker एक्सटेंशन को विशिष्ट फ़ंक्शन्स के लिए HitCounters एक्सटेंशन की उपस्थिति की ज़रूरत होती है।

इसे निर्दिष्ट करने का एक तरीका होगा extension.json में requires कुँजी का इस्तेमाल करना।

एक दूसरा विकल्प है ExtensionRegistry (मीडियाविकि 1.25 से उपलब्ध) का इस्तेमाल करना:

	if ( ExtensionRegistry::getInstance()->isLoaded( 'HitCounters', '>=1.1' ) {
		/* do some extra stuff, if extension HitCounters is present in version 1.1 and above */
	}

Currently (as of February 2024, MediaWiki 1.41.0) the name of the extension-to-be-checked needs to exactly match the name in their extension.json.^[2]^[3]

Example: if you want to check the load status of extension "OpenIDConnect", you have to use it with a space

	if ( ExtensionRegistry::getInstance()->isLoaded( 'OpenID Connect' ) {
    ...
	}

स्थानीयकरण

Localisation – पर मीडियाविकि के स्थानीयकरण इंजन के बारे में चर्चा की गई है। विशिष्ट रूप से, स्थानीयकृत करने योग्य सुविधाओं की एक सूची, और स्थानीयकरण में शामिल मीडियाविकि स्रोत कोड के कुछ वर्गों का एक वर्णन है।
नए संदेश बनाना
Localization checks – पर स्थानीयकृत संदेशों की साधारण समस्याओं की एक चर्चा है

विकसित करते समय आप $wgMainCacheType = CACHE_NONE और $wgCacheDirectory = false सेट करके कैशिंग अक्षम कर सकते हैं, वरना सिस्टम संदेश में बदलावों को दिखने में समय लग सकता है।

अगर आप चाहते हैं कि आपके एक्सटेंशन के इस्तेमाल उन विकियों पर किया जाए जो एकाधिक भाषाओं में उपलब्ध है, आपको अपने एक्सटेंशन पर स्थानीयकरण का समर्थन जोड़ना होगा।

<language-key>.json में संदेश रखें

एक स्थानीयकरण JSON फ़ाइल में संदेशों की परिभाषाएँ रखें, जहाँ हर भाषा कुँजी आपके एक्सटेंशन की एक अनुवादित भाषा को प्रतिनिधित करेगी। संदेशों को एक संदेश कुँजी और संदेश के साथ मानक JSON प्रारूप में रखा जाता है। हर संदेश छोटे अक्षरों में होना चाहिए और उनमें रिक्त स्थान नहीं होने चाहिए। हर कुँजी के नाम की शुरुआत छोटे अक्षरों में एक्सटेंशन के नाम से होनी चाहिए। एक उदाहरण आप MobileFrontend एक्सटेंशन में पा सकते हैं। यह रहा एक मिनिमल JSON फ़ाइल का उदाहरण (इस मामले में 'en.json'):

en.json

{
	"myextension-desc": "Adds the MyExtension great functionality.",
	"myextension-action-message": "This is a test message"
}

संदेश प्रलेख qqq.json में रखें

संदेश की कुँजियों के लिए प्रलेख qqq कोड वाली छद्म-भाषा के लिए JSON फ़ाइल में रखा जा सकता है। उपरोक्त उदाहरण का एक प्रलेख हो सकता है:

qqq.json:

{
	"myextension-desc": "The description of MyExtension used in Extension credits.",
	"myextension-action-message": "Adds 'message' after 'action' triggered by user."
}

स्थानीयकरण फ़ाइल लोड करें

अपने extension.json में अपनी संदेश फ़ाइलों का स्थान निर्दिष्ट करें (उदाहरणस्वरूप, i18n/ डिरेक्ट्री में):

{
	"MessagesDirs": {
		"MyExtension": [
			"i18n"
		]
	}
}

PHP में wfMessage का इस्तेमाल करें

अपने सेटअप और कार्यान्वयन कोड में संदेश के हर शाब्दिक उपयोग को wfMessage( $msgID, $param1, $param2, ... ) के एक कॉल से बदल दें। IContextSource (और SpecialPage के उपवर्गों जैसे कुछ अधिक) का इस्तेमाल करने वाले वर्गों पर आप $this->msg( $msgID, $param1, $param2, ... ) का इस्तेमाल कर सकते हैं। उदाहरण:

wfMessage( 'myextension-addition', '1', '2', '3' )->parse()

जावास्क्रिप्ट में mw.message का इस्तेमाल करें

जावास्क्रिप्ट में भी i18n फ़ंक्शन्स का इस्तेमाल किया जा सकता है। विस्तार के लिए Manual:Messages API देखें।

एक्सटेंशन के प्रकार

Extensions:

एक्सटेंशनों को कार्यान्वयन की प्रोग्रामिंग तकनीकों के अनुसार श्रेणीबद्ध किया जा सकता है। ज़्यादातर जटिल एक्सटेंशन्स इनमें से एकाधिक तकनीकों का इस्तेमाल करते हैं:

उपवर्गीकरण: मीडियाविकि यह अपेक्षा करेगा कि विशिष्ट प्रकार के एक्सटेंशनों को मीडियाविकि द्वारा प्रदत्त बुनियादी वर्गों के उपवर्गों के रूप में लागू किया जाए:
- Special pages – SpecialPage के उपवर्गों की मदद से वे पृष्ठ बनाए जाते हैं जिन्हें सिस्टम की वर्तमान स्थिति, सदस्यों द्वारा इनपुट पैरामीटरों, और डेटाबेस क्वेरीज़ की मदद से डायनामिक रूप से बनाया जाता है। रिपोर्ट्स और डेटा एंट्री फ़ॉर्म्स, दोनो बनाए जा सकते हैं। इनकी मदद से रिपोर्टिंग और प्रबंधन के कार्य, दोनों किए जा सकते हैं।
- स्किन्स – स्किन्स, मीडियाविकि के SkinTemplate वर्ग के उपवर्ग बनकर पृष्ठों को आउटपुट करने वाले कोड को बदलकर मीडियाविकि की दिखावट और अनुभव को बदलते हैं।
Hooks – मीडियाविकि के प्रोसेसिंग के अंदर कुँजी पॉइंट्स पर अनुकूलित PHP कोड जोड़ने का एक तकनीक। इनका इस्तेमाल मीडियाविकि के पार्सर, इसके स्थानीयकरण इंजन, इसकी एक्सटेंशन प्रबंधन प्रणाली और इसकी अनुरक्षण प्रणाली द्वारा किया जाता है।
- टैग-फ़ंक्शन संबंध – XML-रूप टैग्स जिन्हें HTML कोड आउटपुट करने वाले किसी PHP फ़ंक्शन से जोड़ा जाता है। अपने आपको टैग्स के अंदर के टेक्स्ट को ही प्रारूपित करने तक सीमित न करें। आपको उसे दिखाने की भी ज़रूरत नहीं। कई टैग एक्सटेंशन्स टेक्स्ट का इस्तेमाल पैरामीटरों के रूप में करते हैं जिससे Google वस्तुओं, डेटा एंट्री फ़ॉर्म्स, RSS फ़ीड्स, चुनिंदा विकि लेखों से सारांश, आदि को एम्बेड करने वाला HTML बनाया जा सकता है।
जादुई शब्द – एक तकनीक जिसे किसी फ़ंक्शन से संबद्ध एक ही ID से कई विकिटेक्स्ट स्ट्रिंग्स मैप किए जा सकते हैं। वेरिएबल्स और पार्सर फ़ंक्शन्स, दोनों इस तकनीक का इस्तेमाल करते हैं। उस ID पर मैप किए गए सारे टेक्स्ट को फ़ंक्शन द्वारा लौटाए गए वैल्यू से बदल दिया जाएगा। टेक्स्ट स्ट्रिंग्स और ID के बीच मानचित्रण को $magicWords ऐरे में रखा जाता है। ID का विवेचन एक जटिल प्रक्रिया है - अधिक जानकारी के लिए Manual:जादुई शब्द देखें।
- Variable – इन्हें वेरिएबल्स कहना गलत होगा। ये विकिटेक्स्ट के हिस्से हैं जो साँचों की तरह दिखते हैं, मगर इनमें कोई पैरामीटर या निर्दिष्ट होर्ड-कोड किए गए वैल्यू नहीं होते हैं। {{PAGENAME}} या {{SITENAME}} जैसे मानक विकि मार्कअप वेरिएबलों के उदाहरण हैं। इनका नाम इनके वैल्यूओं के स्रोत के आधार पर दिया गया है: एक PHP वेरिएबल या फिर ऐसा कुछ जो किसी वेरिएबल को सौंपा जा सकता है, जैसे कोई स्ट्रिंग, संख्या, एक्सप्रेशन, या फ़ंक्शन में लौटाया गया वैल्यू।
- Parser functions – {{functionname: argument 1 | argument 2 | argument 3...}}. टैग एक्सटेंशन्स की तरह पार्सर फ़ंक्शन्स तर्कों को प्रोसेस करके एक वैल्यू लौटाते हैं। टैग फ़ंक्शन्स के विपरीत, पार्सर फ़ंक्शन्स का परिणाम विकिटेक्स्ट होता है।
API मॉड्यूल्स – आप मीडियाविकि के प्रतिक्रिया API पर अनुकूलित मॉड्यूल्स जोड़ सकते हैं जिन्हें जावास्क्रिप्ट, बॉट्स या तृतीय-पक्ष क्लाइंट्स की मदद से इन्वोक किया जा सकता है।
Page content models – अगर आपको विकिटेक्स्ट, JSON, आदि के अलावा किसी प्रारूप में डेटा रखने की ज़रूरत है, आप एक नया ContentHandler बना सकते हैं।

दूसरे मूल संस्करणों का समर्थन

मीडियाविकि मूल के पुराने संस्करणों को समर्थित करने की दो प्रचलित प्रथाएँ हैं:

Master: एक्सटेंशन की master शाखा, मूल जितने हो सके उतने पुराने संस्करणों से अनुकूल है। इससे अनुरक्षण पर ज़रा-सा बोझ पड़ता है (पीछे की तरफ अनुकूलता के लिए हैक्स काफ़ी लंबे समय तक रखने पड़ते हैं, और एक्सटेंशन में बदलावों को मीडियाविकि के कई पुराने संस्करणों पर परीक्षित करना पड़ता है), मगर मीडियाविकि के पुराने संस्करण चला रहे साइटों को एक्सटेंशन पर हाल में जोड़ी गई कार्यक्षमता से फ़ायदा हो सकता है।
प्रकाशन शाखाएँ: एक्सटेंशन की प्रकाशन शाखाएँ मूल की उचित शाखाओं से अनुकूल हैं, जैसे मीडियाविकि 1.42 का इस्तेमाल करने वाले साइटों को एक्सटेंशन की REL1_42 शाखा का इस्तेमाल करना होगा। (Gerrit पर होस्ट किए जाने वाले एक्सटेंशनों के लिए, ये शाखाएँ मीडियाविकि के नए संस्करणों के प्रकाशित किए जाने पर अपने आप बना दी जाती हैं।) इससे कोड साफ़-सुथरा रहता है और विकास की तेज़ी बढ़ जाती है, मगर पुराने मूल संस्करणों का इस्तेमाल करने वाले विकियों को बग-सुधारों और नई सुविधाओं से फ़ायदा नहीं होता अगर उन्हें सदस्यों द्वारा बैकपोर्ट न किया जाए।

एक्सटेंशनों के अनुरक्षकों को {{Extension }} साँचे के compatibility policy पैरामीटर से यह घोषित कर देना चाहिए कि वे किस प्रथा का पालन करते हैं।

लाइसेंस

MediaWiki is an open-source project and users are encouraged to make any MediaWiki extensions under an Open Source Initiative (OSI) approved license compatible with GPL-2.0-or-later (Wikimedia's standard software license).

We recommend adopting one of the following compatible licenses for your projects in Gerrit:

GNU General Public License, version 2 or later (GPL-2.0-or-later)
MIT License (MIT)
BSD License (BSD-3-Clause)
Apache License 2.0 (Apache-2.0)

For extensions that have a compatible license, you can request developer access to the MediaWiki source repositories for extensions. To specify the licence in code and with "license-name" a key should be used to provide it's short name, e.g. "GPL-2.0-or-later" or "MIT" adhering to the list of identifiers at spdx.org.

प्रकाशन

अपने मौजूदा एक्सटेंशन के प्रलेख को स्वतः श्रेणीबद्ध और मानकीकृत करने के लिए कृपया साँचा:Extension देखें। अपने नए एक्सटेंशन को इस विकि पर जोड़ने के लिए:

A developer sharing their code in the MediaWiki code repository should expect:

Feedback / Criticism / Code reviews: Review and comments by other developers on things like framework use, security, efficiency and usability.

Developer tweaking: Other developers modifying your submission to improve or clean-up your code to meet new framework classes and methods, coding conventions and translations.

Improved access for wiki sysadmins: If you do decide to put your code on the wiki, another developer may decide to move it to the MediaWiki code repository for easier maintenance. You may then create a विकासक खाता to continue maintaining it.

Future versions by other developers: New branches of your code being created automatically as new versions of MediaWiki are released. You should backport to these branches if you want to support older versions.; Incorporation of your code into other extensions with duplicate or similar purposes — incorporating the best features from each extension.

Credit: Credit for your work being preserved in future versions — including any merged extensions.; Similarly, you should credit the developers of any extensions whose code you borrow from — especially when performing a merger.

Any developer who is uncomfortable with any of these actions occurring should not host in the code repository. You are still encouraged to create a summary page for your extension on the wiki to let people know about the extension, and where to download it.

तैनात-कार्य और पंजीकरण

अगर आपका उद्देश्य है अपने एक्सटेंशन को विकिमीडिया साइटों (संभवतः विकिपीडिया समेत) में लागू करवाना, प्रदर्शन और सुरक्षा में अतिरिक्त सावधानी का आश्वासन ज़रूरी है। Writing an extension for deployment देखें।

अगर आपका एक्सटेंशन नामस्थान जोड़ता है, आपको इसके डिफ़ॉल्ट नामस्थानों को पंजीकृत कर देना चाहिए; उसी तरह, अगर यह डेटाबेस टेबल्स जोड़ता है, आपको उन्हें database field prefixes पर पंजीकृत कर देना चाहिए।

कृपया ध्यान रखें कि विकिमीडिया साइटों पर नए एक्सटेंशनों के निरीक्षण और तैनात-कार्य की प्रक्रिया काफ़ी धीमी हो सकती है, और कुछ मामलों में तो इसे दो से भी ज़्यादा वर्ष लग जाते हैं।^[4]

सहायता प्रलेख

आपको अपने एक्सटेंशन द्वारा प्रदत्त सुविधाओं के लिए एक सार्वजनिक डोमेन सहायता प्रलेख प्रदान करना चाहिए। The convention is for extensions to have their user-focused help pages under a pseudo-namespace of Help:Extension:<ExtensionName>, with whatever subpages are required (the top level page will be automatically linked from the extension infobox if it exists). एक अच्छा उदाहरण है Help:CirrusSearch । आपको addHelpLink() फ़ंक्शन की मदद से सदस्यों को प्रलेख की एक कड़ी देनी चाहिए।

Releasing updates

There are a number of common approaches to releasing updates to extensions. These are generally defined according to the compatibility policy of the extension (master, rel, or ltsrel):

master - Releases may be tagged with version numbers on the master branch, and documentation provided on the extension's homepage describing which extension versions are compatible with which core versions. Release branches will still be created automatically, and you may wish to delete these if they are not intended to be used.
rel and ltsrel - Release by backporting changes to the REL1_* branches (either all changes, or only critical ones). Version numbers are generally not needed unless the extension is a dependency of another (the version number can then be provided in the other extension's configuration to ensure that incompatible combinations aren't installed). Many extensions will stay at the same version number for years.

सहायता / सहयोग प्रदान करना

एक्सटेंशन के विकासकों को विकिमीडिया के Phabricator पर एक खाता बनाना चाहिए, और एक्सटेंशन के लिए एक नई परियोजना का अनुरोध करना चाहिए। यह एक सार्वजनिक मंच प्रदान करेगा जहाँ सदस्य समस्याएँ और सुझाव प्रस्तुत कर पाएँगे, और आप सदस्यों और विकासकों के साथ मिलकर बग्स ठीक कर सकते हैं और अपने एक्सटेंशन के लिए सुविधाओं की योजनाएँ बना सकते हैं।

ये भी देखें

Manual:Extension registration - provides further developer documentation on how to register extensions and skins.
API:Extensions – बताता है कि आपका एक्सटेंशन क्लाइंट्स को API कैसे प्रदान कर सकता है
Manual:Extending wiki markup
Manual:Coding conventions
एक्सटेंशनों के लिए सर्वोत्तम प्रथाएँ
ResourceLoader

Learn by example

Extension:Examples – विस्तृत इनलाइन प्रलेख के साथ कुछ उदाहरण सुविधाएँ लागू करता है
- इस और दूसरे उदाहरण वाला examples गिट रिपॉज़िटरी
Extension:BoilerPlate – एक काम करने वाला बॉइलरप्लेट एक्सटेंशन, जिसे आप अपने एक्सटेंशन के लिए शुरुआत का एक स्थान मानकर चल सकते हैं (गिट रिपॉज़िटरी)
- Example एक्सटेंशन पढ़ें, और अपने कोड को BoilerPlate एक्सटेंशन पर आधारित करें।
cookiecutter-mediawiki-extension – एक cookiecutter साँचा जो एक बॉइलरप्लेट एक्सटेंशन बनाता है (वेरिएबलों आदि के साथ)
- इससे आप तुरंत अपना एक्सटेंशन बनाना शुरू कर सकते हैं।
- BoilerPlate एक्सटेंशन भी बना सकता है।
List of simple extensions - उनसे विशिष्ट कोड की प्रतिलिपि बनाएँ

सन्दर्भ

[1] rchive:wikitech-l/2011-August/054839.html

[2] ttps://www.mediawiki.org/wiki/Topic:Xyjw7nhfzaas5r5z

[3] ttps://phabricator.wikimedia.org/T356596

[4] ricator:T148848

[1]

[2]

[3]

[4]