लेख
"गतिशील + लेख" बहुभाषी ब्लॉग बनाने के लिए शुद्ध फ्रंट-एंड का उपयोग करें
मैंने अपनी वेबसाइट को "डायनामिक + आर्टिकल" बहुभाषी ब्लॉग में बनाया: सामग्री को मार्कडाउन के साथ प्रबंधित किया जाता है, पोस्ट करते समय अनुवाद पूरा हो जाता है, निर्माण के दौरान स्थिर पृष्ठ उत्पन्न होते हैं, और ब्राउज़र भाषाओं को पढ़ने और स्विच करने के लिए जिम्मेदार होता है। यह आलेख सामग्री मॉडल, साझा पाइपलाइनों, ऑन-डिमांड लोडिंग और एसईओ के बीच व्यापार-बंद, और वास्तव में शुद्ध फ्रंट-एंड क्या बचाता है, को तोड़ता है।
· 1 मिनट में पढ़ें
मुझे आशा है कि मेरी वेबसाइट का उपयोग विचारों के एक पैराग्राफ को लिखने या संपूर्ण तकनीकी मुद्दे को स्पष्ट रूप से लिखने के लिए किया जा सकता है। छोटे वाले में "डायनामिक्स" और बड़े वाले में "लेख" डालें। दोनों को एक-दूसरे से जोड़ा जा सकता है, और जब विज़िटर भाषा बदलता है, तो सामग्री को भी एक साथ स्विच करना होगा।
यह आवश्यकता बहुत सामान्य लगती है, लेकिन यदि आप शुरू से ही एक डेटाबेस, बैकएंड और सामग्री एपीआई जोड़ते हैं, और फिर प्रत्येक भाषा के संस्करण को संभालते हैं, तो यह जल्द ही एक और उत्पाद बन जाएगा जिसके लिए दीर्घकालिक रखरखाव की आवश्यकता होती है।
मैंने सबसे पहले उन आवश्यकताओं को सीमित करना चुना जिनका मैं वास्तव में उपयोग कर सकता हूं: ** एक लेखक, सामग्री को Git में दर्ज करें, और प्रकाशन के बाद वेबसाइट का पुनर्निर्माण करें। पाठक को केवल स्थिर फ़ाइलें और एक ब्राउज़र की आवश्यकता होती है। ** यह स्टीफन.ताइपे की वर्तमान "गतिशील + लेख" संरचना है।
शुद्ध फ्रंट-एंड पढ़ने के अंत को संदर्भित करता है#
आइए पहले सीमाएं स्पष्ट करें। यह प्रोजेक्ट रिएक्ट, वाइट और टेलविंड का उपयोग करता है। सामग्री प्रसंस्करण, छवि रूपांतरण और स्क्रिप्ट निर्माण के लिए Node.js अभी भी आवश्यक है; प्रकाशन चरण के दौरान अनुवाद बाहरी सेवाओं को भी कॉल करेगा। परिनियोजन के बाद, स्थिर फ़ाइलें Nginx द्वारा प्रदान की जाती हैं।
तो शुद्ध फ्रंट-एंड से मेरा मतलब यह है कि जब पाठक वेबसाइट खोलते हैं, तो उन्हें जानकारी खोजने, समूह पृष्ठों या वास्तविक समय में अनुवाद करने के लिए एक विशेष ब्लॉग बैक-एंड की आवश्यकता नहीं होती है। इसमें एक निर्माण प्रक्रिया और एक होस्ट है, लेकिन लेख पढ़ने के लिए कोई स्थायी एप्लिकेशन एपीआई या डेटाबेस नहीं है।
यदि काम पहले से किया जाए तो पढ़ना बहुत आसान हो जाएगा।
समाचार और लेख एक ही स्रोत साझा करते हैं, प्रत्येक का अपना मॉडल होता है#
सामग्री content/ में केंद्रित है, और मूल पाठ सभी मार्कडाउन है। दोनों सामग्रियों को एक ही प्रारूप में नहीं रखा गया है:
content/
tags.yaml
tags.locales.yaml
notes/2026/20261004-0944.md
notes/2026/20261004-0944.locales.yaml
articles/frontend-only-multilingual-blog/
index.md
locales.yaml
cover.webp
डायनेमिक्स छोटे कार्ड हैं। फ़ाइल नाम आईडी के रूप में ताइपे समय के मिनट का उपयोग करता है। इसे विचारों, सीखने, ऑनलाइन, धोखाधड़ी या पढ़ने से चिह्नित किया जा सकता है। इसे हर बार शीर्षक के बारे में सोचे बिना सिर्फ एक पैराग्राफ लिखकर स्थापित किया जा सकता है। यदि यह 500 शब्दों से अधिक है तो एक अनुस्मारक दिखाई देगा, और यदि यह 1,000 शब्दों से अधिक है तो इसे एक लेख में बदल दिया जाना चाहिए।
लेखों में एक निश्चित स्लग, शीर्षक, सार, तिथि होती है, और कवर और अद्यतन समय भी हो सकता है। मूल साझा लिंक को अमान्य होने से बचाने के लिए सार्वजनिक किए जाने के बाद यूआरएल को नहीं बदला जाएगा।
दोनों article: का उपयोग करके संबंधित हैं। अपडेट के लिए, आप पहले प्रश्न लिख सकते हैं और फिर पूरे लेख को लिंक कर सकते हैं; आलेख पृष्ठ उन अद्यतनों को सूचीबद्ध करेगा जो इसे उल्टा संदर्भित करते हैं। छोटी सामग्री वर्तमान प्रारंभिक बिंदु को बरकरार रखती है, और लंबी सामग्री व्युत्पत्ति को समाप्त करने के लिए जिम्मेदार है। दोनों तरफ एक ही पूरा पाठ पोस्ट करने की आवश्यकता नहीं है।
सामग्री नियमों को निर्माण से पहले त्रुटियों को रोकने दें#
यदि मार्कडाउन को बस चित्र में डाल दिया जाता, तो लाइव होने के बाद तक कई समस्याएं नहीं देखी जातीं: गलत तारीखें, असंबद्ध लेख, बिना बदलाव के चित्र, या एक ही विषय को तीन समान टैग के साथ लिखा जाना।
मैंने इन नियमों को साझा सामग्री पाइपलाइन में डाल दिया है। loadContent फ़ाइल पढ़ें, ज़ॉड के साथ फ़ील्ड की जांच करें, और फिर मार्कडाउन, छवियों, भाषा और सामग्री संबंधों को संसाधित करें। सीएलआई निरीक्षण और वाइट निर्माण दोनों इस पाइपलाइन का उपयोग "स्थानीय मशीन कहती है कि यह काम करती है, लेकिन आधिकारिक वातावरण नहीं करता है" के बीच के अंतर को कम करने के लिए किया जाता है।
टैग केवल tags.yaml पंजीकृत कुंजी स्वीकार करता है; गतिशील रूप से संदर्भित लेख और अन्य गतिशीलता मौजूद होनी चाहिए; स्थानीय पूर्वावलोकन ड्राफ्ट पढ़ सकता है, और आधिकारिक बिल्ड ड्राफ्ट को बाहर कर देगा। ये नियम पोस्ट करते समय याद रखने पर आधारित नहीं हैं, बल्कि ये वास्तव में निरीक्षण को रोकते हैं।
Markdown के आउटपुट की सीमाएँ भी स्पष्ट हैं: raw HTML सीधे आउटपुट नहीं होता, बनाए गए HTML को साफ़ किया जाता है, और code blocks को build के समय highlight किया जाता है। स्थानीय relative paths से संदर्भित content images को अधिकतम 1600px चौड़ाई वाले WebP में बदला जाता है और GPS डेटा सहित EXIF metadata हटाया जाता है। लेख, कार्ड और share previews में वही संसाधित छवियाँ इस्तेमाल होती हैं। Remote images और root से शुरू होने वाले absolute paths वाली छवियाँ इस स्थानीय conversion प्रक्रिया से नहीं गुजरतीं।
बहुभाषी प्रणाली की लागत का भुगतान लेख प्रकाशित करते समय किया जाएगा।#
वेबसाइट वर्तमान में 22 भाषाओं का समर्थन करती है। मूल पारंपरिक चीनी पाठ एक बार लिखा गया है, और अन्य 21 भाषाओं के शीर्षक, सार, पाठ और चित्र विवरण इसके आगे locales.yaml में संग्रहीत हैं।
यहां एक निर्णय है जिसकी मुझे परवाह है: **पाठकों को अनुवाद के लिए इंतजार नहीं करना पड़ेगा। ** content:localize पोस्ट करते समय अनुवाद उत्पन्न करें। आधिकारिक बिल्ड केवल मौजूदा फ़ाइलों को पढ़ता है और हर बार तैनात होने पर अनुवाद सेवा को दोबारा कॉल नहीं करता है।
मूल पाठ और अनुवादित पाठ की तुलना करने के लिए सोर्स डाइजेस्ट का उपयोग करें। यदि मूल पाठ बदल दिया जाता है, तो पुराने अनुवाद को नवीनतम संस्करण नहीं माना जा सकता है; यदि एक भाषा परिवार गायब है या अनुवाद पुराना है, तो content:check विफल हो जाएगा। अनुवाद प्रक्रिया कोड, इनलाइन कोड और लिंक लक्ष्यों को तकनीकी पहचानकर्ताओं या यूआरएल का अनुवाद करने से बचाती है।
इसका मतलब यह नहीं है कि स्वचालित अनुवाद में मानव संपादन की गुणवत्ता होती है। यह पूर्णता और अद्यतन स्थिरता को संबोधित करता है, और पेशेवर भाषा और लहजे को अभी भी प्रूफरीडिंग की आवश्यकता होती है। जो मूल पाठ बदला नहीं गया है, वह मौजूदा अनुवाद को बनाए रखेगा, और मैन्युअल रूप से संशोधित पाठ को दोबारा चलाने से अधिलेखित नहीं किया जाएगा।
सूची में सार पढ़ें, लेख लोड करने के लिए क्लिक करें#
सामग्री बढ़ने के बाद, यदि मुखपृष्ठ प्रत्येक लेख और प्रत्येक भाषा परिवार का पूरा पाठ लोड करता है, तो शुद्ध फ्रंट-एंड बहुत धीमा होगा।
Vite plugin content को तीन entry points में बाँटता है: homepage के लिए virtual:content/latest, content pages के लिए virtual:content/index, और हर लेख के लिए अलग virtual:content/article/<slug>। Homepage पर सबसे हाल के तीन छोटे अपडेट और तीन article cards आते हैं। छोटे अपडेट के data में पूरा पाठ और अनुवाद अब भी शामिल होते हैं; card पर केवल दिखाया गया पाठ छोटा किया जाता है। लंबे लेखों के cards में सिर्फ़ सारांश और संबंधित data होता है, जबकि हर लेख का पूरा body dynamic import से अलग लोड होता है।
रिएक्ट का सस्पेंस टेक्स्ट की प्रतीक्षा के लिए जिम्मेदार है, और बाहरी त्रुटि सीमा लोडिंग विफलता संदेश प्रदर्शित करने के लिए जिम्मेदार है। जब पाठ अनुरोध विफल हो जाता है, तो शीर्षक, सार और पृष्ठ नेविगेशन बना रहता है।
यहां ट्रेड-ऑफ़ भी हैं: वर्तमान में, प्रति लेख एक पाठ खंड होता है, जिसमें प्रत्येक भाषा परिवार के अनुवाद होते हैं, और इसे अभी तक प्रति भाषा परिवार के एक खंड में विभाजित नहीं किया गया है। गतिशील पूर्ण पाठ और अनुवाद सामग्री सूचकांक में दर्ज किए जाते हैं। जैसे-जैसे सामग्री की मात्रा बढ़ती जा रही है, सूचकांक का आकार और बहुभाषी पाठ के डाउनलोड की संख्या मापे जाने वाले अगले चरण हैं।
स्थैतिक पढ़ने के लिए फ्रंट-एंड स्विचिंग और एक प्रवेश द्वार होना चाहिए।#
हम केवल एसपीए करते हैं, और जब हम इसे साझा करते हैं, तो हम अक्सर मुखपृष्ठ पर केवल शीर्षक और चित्र देखते हैं। यह लेख के लिए पर्याप्त नहीं है.
इसलिए, सेट करते समय, प्रत्येक डायनामिक, आलेख और टैग URL का अपना HTML शेल होता है, जिसमें शीर्षक, विवरण, कैनोनिकल, ओपन ग्राफ़ और JSON-LD होता है, और पढ़ने योग्य मूल पाठ को noscript में रखा जाता है। आप जावास्क्रिप्ट निष्पादित किए बिना इस लेख की सामग्री और विशेष कवर प्राप्त कर सकते हैं।
सामग्री का वही भाग feed.xml, sitemap-content.xml, लेख का मार्कडाउन संस्करण और llms.txt के लिए लेख सूचकांक भी तैयार करेगा। ये निर्मित उत्पाद हैं, सामग्री का कोई अन्य सेट नहीं जिसके लिए मैन्युअल सिंक्रनाइज़ेशन की आवश्यकता होती है।
हालाँकि, बहुभाषी एसईओ की सीमाओं को भी स्पष्ट किया जाना चाहिए: **वर्तमान में, अपडेट और लेख प्रत्येक भाषा में एक ही यूआरएल साझा करते हैं, और भाषा फ्रंट एंड द्वारा स्विच की जाती है; स्थिर सामग्री पृष्ठ, फ़ीड और मार्कडाउन संस्करण मूल पाठ को बनाए रखते हैं। ** मुखपृष्ठ में भाषा और प्रकाश और अंधेरे मोड के लिए प्री-रेंडरिंग भी है। इसका मतलब यह नहीं है कि प्रत्येक लेख में 22 स्वतंत्र रूप से अनुक्रमित भाषा पृष्ठ भी हैं।
यदि आपको भविष्य में खोज इंजनों द्वारा प्रत्येक भाषा परिवार को शामिल करने की अनुमति देने की आवश्यकता है, तो आपको भाषा परिवार रूटिंग, संबंधित स्थिर पृष्ठ और hreflang जोड़ने की आवश्यकता होगी। यह एक और आवश्यकता है जिसे यह सेट अभी तक पूरा नहीं करता है।
पोस्ट करना भी एक डिलीवरी प्रक्रिया है#
मेरी प्रकाशन प्रक्रिया है: मूल पाठ लिखें, अनुवाद तैयार करें, सामग्री की जांच करें, Git में सबमिट करें, और फिर इसे main में मर्ज करें। मौजूदा GitHub क्रियाएँ वेबसाइट का पुनर्निर्माण करेंगी और इसे तैनात करेंगी।
npm run content:localize
npm run content:check
npm run test:content
npm run build
अगर सभी भाषाओं के अनुवाद पूरे नहीं हैं, तो पहले उन्हें पूरा करता हूँ। Draft लेख स्थानीय preview में ही रहते हैं। Production output यह भी जाँचता है कि draft pages मौजूद न हों और feed, sitemap, homepage तथा JavaScript bundles जैसे प्रमुख सार्वजनिक artifacts में draft markers खोजता है। Code की तरह content के भी diffs और version history होते हैं, और उसे code के साथ वापस लिया जा सकता है।
यह विधि वास्तविक समय के अपडेट का त्याग करती है: यदि आप पाठ का एक टुकड़ा बदलते हैं, तो आपको तैनाती की प्रतीक्षा करनी होगी। लेकिन अपनी तकनीकी वेबसाइट के लिए, मैं एक कम बैकएंड, एक कम निष्पादन अवधि निर्भरता और एक परिवर्तन रिकॉर्ड के बदले में इस प्रतीक्षा का व्यापार करने को तैयार हूं जिसे ट्रैक करना आसान है।
ऐसा करना कब उचित है?#
यदि आप एक लेखक हैं, तो पोस्टिंग आवृत्ति का पुनर्निर्माण किया जा सकता है, सामग्री मुख्य रूप से पाठ है, और आप गिट के आदी हैं, यह वास्तुकला बहुत उपयुक्त है। लघु अद्यतन लेखन सीमा को कम करते हैं, लेख पूर्ण व्युत्पत्ति बरकरार रखता है, और बहु-भाषा समान सामग्री को अधिक लोगों द्वारा पढ़ने की अनुमति देती है।
यदि आवश्यकताएँ कई लोगों के बीच वास्तविक समय सहयोग, अनुमति प्रबंधन, पाठक टिप्पणियाँ, लॉगिन या सदस्यता बन जाती हैं, तो सीएमएस और बैकएंड का पुनर्मूल्यांकन करने की आवश्यकता है। शुद्ध फ्रंट-एंड इन जरूरतों को स्वचालित रूप से गायब नहीं करेगा, लेकिन मैंने उन्हें फिलहाल इस ब्लॉग के दायरे में नहीं रखा है।
इस बार के डिज़ाइन सिद्धांत मेरे द्वारा बहु-लेआउट और बहु-थीम आर्किटेक्चर डिज़ाइन पैटर्न में लिखे गए सिद्धांतों के बहुत करीब हैं: पहले जिम्मेदारियों को स्पष्ट रूप से अलग करें, और फिर साझा नियमों को स्थिरता बनाए रखें।
इस वेबसाइट के लिए, मुख्य बात यह है कि मुझे लिखते रहने और हर बार प्रकाशित होने पर यह जानने की अनुमति मिलती है कि वास्तव में कौन सी सामग्री वितरित की जा रही है।