एमएफसी

Question

में अंतर्राष्ट्रीयकरण अंततः (पोस्टिंग के वर्षों के बाद) मेरे ऐप को अंग्रेजी के अलावा कुछ अन्य भाषाओं में स्थानांतरित करने का समय है।

पहली चुनौती है मेरे सी ++/एमएफसी अनुप्रयोग में एकीकरण को डिजाइन करना जिसमें दर्जनों संवाद और अनगिनत तार हैं। मैं दो संभावित विकल्प के कार्यान्वयन में आए:

1. संकलित करें और DLLs के रूप में स्थानीय संसाधन फ़ाइलों को तैनात
2. निकालें और स्थानीय संस्करण के साथ सभी तार की जगह। प्रत्येक भाषा के लिए एक एक्सएमएल (या सरल पाठ) फ़ाइल होगी।

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

किसी भी सलाह की सराहना की जाती है।

सादर,
कॉस्मिन Unguru
http://www.batchphoto.com/

Answer 1

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

कारण हैं:

(1) उपयोगकर्ता एक XCOPY स्थापित करता है, वह हमेशा मुख्य निष्पादनयोग्य में डिफ़ॉल्ट भाषा (अंग्रेजी) है।

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

(3) मेरी बहुत ही राय राय: (ए) एक्सएमएल फाइलों में लाइन ब्रेक, टैब, व्हाइटस्पेस आपके ** में दर्द है। (बी) एक्सएमएल फाइलों को विलय करना और भी बदतर है ...

(4) एन्कोडिंग को न भूलें। यह एक्सएमएल में ठीक है लेकिन आपके अनुवादक एक अनुपयुक्त संपादक का उपयोग कर सकते हैं और फ़ाइल को नुकसान पहुंचा सकते हैं।

और अब मुख्य कारण के लिए:

(5) क्योंकि कई तार कर रहे हैं आप अपने संवादों के कई को पुनर्व्यवस्थित करना होगा लंबे समय तक में उदा अंग्रेजी से फ्रेंच या जर्मन। और सभी statics, बटन, ... बड़ा "बस मामले में" बकवास लग रहा है।

एक और संकेत: कुछ रुपये खर्च करें और अनुवाद परियोजनाओं में से एक खरीदें जो आपकी परियोजनाओं/बाइनरी आयात करते हैं और एक अनुवाद डेटाबेस का निर्माण करते हैं। पहली रिलीज के बाद इसे amortized किया जाएगा।

एक और संकेत (2): यदि संभव हो तो एक रिलीज करें जिसमें कोई बदलाव न हो लेकिन केवल बहु भाषा सुविधा हो। भविष्य में, यदि संभव हो तो: अपने उत्पाद को अंग्रेजी में रिलीज़ करें। फिर अनुवाद एक ही चरण (प्रति भाषा) में करें और अन्य भाषाओं को छोड़ दें।

Answer 2

DLL विकल्प आमतौर पर संसाधन लोडिंग प्रक्रिया (उदाहरण के लिए LoadLibrary) के बाद से इस के लिए प्रयोग किया जाता है पहले से ही लिखा है - जिसका अर्थ है कि आप किसी भी पार्स/लोड हो रहा है लिखने के लिए नहीं है कोड। जबकि एक्सएमएल को संपादित करना आसान है, डीएलएल के पास थोड़ा और सुरक्षा है (उपयोगकर्ता उन्हें आसानी से संपादित नहीं कर पाएंगे) और डेवलपर (अर्थात्) को भाषा लोडिंग सिस्टम लिखने के बजाए एप्लिकेशन लॉजिक पर काम करने के लिए अधिक समय दें।

HMODULE hLangDLL = LoadLibrary("text_en.dll"); 
// more stuff 
TCHAR mybuffer[1024] = {0}; 
LoadString(hLangDLL, IDS_MYSTRING, mybuffer, 1023); 

Answer 3

यदि यह केवल तारों को बदल रहा है तो मैं सहमत हूं कि एक्सएमएल आपके द्वारा रूपरेखा के सटीक कारणों के लिए यहां आगे बढ़ने का तरीका है। अन्य लोगों के संपादन के लिए आसान, रनटाइम पर भाषा को बदलने में आसान, आदि

एकमात्र कारण (मेरी आंखों में) कि आप विकल्प 1 चुनना चाहते हैं, यदि तारों के अलावा अन्य चीजें स्थानीयकरण की जा रही हैं जैसे विभिन्न आइकन की आवश्यकता है।

यदि यह सिर्फ टेक्स्ट है? मैं एक्सएमएल के साथ जाओ।

Answer 4

हमारे मामले में हमारे पास प्रति भाषा भिन्न संवाद थे। संसाधन फ़ाइल समान थी क्योंकि विकास के समय में कई लागेज लागू किए गए थे। आप मूल रूप से मौजूदा संसाधन फ़ाइलों को अलग-अलग भाषाओं में जोड़ सकते हैं। मुझे उम्मीद है कि यह आपके रास्ते को खोजने में मदद करता है।

Answer 5

एक डीएलएल संसाधन पुस्तकालय का उपयोग करना अपेक्षाकृत सरल ऑपरेशन है, और आपको न केवल स्ट्रिंग्स, बल्कि अन्य संसाधनों को प्रबंधित करने की अनुमति देता है। और यह इसका मुख्य लाभ है, क्योंकि i18n is not only about string translation।

हालांकि, आपकी आवश्यकताओं के आधार पर, टेक्स्ट-आधारित समाधान एक बेहतर निर्णय हो सकता है, क्योंकि इसकी आसान हैंडलिंग - संसाधन स्क्रिप्ट xml फ़ाइलों की तुलना में अधिक जटिल होती है, खासकर औसत अनुवादक के लिए।

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

Answer 6

मेरी अच्छी और मैत्रीपूर्ण सुझाव जो स्थानीयकरण के साथ एक बहुत काम किया:

1. ले लो GNU gettext,
2. मार्क सभी अपने तारों के रूप में _ ("अंग्रेजी")।
3. गेटटेक्स्ट टूल xgettext का उपयोग करके सभी तारों को निकालें और संकलन संकलित करें
4. poedit जैसे महान टूल का उपयोग करके स्ट्रिंग का अनुवाद करें।
5. अपनी परियोजना में उपयोग gettext और अपने स्थानीयकरण जीवन को आसान बनाने के!

तुम भी boost::locale ही उद्देश्य के लिए उपयोग कर सकते हैं - यह GNU gettext शब्दकोशों और दृष्टिकोण का उपयोग करता है, लेकिन अलग और अधिक शक्तिशाली क्रम प्रदान करता है और विंडोज़ डेवलपर के लिए यह बहुत अच्छा ऐड-ऑन है - यह विस्तृत तार कि MFC सामान्य के लिए उपयोग करने के लिए की आवश्यकता है का समर्थन करता है यूनिकोड समर्थन।

संसाधनों और अन्य "अनुवाद" टूल का उपयोग न करें जो भाषाई दृष्टिकोण से कुल बकवास हैं (और डेवलपर का दृष्टिकोण भी)।

अतिरिक्त पठन: http://cppcms.sourceforge.net/boost_locale/html/tutorial.html