बहुभाषी PHP वेबसाइट

Question

के लिए सबसे प्रभावी दृष्टिकोण मैं एक बड़ी बहुभाषी वेबसाइट पर काम कर रहा हूं और मैं इसे बहुभाषी बनाने के लिए विभिन्न दृष्टिकोणों पर विचार कर रहा हूं। संभव विकल्पों मैं के बारे में सोच सकते हैं:

1. पुलिस फाइलों
की पीढ़ी के साथ Gettext कार्यों
2. अनुवाद और एक अद्वितीय स्ट्रिंग आईडी प्रत्येक पाठ के लिए सरणियों युक्त
3. पीएचपी-फाइलों के साथ एक MySQL तालिका अद्वितीय स्ट्रिंग आईडी
के साथ अलग अलग अनुवाद

जहां तक ​​मैं समझ गया है gettext कार्यों सबसे कुशल होना चाहिए, लेकिन मेरी आवश्यकता है कि यह मूल संदर्भ भाषा (अंग्रेजी) के साथ में एक पाठ स्ट्रिंग परिवर्तित करने के लिए संभव हो जाना चाहिए है उस स्ट्रिंग के अन्य अनुवाद स्वचालित रूप से वापस अंग्रेजी में वापस लौट रहे हैं क्योंकि कुछ शब्द बदल गए हैं। गेटटेक्स्ट के साथ यह संभव है?

कम से कम संसाधन मांग समाधान क्या है?
गेटटेक्स्ट फ़ंक्शंस या PHP फ़ाइलों का उपयोग सरणी के साथ समान या कम समान संसाधन मांग के साथ कर रहा है?
अधिक कुशल समाधान के लिए कोई अन्य सुझाव?

Answer 1

कुछ विचार:

1. अनुवाद
अनुवाद कौन कर रही होगी? वे लोग जो साइट से जुड़े हुए हैं? एक अनुवाद एजेंसी? गेटटेक्स्ट का उपयोग करते समय आप 'पॉट' (.po) फ़ाइलों के साथ काम करेंगे। इन फ़ाइलों में संदेश आईडी और संदेश स्ट्रिंग (अनुवाद) शामिल है। उदाहरण:

msgid "A string to be translated would go here" 
msgstr ""

अब, यह ठीक है और जो कोई भी इस का अनुवाद करने की जरूरत के लिए समझ में आता लग रहा है। लेकिन क्या होता है जब आप कीवर्ड का उपयोग करते हैं, जैसे माइक सुझाव देता है, पूर्ण वाक्यों के बजाय? अगर किसी को "address_home" नामक अनुवाद करने की आवश्यकता है, तो उसके पास कोई सुराग नहीं है यदि यह शीर्षलेख "होम एड्रेस" होना चाहिए या यह एक पूर्ण वाक्य है।

/// This is a comment that will be included in the pot file for the translators 
gettext("ready_for_lost_episode"); 

जब पुलिस फाइलों बनाने इन टिप्पणियों जोड़ देगा xgettext --add-comments=/// का उपयोग करना: इस मामले में, फ़ाइल पर राइट इससे पहले कि आप gettext समारोह पर कॉल करने के लिए टिप्पणी जोड़ने की है, तो तरह सुनिश्चित करें। हालांकि, मुझे नहीं लगता कि गेटटेक्स्ट इस तरह इस्तेमाल किया जा रहा है। साथ ही, यदि आपको प्रत्येक टेक्स्ट के साथ टिप्पणियां जोड़ने की आवश्यकता है, तो आप जो प्रदर्शित करना चाहते हैं, वह आप करेंगे) शायद किसी बिंदु पर एक त्रुटि करें, बी) आप पूरी स्क्रिप्ट किसी भी तरह से ग्रंथों से भर जाएंगे, केवल टिप्पणी फ़ॉर्म में, सी) टिप्पणियों को सीधे गेटटेक्स्ट फ़ंक्शन के ऊपर रखा जाना चाहिए, जो आपके कोड में फ़ंक्शन की स्थिति के आधार पर हमेशा विश्वसनीय नहीं होता है।

2।रखरखाव
आपकी साइट बढ़ने के बाद (यहां तक ​​कि आगे) और आपकी भाषा फाइलें इसके साथ-साथ सभी अलग-अलग अनुवादों को बनाए रखने में काफी मुश्किल हो सकती हैं। प्रत्येक बार जब आप कोई टेक्स्ट जोड़ते हैं, तो आपको नई फाइलें बनाने, अनुवादकों को फाइल भेजने, फ़ाइलों को वापस प्राप्त करने, सुनिश्चित करने के लिए कि संरचना अभी भी बरकरार है (उत्सुक अनुवादक हमेशा वाक्यविन्यास का अनुवाद करने में खुश रहते हैं, पूरी फ़ाइल बनाते हैं अनुपयोगी :)), और नए अनुवादों को आयात करने के साथ खत्म करें। यह करने योग्य, निश्चित है, लेकिन इस साइट पर बड़ी साइटों और कई अलग-अलग भाषाओं के साथ संभावित समस्याओं से अवगत रहें।

---

एक अन्य विकल्प:

व्यक्तिगत रूप से, मैं इसे और अधिक उपयोगी एक डेटाबेस और निर्यात में, एक (सरल) सीएमएस का उपयोग कर चर और अनुवाद रखने अनुवाद प्रबंधन करने के लिए लगता है: अपने 2 और 3 विकल्प गठबंधन खुद को भाषा फाइलों के लिए रिलीज ग्रंथ:

1. डेटाबेस में चर जोड़ें (उदाहरण: आईडी, पेज, चर);
2. इन चरों में अनुवाद जोड़ें (उदा .: आईडी, varId, भाषा, अनुवाद);
3. प्रासंगिक चर और अनुवाद का चयन करें, उन्हें एक फ़ाइल में लिखें;
4. आपकी साइट में प्रासंगिक भाषा फ़ाइल शामिल करें;
5. एक चर पाठ प्रदर्शित करने के लिए अपने स्वयं के समारोह बनाने के लिए:

text('var'); या हो सकता है की तरह __('faq','register','lost_password_text');

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

लाभ:

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

2. अनुवाद। आप एक ही पृष्ठ पर सभी अलग-अलग भाषाओं के सभी अनुवादों के साथ चर प्रदर्शित कर सकते हैं। यह उन लोगों के लिए उपयोगी हो सकता है जो ग्रंथों को एक ही समय में कई भाषाओं में अनुवाद कर सकते हैं। और संदर्भ के लिए एक महसूस करने के लिए अन्य अनुवादों को देखना उपयोगी हो सकता है ताकि अनुवाद जितना संभव हो सके उतना अच्छा हो। आप यह जानने के लिए डेटाबेस से पूछ सकते हैं कि क्या अनुवाद किया गया है और क्या नहीं है। संभवतः पुराने पुराने अनुवादों का ट्रैक रखने के लिए टाइमस्टैम्प जोड़ें।

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

सब कुछ मुझे लगता है कि आपको लगता है कि आप इस तरह के अनुवादों पर विशेष रूप से लंबे समय तक अधिक नियंत्रण प्राप्त करेंगे। मैं देशी गेटटेक्स्ट फ़ंक्शन की तुलना में इस दृष्टिकोण की गति या दक्षता के बारे में कुछ भी नहीं बता सकता। लेकिन, भाषा फ़ाइलों के आकार के आधार पर, मुझे नहीं लगता कि यह एक बड़ा अंतर होगा। यदि आप पृष्ठ या अनुभाग द्वारा चर समूहबद्ध करते हैं, तो आप हमेशा आवश्यक भागों को शामिल कर सकते हैं।

Answer 2

बल्कि कुंजी के रूप में अंग्रेजी पाठ का उपयोग करने की तुलना में आप मनमाने ढंग से ऐसा कर सकता है, लेकिन यह भी प्रदान अंग्रेज़ी अनुवाद यानी

gettext कुंजी है 'हैलो'

फिर आप इस के अपने विभिन्न भाषा अनुवाद किया है और इसका एक अंग्रेजी अनुवाद भी 'हैलो' है, फिर यदि आप स्ट्रिंग के अंग्रेजी संस्करण को अपडेट करना चाहते हैं तो आप अकेले कुंजी छोड़ सकते हैं और केवल अंग्रेज़ी अनुवाद अपडेट कर सकते हैं।

Answer 3

कुछ परीक्षणों के बाद मैंने आखिरकार दूसरे और तीसरे विकल्प के एलेक्स के संयोजन की लाइनों के साथ कम या ज्यादा जाने का फैसला किया।

gettext समस्या
मैं इसे आज़माने के लिए पहले पूरे gettext-प्रणाली स्थापित करने की कोशिश की है, लेकिन यह पता चला और अधिक जटिल होने के लिए तो मैंने सोचा। समस्या यह है कि Windows और यूनिक्स सिस्टम setlocale() के लिए अलग-अलग भाषा शॉर्टनाम का उपयोग करते हैं। फिलहाल मैं Wamp के साथ विंडोज़ पर अपना देव-सर्वर चला रहा हूं, जबकि अंतिम साइट लिनक्स पर चलती है। कुछ dozenguides, forums, questions आदि के माध्यम से जाने के बाद और प्रत्येक संशोधन के बाद सर्वर को पुनरारंभ करने के बाद। मैं इसे किसी भी आसान तरीके से ठीक से सेटअप नहीं कर सका। इसके अतिरिक्त गेटसेक्स्ट थ्रेडसेफ नहीं है, जिस भाषा फ़ाइल को सर्वर को पुनरारंभ करने की आवश्यकता है उसे अपडेट करने के लिए या a hack का उपयोग करने की आवश्यकता है, भाषा फ़ाइलों के विभिन्न संस्करणों को संभालने या स्रोत को संशोधित किए बिना मूल अंग्रेजी पाठ को संभालने का कोई आसान तरीका नहीं है या माइक सुझाव का उपयोग कर , जैसा कि एलेक ने बताया है इष्टतम नहीं है।

समाधान
तो मैं मैं क्या सोचता सबसे अच्छा Alecs प्रतिक्रिया के आधार पर हल है के साथ समाप्त हो गया:

• सहेजें सभी क्षेत्रों के साथ एक DB में अनुवाद; भाषा, पेज, var_key, संस्करण, संशोधन और last_modified_time - जहां संस्करण मूल अनुवाद (अंग्रेज़ी) के संस्करणों के अनुरूप है, जबकि संशोधन अनुवादक को संस्करण के भीतर अंतिम अनुवाद को संशोधित/सही करने की अनुमति देता है।
• अनुवाद के लिए एक प्रकार का सीएमएस का उपयोग करें, जो डीबी से जुड़ा हुआ है और विभिन्न संस्करणों को संभालता है और किस भाषा का अनुवाद किया जाता है, इसका एक आसान अवलोकन करने के लिए अनुमति देता है, जिसमें संस्करण और अनुवाद कितने पूर्ण होते हैं।
• जब किसी संस्करण का संशोधन अंतिम रूप दिया जाता है तो कैश फाइलें उत्पन्न होती हैं - प्रत्येक फ़ाइल में एक भाषा और एक पृष्ठ के लिए केवल var_key और टेक्स्ट-अनुवाद के साथ एक सरणी होती है और इसे ISO 639-1 भाषाओं के नाम और पृष्ठ का नाम दिया जाता है जैसे: lang/en_index.php इन भाषा फ़ाइलों को तब फ़ंक्शन टी ($ var_key) में बस शामिल और लपेटा जाता है जो विकास के दौरान डीबी का उपयोग करने की अनुमति देता है, जबकि तब केवल कैश फ़ाइलों का उपयोग करने के लिए बदल जाता है।

प्रदर्शन
मैं कभी नहीं आसपास gettext परीक्षण करने के लिए है, लेकिन the link Mike posted के अनुसार एक सरणी का उपयोग करने और gettext के बीच प्रदर्शन में अंतर पूरी तरह से लाभ जो एक कस्टम प्रणाली के रूप में ऊपर वर्णित देता है के लिए मेरे लिए स्वीकार्य है। हालांकि, मैंने MySQL DB से उसी 20 टेक्स्ट-स्ट्रिंग को पुनर्प्राप्त करने की तुलना में सरणी में 20 अनुवादित टेक्स्ट-स्ट्रिंग के साथ एक सरणी का उपयोग करने की तुलना की। यह पता चला कि फ़ाइल से शामिल एक सरणी का उपयोग करके 6 गुना तेज एक ही समय में सभी 20 स्ट्रिंग्स को MySQL डीबी से पुनर्प्राप्त करने से पहले था।यह वास्तव में वैज्ञानिक बेंचमार्क नहीं था और परिणाम निश्चित रूप से विभिन्न प्रणालियों और सेटअप पर भिन्न हो सकते हैं, लेकिन यह स्पष्ट रूप से दिखाता है कि मुझे क्या उम्मीद है - यह एक सरणी का उपयोग करने से डीबी का उपयोग करके बहुत धीमा होगा, इसलिए मैं कैश उत्पन्न करना चुनता हूं डीबी का उपयोग करने के बजाय सरणी के लिए फाइलें।

तुलना के रूप में मैंने यह भी परीक्षण किया कि यह केवल उसी पाठ के साथ सरल ईकोस को आउटपुट करना कितना तेज़ था। यह एक शामिल फ़ाइल से सरणी का उपयोग करने से लगभग 20 गुना तेज हो गया, लेकिन अच्छी तरह से - तो अलग-अलग भाषाओं के लिए पृष्ठ के विभिन्न संस्करणों के बिना अनुवाद करना संभव नहीं है, जो गतिशील पृष्ठों के उद्देश्य को अस्वीकार करता है। फिर a good cachesystem का उपयोग करना बेहतर है।

प्रदर्शन परीक्षण स्रोत फ़ाइलें:
पीएचपी: http://pastie.org/964082
MySQL तालिका: http://pastie.org/964115
यह निश्चित रूप से सही नहीं है, लेकिन कम से कम प्रदर्शन मतभेदों के बारे में एक विचार पैदा करता है।