java - फ्रंट एंड या बैक एंड पर एपीआई त्रुटि संदेश का अंतर्राष्ट्रीयकरण?




angularjs spring (2)

मेरी टीम वर्तमान में एक वेब प्रोजेक्ट पर काम कर रही है जहां फ्रंट एंड बैक एंड द्वारा प्रदान की गई जेएसन एपीआई का उपयोग करता है। हमारे द्वारा उपयोग की जाने वाली तकनीक स्प्रिंग बूट और एंजियरीजेएस है एपीआई में मानक त्रुटि प्रारूप है जो इस तरह दिखता है:

{
    "errorCode": "1111",
    "message": "Error occurred: some error message",
    "developerMessage": "message for developer"
}

त्रुटि प्रतिक्रिया में फ़ील्ड सत्यापन त्रुटियों की वैकल्पिक सूची भी हो सकती है। सवाल यह है कि हमें उपयोगकर्ता त्रुटि संदेशों का अनुवाद कहाँ करना चाहिए? क्या पिछला अंत अनुरोध के लोकेल के आधार पर पहले से ही अनुवाद किया गया संदेश या फ्रंट एंड में त्रुटि कोड का उपयोग करना चाहिए और यह i18n तंत्र है हमारे पास आईआईएलएन तंत्र दोनों पीठ के अंत (स्प्रिंग i18n समर्थन) और फ्रंट एंड (कोन्यूलर-ट्रांसलेट) हैं।

सबसे अच्छा अभ्यास क्या है? प्रत्येक दृष्टिकोण के पेशेवरों और विपक्ष क्या हैं? किसी भी सलाह की सराहना की है।


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

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


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

ध्यान दें कि एकाधिक क्लाइंट ऐप्स का समर्थन करने के लिए आपको अपने बिल्ड में बंडलिंग चरण के दौरान resx रूपांतरण की आवश्यकता हो सकती है। यह ग्राहक द्वारा आवश्यक प्रारूप में संसाधन फ़ाइलों को बनाएगा ताकि आप अनुवाद के एक स्रोत को रख सकें

लाभ:

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

कमियां:

  • नई त्रुटियों के लिए अनुवाद संभव नहीं है क्लाइंट एप्लिकेशन को बंडल किए जाने के बाद बैकेंड पर कोई त्रुटि परिभाषित की गई थी, तो क्लाइंट को सामान्य संदेश प्रदर्शित करने की आवश्यकता होगी (लेकिन यदि आवश्यक हो तो नया त्रुटि आईडी प्रदर्शित कर सकते हैं)
  • अधिक जटिल बंडलिंग






angular-translate