डेटाबेस संचालित सामग्री का अनुवाद करने का सबसे अच्छा तरीका

Question

मैं थोड़ी देर के लिए इसके साथ संघर्ष कर रहा हूं। एक मेरा सीएमएस 'एक अनुवाद मॉड्यूल के साथ विस्तारित करने के लिए तैयार है। मैं विभिन्न तरीकों के बारे में सोच रहा हूं लेकिन अब तक यह पता नहीं लगाया गया कि अब तक का सबसे अच्छा तरीका क्या है।

असल में मेरे पास एक सीएमएस है जो डेटाबेस से सभी डेटा को स्क्रीन पर पार्स करने के लिए टेम्पलेट सिस्टम का उपयोग करता है। मैं अपने टेम्पलेट्स को अलग-अलग फ़ोल्डर्स में "विभाजित" करने के लिए अभी तक आया हूं, जो पाठ, पाद लेख, इत्यादि जैसी छवियों जैसे "स्थैतिक" हैं।

हालांकि, कई मॉड्यूल (पेज, समाचार, उत्पाद) जिनमें कई फ़ील्ड हैं जिन्हें डेटाबेस संचालित विधि का अनुवाद करने की आवश्यकता होती है। मैंने एक "भाषा" तालिका से शुरुआत की जो भाषाओं (आईडी, iso_code, नाम) का वर्णन करता है। जहां तक ​​मैं आया हूं .. चूंकि वहां कुछ परियोजनाएं की जानी थीं, इसलिए मैंने इस विषय में अब तक कोई और समय नहीं व्यतीत किया है।

मेरा पहला विचार ("त्वरित फिक्स") टेबल के अंदर कई फ़ील्ड (जैसे "title_nl", "title_en") जोड़ना था, लेकिन यह वास्तव में डेटाबेस को मेरी राय में आवश्यकतानुसार अधिक भीड़ बनाता है।

मेरा दूसरा विचार उदाहरण के लिए, "news_translations" तालिका बनाना था। जिसमें भाषा आईएसओ कोड, एक news_id, फ़ील्ड जिसमें अनुवाद की आवश्यकता होती है। स्पष्ट रूप से एक news_id अनुवाद को इसके मूल से जोड़ता है और भाषा आईएसओ कोड डेटाबेस से सही भाषा प्राप्त करने के लिए उपयोग किया जाता है। फिर मेरे फ्रंट-एंड कोड में मैं पहली बार जांचता हूं कि डिफ़ॉल्ट भाषा का चयन किया गया है (=> "समाचार" तालिका से चुनें) या एक अनुवाद (=> अनुवाद तालिका के अंदर जांचें)। यदि दूसरा मामला कोई परिणाम नहीं लौटाता है तो एक संदेश प्रदर्शित होता है "क्षमा करें, कोई अनुवाद उपलब्ध नहीं है" और डिफ़ॉल्ट दिखाया गया है (या एक त्रुटि संदेश, जो क्लाइंट को सबसे अच्छा फिट करता है ..)।

लेकिन फिर एक तीसरा विकल्प है .. मेरी वेबसाइट सभी खोज इंजन अनुकूल लिंक (www.domain.com/pagename/ या www.domain.com/news/1-news-item-here.html) का उपयोग करती हैं। यदि मेरे अनुवाद तालिका में एसईएफ यूआरएल को "ओवरराइड" करने की क्षमता भी थी तो यह बहुत बेहतर होगा। लेकिन मुझे लगता है कि इस मामले में मुझे हमेशा अनुवाद तालिका में 1 अतिरिक्त क्वेरी की आवश्यकता होगी (क्योंकि हम पहले अनुवादित पृष्ठ की जांच करना चाहते हैं) ... अनुमान लगाएं कि यह इतना बड़ा सौदा नहीं है, लेकिन मुझे लगता है कि यह अनुमान लगाने योग्य है।

अंत में मुझे लगता है कि मेरे विकल्प संख्या 3 का वर्णन करके मुझे क्या चाहिए। लेकिन मैं इस विषय पर कुछ अन्य राय भी लेना चाहता हूं!

• बहु भाषा समर्थन
• भाषा उपलब्ध नहीं है फ़ाइलें (जाहिर है यही कारण है कि मैं टेम्पलेट का उपयोग)
• एक मूल पृष्ठ का अनुवाद करने में सक्षम होने के नाते/newsitem के साथ एक सीएमएस प्रणाली बनाएं: यह मैं क्या हासिल करने की कोशिश कर रहा हूँ/उत्पाद
• वैकल्पिक: भाषा के अनुसार SEF का URL बदल

मुझे लगता है कि विकल्प 3 सभी इस .. तो यह समाधान बनाने के लिए चरणों है:

में हालांकि .. -

1. एक _translation तालिका 2 नए क्षेत्रों 'translation_to' ( PrimaryKey युक्त) और 'translation_is' (आईएसओ कोड युक्त) जोड़कर भी मूल में शायद प्रत्येक आइटम के लिए बनाएँ (या उस स्थिति में सभी फ़ील्ड को संपादित करने की आवश्यकता होगी (जो हमेशा आवश्यक नहीं है .. साथ ही दूसरी तालिका बनाकर मैं मूल अपने अनुवादों के साथ विभाजित रखता हूं, है ना?)

2. यदि डिफ़ॉल्ट भाषा का चयन नहीं किया गया है तो अनुवाद को खोजने के लिए अनुवाद तालिका पहले पूछताछ करें, यदि कोई पाया जाता है तो अनुवाद प्रदर्शित करता है। अन्यथा उपयोगकर्ता को सूचित/त्रुटि दें और/या मूल पाठ (एसईएफ यूआरएल के आधार पर ... यदि एसईएफ को अनुवाद या मूल तालिका में नहीं मिला है, तो स्पष्ट रूप से केवल त्रुटि प्रदर्शित करें)।

कोई सुझाव? :-)

साथ सोचने के लिए धन्यवाद!

Answer 1

मैं देखना चाहता हूं कि आपकी तालिका संरचना कैसी दिखती है। संभवतः सबसे अच्छी चीज जो आप कर सकते हैं वह दो अलग-अलग नई टेबल उत्पन्न करती है जैसे "CONTENT_MULTI_LANG" & "SITE_LOCALES"।

फिर कोड में जो आपकी सामग्री को प्रिंट करता है, एक भाषा ध्वज के लिए प्रारंभिक जांच करता है। मैं स्थैतिक सामग्री लोड करने के लिए दो अलग-अलग वर्ग बनाएगा, जैसे कि "सामग्री_लोड मानक" और "सामग्री_लोड मैल्टीआईलांग"। तो फिर आपकी सशर्त इस तरह दिखेगी।

if ($this->site_locale == 'standard'){ 
    $contentLoader = new Content_LoadStandard(); 
} else { 
    $contentLoader = new Content_LoadMultiLang($this->site_locale); 
} 

$content->blah($cheese); 

आपका "CONTENT_MULTI_LANG" तालिका अपने मानक सीएमएस वस्तु तालिका का एक संकुचित संस्करण होना चाहिए, केवल प्रासंगिक सामग्री क्षेत्र (रों) वैकल्पिक भाषाओं में होने की जरूरत है कि युक्त।

// PSEUDO SQL 
    CREATE TABLE `LOCALE` (
     `id` int(11), 
     `locale` varchar(16), // name of locale (language) 
     ...    // any other fields 
) 

    CREATE TABLE `CONTENT_MULTI_LANG` (
     `id` int(11), 
     `pcid` int(11), // parent content id 
     `lid` medint(), // locale id 
     `content` {$type}, // whatever type you use (varchar, text, bin, etc) 
     ...    // any other fields 
) 

अपने Content_LoadMultiLang कक्षा में, एक में शामिल होने का उपयोग कर वैकल्पिक सामग्री क्वेरी करने के लिए तरीकों पैदा करते हैं।

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

Answer 2

मैंने ड्रूपल से जो देखा है, उससे तीन विकल्प यह है कि वे दो बदलावों के साथ इसे कैसे संभालेंगे। वे इसे एक टेबल में रखते हैं और भाषा कहा जाता है। फिर एक अलग टेबल है जो मानचित्र करता है कि कौन से आइटम जुड़े हुए हैं।

इस तरह प्राथमिक भाषा अज्ञेयवादी है, जिसका अर्थ है कि सामग्री किसी भी भाषा में किसी अन्य भाषा में अनुवाद किए बिना बनाई जा सकती है।