इससे निपटने के कई तरीके हैं। उनमें से कोई भी "सबसे अच्छा तरीका" नहीं है और उनमें से सभी अल्पावधि या लंबी अवधि में समस्याओं के साथ हैं। कहने वाली पहली बात यह है कि बहुभाषी साइटें आसान नहीं हैं, अनुवादक और प्यारे लोग हैं लेकिन उनके साथ काम करना कठिन है और अधिकांश प्रोग्रामर समस्या को केवल तकनीकी के रूप में देखते हैं। इस उत्तर के दायरे से बाहर एक और आयाम भी है, जैसे कि आप अनुवाद कर रहे हैं या स्थानीयकरण कर रहे हैं। इसमें लक्षित दर्शकों के सांस्कृतिक रीति-रिवाजों को देखना और फिर उस संस्कृति के लिए भाषा, शैली, लेआउट, रंग, टाइपफेस आदि को तैयार करना शामिल है। अंत में एमटी, मशीनी अनुवाद का उपयोग किसी गंभीर बात के लिए न करें या यदि इसे सटीक होने की आवश्यकता है और अनुवादकों को प्राप्त करते समय यह सुनिश्चित करें कि वे एक विदेशी भाषा से अपनी मूल भाषा में अनुवाद कर रहे हैं, जिसका अर्थ है कि वे लक्षित भाषा की सभी बारीकियों को समझते हैं।
सही। समाधान। इस आधार पर कि आप साइट को फिर से लिखना नहीं चाहते हैं, तो बस आपके पास मौजूद साइट को क्लोन करें और प्रतियों को लक्षित भाषा में अनुवाद करें। कोड आधार को स्थिर मानते हुए आप किसी भी कोड परिवर्तन को प्रबंधित करने के लिए VCS का उपयोग कर सकते हैं। आप लक्ष्य भाषा में फिट होने के लिए साइट के अलग-अलग हिस्सों को बदल सकते हैं, उदाहरण के लिए फ्रांसीसी टेक्स्ट समकक्ष अंग्रेजी टेक्स्ट से औसतन 30% बड़ा है, इसलिए इसे वितरित करने के लिए एक साइट का उपयोग करने का मतलब है कि आपको स्वरूपण समस्याएं हो सकती हैं और आपको स्वैप करने की आवश्यकता हो सकती है भाषा के आधार पर अलग-अलग सीएसएस फ़ाइल अंदर और बाहर। ऐसा करने का यह एक भद्दा तरीका लग सकता है लेकिन फिर साइटें कब तक मौजूद रहेंगी? इसे इस तरह से करने का प्रबंधन ओवरहेड अन्य विकल्पों की तुलना में कम हो सकता है।
पुनर्निर्माण के बिना दूसरा तरीका। वर्तमान साइट में सभी सामग्री को टैग से बदलें और फिर फ़ाइल या डीबी टेबल में अलग-अलग भाषा डालें, उपयोगकर्ताओं की वांछित भाषा को सूंघें (क्या आपके पास पंजीकृत उपयोगकर्ता हैं जो वरीयता दे सकते हैं या आप ब्राउज़र भाषा टैग प्राप्त करना चाहते हैं, या है यह URL dot-com dot-fr, dot-de होगा जो चुनाव करेगा) और फिर टैग को लक्ष्य भाषा से बदलें। फिर आपको आकार के मुद्दों और छवि के मुद्दों को अलग से संबोधित करने की आवश्यकता है। यह समाधान तब प्रभावी होता है जब सिम्फनी और ज़ेंड जैसे ढांचे l10n को लागू करने के लिए करते हैं।
फिर आप एक ढांचे के साथ या गेटटेक्स्ट के साथ पुनर्निर्माण कर सकते हैं और संभवतः एक क्लीनर समाधान प्राप्त कर सकते हैं लेकिन याद रखें कि ढांचे को अन्य समस्याओं को हल करने के लिए डिज़ाइन किया गया था, अनुवाद नहीं और अनुवाद घटक आंशिक समाधान के रूप में ढांचे में आ गया है।
सभी समाधानों के साथ बड़ी समस्या निरंतर रखरखाव है। क्योंकि न केवल आपके पास कोड आधार है, बल्कि बनाए रखने के लिए कई भाषा आधार भी हैं। जब तक आप सभी एक समाधान में वास्तव में चतुर और प्रभावी नहीं हैं, तब तक चल रहे कार्य कठिन होंगे।
