टेक्स्ट और रोजमर्रा के टूल · टेक्स्ट टूलकिट
URL स्लग कन्वेंशन: हाइफ़न, लोअरकेस और क्या RFC 3986 अनुमति देता है
· पेजभूमि
URL-स्लग सामग्री-प्रबंधन पाठ टूल
बताते हैं कि स्लग कहां से आए, कौन से अक्षर RFC 3986 अनारक्षित रह गए, क्यों हाइफ़न ने अंडरस्कोर पर जीत हासिल की और लोअरकेस मायने क्यों रखता है, और ये नियम कैसे आकार देते हैं जो एक स्लग जनरेटर उत्पन्न करता है।
URL को कोई भी ज़ोर से नहीं पढ़ सकता - %20 के रूप में रिक्त स्थान, बड़े अक्षर जो लिंक तोड़ते हैं, और स्लग क्यों मौजूद हैं
`New Product Launch 2026` जैसा पेज पथ सीधे URL में कॉपी किए जाने पर अजीब होता है। रिक्त स्थान को एक और प्रतिनिधित्व की आवश्यकता है, मिश्रित बड़े अक्षर असंगत टाइपिंग को आमंत्रित करते हैं, और विराम चिह्न से पते को स्कैन करना कठिन हो सकता है। एक स्लग पेज को एक कॉम्पैक्ट पथ खंड देता है जिसे लोग साइट नाम के बगल से पहचान सकते हैं।
रिपॉजिटरी यह दस्तावेज नहीं करती है कि स्लग कब उत्पन्न हुए या उन्हें अपनाने का कोई सार्वभौमिक कारण साबित नहीं हुआ है, इसलिए यहां उपयोगी प्रश्न चालू है। किसी साइट स्वामी को संपादन योग्य शीर्षक से प्रकाशन योग्य पथ में एक दोहराए जाने योग्य परिवर्तन की आवश्यकता होती है। ToolAcre परिणाम का दिखावा किए बिना उस परिवर्तन की आपूर्ति करता है जो प्रत्येक टाइपोग्राफ़िक विवरण को संरक्षित करता है।
URL को कोई भी स्लग को अज्ञात मूल कहानी बताए बिना, ज़ोर से नहीं पढ़ सकता है
ToolAcre सामान्य RFC 3986 पार्सर या सत्यापनकर्ता लागू नहीं करता है। इसका `slugify` फ़ंक्शन इनपुट को सामान्य बनाता है, संयोजन चिह्न हटाता है, परिणाम को छोटा करता है, अक्षरों और संख्याओं के अलावा अन्य वर्णों के रन को एक चुने हुए विभाजक से बदल देता है, और दोनों सिरों से विभाजकों को ट्रिम करता है। वे स्रोत-समर्थित नियम इस जनरेटर को व्यापक मानक लेबल की तुलना में अधिक सटीक रूप से परिभाषित करते हैं।
सामग्री-प्रबंधन नीति निर्धारित करते समय यह अंतर मायने रखता है। एक वर्ण URL में कहीं प्रयोग करने योग्य हो सकता है, जबकि इस विशेष स्लग परिवर्तन द्वारा अभी भी हटाया जा रहा है। जेनरेट किए गए पथ को एक एडिटरीय सम्मेलन के रूप में मानें, न कि प्रत्येक कानूनी URL वर्ण, आरक्षित सीमांकक, या अन्य प्रणालियों द्वारा स्वीकृत प्रतिशत-एन्कोडेड प्रतिनिधित्व की पूरी सूची के रूप में।
पूर्ण RFC 3986 व्याख्या के बजाय यह स्लग कार्यान्वयन क्या स्वीकार करता है
`slugify` में हाइफ़न डिफ़ॉल्ट विभाजक हैं, और लगातार विराम चिह्न या रिक्त स्थान उसी विभाजक रन में ढह जाते हैं। इसलिए शीर्षक `Quarterly report: costs & margins` कोलन, एम्परसेंड, या पथ में रिक्त स्थान को उजागर करने के बजाय `quarterly-report-costs-margins` बन जाता है। आउटपुट स्पष्ट रूप से शब्दों में विभाजित रहता है।
स्रोत यह स्थापित नहीं करता है कि किसी विशेष खोज-इंजन निर्णय के माध्यम से हाइफ़न ने अंडरस्कोर को हरा दिया है, इसलिए इतिहास को यहां तथ्य के रूप में प्रस्तुत नहीं किया जाना चाहिए। रक्षात्मक मार्गदर्शन सरल है: साइट के लिए एक विभाजक का चयन करें, इसे लगातार लागू करें, और मैन्युअल रूप से ऐसे फॉर्म मिश्रण करने से बचें जो केवल इसलिए भिन्न होते हैं क्योंकि अलग-अलग एडिटर ने अलग-अलग आदतों का पालन किया है।
असमर्थित खोज-इंजन इतिहास का दावा किए बिना, इस जनरेटर के विभाजक के रूप में हाइफ़न
स्लग लौटाने से पहले लोअरकेस लगाया जाता है। इससे इस परिवर्तन के तहत `About Our Team`, `ABOUT OUR TEAM`, और `about our team` `about-our-team` पर एकत्रित हो जाते हैं। किसी शीर्षक से पूर्वानुमानित लोअरकेस पथ को पुन: प्रस्तुत करना आसान होता है और एडिटरीय संस्करण बनाने से बचा जाता है जिसका एकमात्र दृश्यमान अंतर पूंजीकरण है।
क्या दो अलग-अलग केस वाले पथ एक ही संसाधन पर हल होते हैं, यह आसपास के होस्ट, राउटर, परिनियोजन और रीडायरेक्ट नियमों पर निर्भर करता है; यह पाठ उपयोगिता उस व्यवहार को निर्धारित नहीं कर सकती. व्यावहारिक CMS नियम एक लोअरकेस कैनोनिकल पथ को प्रकाशित करना और किसी भी रीडायरेक्ट नीति को केस हैंडलिंग के बारे में असत्यापित धारणा पर भरोसा करने के बजाय कहीं और स्पष्ट करना है।
लंबाई, शब्दों को रोकना और स्थिरता - स्लग में क्या रखना है और क्या छोड़ना है, इस पर व्यावहारिक मार्गदर्शन
छोटा स्वचालित रूप से बेहतर नहीं है. ऐसे शब्द रखें जो एडिटर को पेज को आस-पास की सामग्री, विशेषकर उत्पाद, कार्य या विषय के नाम से अलग करने दें। शब्दांकन केवल तभी छोड़ें जब शेष पथ अभी भी विशिष्ट हो। एक स्लग जो संक्षिप्त लेकिन अस्पष्ट है, रखरखाव कार्य बनाता है जब कई लेख बाद में एक ही उम्मीदवार पथ के लिए प्रतिस्पर्धा करते हैं।
ToolAcre अपने अंतर्निहित फ़ंक्शन में `maxLength` विकल्प का समर्थन करता है, लेकिन केस-कन्वर्टर कॉन्फ़िगरेशन दृश्यमान लंबाई नियंत्रण के बजाय संपूर्ण-पाठ स्लग क्रिया का वर्णन करता है। इससे भी महत्वपूर्ण बात यह है कि काट-छांट कोई एडिटरीय रणनीति नहीं है। प्रकाशन से पहले तय करें कि कौन से शब्द मायने रखते हैं, फिर चुने हुए स्लग को स्थिर रखें जब लॉन्च के बाद कॉस्मेटिक हेडलाइन शब्द बदल जाते हैं।
कारगर उदाहरण - तीन वास्तविक शीर्षकों को स्लग में बदलना और प्रत्येक को नियमों के विरुद्ध जाँचना
तीन शीर्षकों पर विचार करें. `Cafes, Costs & Margins` `cafes-costs-margins` बन जाता है; `Launch Notes: Version 2` `launch-notes-version-2` बन जाता है; और `A Guide to Better Page Names` `a-guide-to-better-page-names` बन जाता है। प्रत्येक परिणाम लोअरकेस होता है, बनाए गए शब्द रनों के बीच हाइफ़न का उपयोग करता है, और विराम चिह्न हटा देता है जो अक्षर या संख्या नहीं है।
पहला उदाहरण जानबूझकर सादा ASCII है, लेकिन वही स्रोत नियम लैटिन अक्षर से एक विघटित उच्चारण को उसके आधार रूप में मोड़ सकता है। सामग्री को निर्दिष्ट करने से पहले प्रत्येक परिणाम की समीक्षा करें: फ़ंक्शन को ब्रांड वर्तनी, पसंदीदा संक्षिप्ताक्षरों, डुप्लिकेट मार्गों, या उन शब्दों का कोई ज्ञान नहीं है जिन्हें एडिटरीय टीम खर्च करने योग्य मानती है।
इसमें क्या शामिल नहीं है - अंतर्राष्ट्रीयकृत डोमेन नाम और गैर-लैटिन लिपियों को URL में रखने का विकल्प
इस कार्यान्वयन द्वारा गैर-लैटिन अक्षरों को सार्वभौमिक रूप से खारिज नहीं किया गया है। रेगुलर एक्सप्रेशन सभी लिपियों में अक्षरों और संख्याओं को बरकरार रखता है, जबकि कॉन्फ़िगरेशन बताता है कि स्लग गैर-लैटिन लिपियों को लिप्यंतरण के बिना लोअरकेस में रखता है। यह दावा करना कि टूल हमेशा किसी शीर्षक को ASCII में परिवर्तित करता है, इसलिए स्रोत और प्रकाशित टूल सीमाओं दोनों का खंडन होगा।
यह परिवर्तन अंतर्राष्ट्रीयकृत डोमेन नामों को कॉन्फ़िगर नहीं करता है, होस्ट नाम नहीं चुनता है, या लेखन प्रणालियों के बीच शब्दों का लिप्यंतरण नहीं करता है। वे अलग-अलग नीतिगत निर्णय हैं। एक बहुभाषी साइट के लिए, वास्तविक CMS और रूटिंग स्टैक में जेनरेट किए गए पथ का परीक्षण करें, फिर तय करें कि क्या बरकरार रखी गई स्क्रिप्ट या अलग से लिखा गया अनुवाद उस साइट के लिए सर्वोत्तम है।
गैर-लैटिन अक्षरों को बरकरार रखा गया है; लिप्यंतरण और डोमेन नाम इस परिवर्तन से बाहर हैं
एक उपयोगी स्लग नीति संक्षिप्त हो सकती है: पेज शीर्षक से शुरू करें, इसे छोटा करें, मान्यता प्राप्त शब्द रन को हाइफ़न के साथ जोड़ें, आसपास के विभाजकों को हटा दें, सार्थक संख्याओं को संरक्षित करें, और प्रकाशन से पहले स्पष्टता के लिए परिणाम की समीक्षा करें। CMS नियमों में टकराव और रीडायरेक्ट व्यवहार को रिकॉर्ड करें, क्योंकि टेक्स्ट ट्रांसफ़ॉर्म मौजूदा मार्गों का निरीक्षण नहीं कर सकता है या इनबाउंड लिंक की सुरक्षा नहीं कर सकता है।
टेक्स्ट केस कन्वर्टर यांत्रिक भाग को एक क्रिया में लागू करता है। एक शीर्षक चिपकाएँ, स्लग ट्रांसफ़ॉर्म चुनें और पेज पथ में कॉपी करने से पहले आउटपुट का निरीक्षण करें। यह समर्थित उच्चारणों को मोड़ता है, प्रतीकों को हटाता है, विभाजकों को संक्षिप्त करता है, और लोअरकेस टेक्स्ट का उत्पादन करता है, जिससे सामग्री का अर्थ और एडिटर के साथ दीर्घकालिक URL स्थिरता बनी रहती है।