सिद्धांत 2 - i18n के लिए सर्वोत्तम प्रथाओं?

Question

मैं कुछ ऐसे टेबलों को संभालने के बारे में सलाह देता हूं जिनके पास फ़ील्ड रखने की आवश्यकता है जिन्हें एन भाषाओं में अनुवादित किया जाना चाहिए। मैंने पढ़ा है कि एक आधार-सारणी रखने का सबसे अच्छा तरीका है जिसमें सभी फ़ील्ड हैं जो भाषा विशिष्ट नहीं हैं और एक तालिका है जो अनुवाद के साथ सभी फ़ील्ड रखती है।

उदाहरण:

 

PRODUCT    PRODUCT_TRANSLATIONS 
+--------------+ +----------------------+ 
| id   | | id     | 
+--------------+ +----------------------+ 
| category_id | | product_id   | 
+--------------+ +----------------------+ 
| price  | | language_id   | 
+--------------+ +----------------------+ 
        | name     | 
        +----------------------+ 
        | description   | 
        +----------------------+ 

तो हम आधार तालिका उत्पाद है कि सभी मेटा डेटा रखती है और एक PRODUCT_TRANSLATIONS तालिका जहां कि सभी डेटा की जरूरत संग्रहीत किया जाता है होगा कई भाषाओं में अनुवाद करने की। PRODUCT तालिका में PRODUCT_TRANSLATIONS तालिका के लिए एक बहुत ही रिश्ते है।

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

बीटीडब्ल्यू: मुझे जीडीमिनास द्वारा अनुवादनीय व्यवहार विस्तार से अवगत है, लेकिन मुझे यह तथ्य पसंद नहीं है कि सभी अनुवाद एक तालिका में संग्रहीत हैं।

तो अंतर्राष्ट्रीयकरण की बात आती है तो मैं किसी भी सर्वोत्तम प्रथा की तलाश में हूं। इस विषय पर किसी भी विचार की अत्यधिक सराहना की जाती है।

Answer 1

आपके द्वारा वर्णित अनुवाद योग्य व्यवहार एक्सटेंशन प्रति-वर्ग अनुवाद इकाई की अनुमति देता है। translatable doc के उन्नत उदाहरण अनुभाग के अंतर्गत "अनुवाद इकाई" उपशीर्षक देखें।

इसका संक्षिप्त विवरण यह है: अनुवादों को संग्रहीत करने के लिए उपयोग की जाने वाली किसी विशेष इकाई को निर्दिष्ट करने के लिए @Gedmo\TranslationEntity एनोटेशन का उपयोग करें। इस तरह, आप भार को कई तालिकाओं में विभाजित कर सकते हैं।

Answer 2

Btw: मैं मैं तथ्य यह है कि सभी अनुवाद एक तालिका में जमा हो जाती है पसंद नहीं है Gediminas लेकिन द्वारा अनुवाद का व्यवहार विस्तार के बारे में पता कर रहा हूँ।

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

/** 
* @var array 
* 
* @ORM\Column(name="title", type="array", nullable=true) 
*/ 
private $title; 

यदि आपका सिस्टम की सामग्री पूरी तरह से एक भाषा से दूसरी करने के लिए अलग है या आपके सिस्टम की जरूरत है कुछ भारी प्रश्नों और रिपोर्ट उन बहु भाषा क्षेत्रों के आधार पर तो दृष्टिकोण आप का उल्लेख अच्छा होगा।