← सभी लेख

दो कंटेंट ट्रीज़ को बनाए रखे बिना द्विभाषी साइट को शिप करना

कैसे बिल्ड-टाइम डेटा पाइपलाइन भाषा मार्गों में अनुवाद ड्रिफ्ट को रोकती हैं।

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

एकल सत्य स्रोत

/content/en और /content/hi जैसी अलग-अलग मार्कडाउन फ़ोल्डर्स बनाने के बजाय, प्राथमिक कंटेंट को एकीकृत फ़ॉर्मेट में संग्रहीत करें और अनुवादों को बिल्ड-टाइम ट्रांसफ़ॉर्मेशन चरण के रूप में प्रोसेस करें।

{
  "slug": "bilingual-site-without-two-trees",
  "title": "Shipping a bilingual site...",
  "translated": false
}

स्वचालित बिल्ड-टाइम अनुवाद पाइपलाइन

next build चलाने से पहले, एक हल्का Node स्क्रिप्ट आपके स्रोत पोस्टों की जाँच करता है। translated: false के रूप में चिह्नित कोई भी एंट्री LLM API के माध्यम से प्रोसेस की जाती है ताकि संबंधित अनुवाद डेटा फ़ाइल उत्पन्न की जा सके।

// scripts/generate-translations.ts
import dotenv from 'dotenv';
dotenv.config({ path: '.env.local' });

async function translatePosts() {
  const unhandled = posts.filter(p => !p.translated);
  for (const post of unhandled) {
    const translatedData = await translateWithLLM(post);
    saveHindiTranslation(post.slug, translatedData);
  }
}

एकीकृत घटक वास्तुकला

lang द्वारा अपने रूटिंग और टेम्प्लेट घटकों को पैरामीटराइज़ करके, एकल Next.js टेम्प्लेट पेज दोनों /posts/[slug] और /hi/posts/[slug] को रेंडर करता है। दोनों रूट समान टाइपोग्राफी, लेआउट नियम और SEO लॉजिक साझा करते हैं, जबकि लोकेल‑मैच्ड डेटा डिक्शनरी को संदर्भित करते हैं।