वेब एप्लिकेशन पर स्थानीयकरण कैसे करें?

Question

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

लेकिन क्या स्थानीयकरण करने का कोई तरीका लचीला या सुझाव दिया गया है? धन्यवाद।

Answer 1

ऐसा लगता है कि आप वास्तव में क्या पूछ रहे हैं: स्थानीयकरण को सही ढंग से कैसे कार्यान्वित करें? या एप्लिकेशन को स्थानीयकृत करना आसान बनाने के लिए प्रोग्राम कैसे करें।

वास्तव में यह अंतर्राष्ट्रीयकरण से संबंधित प्रश्न है। वहाँ कई चीजें आप क्रम में ध्यान में रखने की जरूरत है अपने आवेदन स्थानीय बनाना आसान बनाने के लिए कर रहे हैं:

• तार हार्डकोड न करें (है कि एक स्पष्ट है)
• जानकारी (प्रारूपण टैग का प्रयोग नहीं करते स्टाइल को हार्डकोड न करें < बी >, <i>, < मजबूत >, आदि; इसका उपयोग न करें: <p style="font-weight: bold;color: green;">Success!</p>)। यह स्थानीयकरण लोगों को उन्हें संशोधित करने से रोक देगा (यानी सीजेकेवी अनुवादों से बोल्ड किए गए पाठ को हटाकर)
• कंपाउंड संदेशों (जैसे "फंक्शन [ए, बी, सी] [ए, बी, सी]" का उपयोग करने से बचें। वे सही ढंग से अनुवाद करने के लिए बहुत मुश्किल हैं। यदि आपके पास बहुत सारे चर नहीं हैं तो संसाधनों में कुछ और स्ट्रिंग जोड़ने में कोई दिक्कत नहीं होगी।
• या तो CONCATENATE ऑपरेटर के साथ या सिर्फ एक दूसरे के बगल तार रखकर यौगिक संदेशों को श्रेणीबद्ध नहीं है (अर्थात ऐसा नहीं करते हैं: String message = "Function " + function + " does " + whatItDoes; या इस: #{['something']}<a href="whatever">#{['some_link']}</a>#{['something_else']}), बजाय स्वरूपण उपयोग (अर्थात MessageFormat.format("Hello, {0}. You have {1} new messages.", name, mailCount);)। यह अनुवादक को वाक्य को दोबारा आदेश देने की अनुमति नहीं देगा और लक्ष्य की भाषा व्याकरण नियमों के कारण इसकी आवश्यकता हो सकती है।
• कच्चे प्लेसहोल्डर (जैसे% s% i% u) का उपयोग न करें यदि आपके पास उस वाक्य में से एक से अधिक वाक्य हैं (यह वास्तव में क्रमांकित प्लेसहोल्डर जैसे {0}, {1} का उपयोग करना बेहतर है)। दोबारा, कभी-कभी अनुवादकों को वाक्य को फिर से व्यवस्थित करने की आवश्यकता होती है ...
• अंग्रेजी के लिए विशिष्ट भाषा संरचनाओं का उपयोग न करें (यानी "Paweł का डैशबोर्ड" जहां Paweł पंजीकरण के दौरान प्रदान किया गया एक नाम है)।कई भाषाओं

इसके अलावा, वहाँ काम करने के लिए कर रहे हैं करने के लिए सही ढंग से अनुवाद करने का कोई तरीका नहीं है:

• (स्थानीयकरण लोग तत्व की शैली को संशोधित कर सकता है तो) शैली पत्रक ओवरराइड तंत्र प्रदान
• करें प्रस्तुत एचटीएमएल पेज के प्रत्येक तत्व के लिए अद्वितीय आईडी असाइन करें (इससे उन्हें अपने ओवरराइड शैली के साथ सटीक नियंत्रण को लक्षित करने की अनुमति मिल जाएगी)
• जहां भी आप कर सकते हैं यूटीएफ -8 एन्कोडिंग का उपयोग करें (जाहिर है एचटीएमएल पेज, यदि कोई हो तो ई-मेल, लेकिन संभवतः संसाधन फाइलें [यानी गुण] साथ ही)

वहाँ भी बहुत कुछ स्वरूपण और नंबर, मुद्राओं, दिनांक (उचित समय क्षेत्र सेट करने सहित) है कि आप ठीक ढंग से भूमंडलीकृत आवेदन में के बारे में परवाह करने की आवश्यकता होगी मान्य भाषा पहचान कार्यप्रवाह की तरह localizability से संबंधित नहीं बातें,, है, लेकिन यह वास्तव में है अलग कहानी।

Answer 2

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

जहां तक ​​लोकेल का पता चलता है, वहां करने के दो तरीके हैं; ऑटो-डिटेक्शन, जो वेब अनुप्रयोगों और चयन आधारित तंत्र द्वारा उपयोग की जाने वाली एक आम आम तंत्र है जो उपयोगकर्ता को प्रदान की गई लोकेल ड्रॉप-डाउन के साथ ऑटो-डिटेक्शन के संयोजन का उपयोग करती है।

विशिष्ट कदम भाषा/ढांचे विशिष्ट होंगे ताकि आप विशिष्ट उत्तर के लिए उपयोग किए जा रहे ढांचे का उल्लेख करना चाहें।

Answer 3

दूसरी तरफ, यदि आप वास्तव में अनुवाद करने योग्य संसाधनों को निकालने के लिए कह रहे हैं, तो मुझे एक पूरी तरह से अलग जवाब देना होगा।

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

क्लाइंट साइड पर स्थानीयकरण के परिणामस्वरूप बहुत धीमी गति से आवेदन होगा, ऐसा न करें। लोग इसे नफरत करेंगे।

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