17 पॉइंट द्वारा xguru 2024-05-03 | 4 टिप्पणियां | WhatsApp पर शेयर करें
  • असममित localization: केवल ज़रूरत पड़ने पर gender/uppercase-lowercase का उपयोग करके स्वाभाविक अनुवाद का लक्ष्य। अभिव्यक्ति की क्षमता source language के grammar तक सीमित नहीं होती
  • क्रमिक सुधार: हर अनुवाद स्वतंत्र रूप से प्रबंधित होता है, इसलिए अन्य locales प्रभावित नहीं होते। दूसरी भाषाओं को प्रभावित किए बिना अनुवाद को बार-बार बेहतर किया जा सकता है
  • विविध सुविधाएँ: date, time और number formatting। plural categories। bidirectional support। custom formatting। पढ़ने में आसान grammar। runtime translation और retranslation। मज़बूत error handling
  • Apache license के तहत open source। server implementations JS, Python, Rust में उपलब्ध हैं और React bindings भी उपलब्ध हैं

Fluent को बनाने का कारण

  • software localization पर लंबे समय से एक पुराने paradigm का प्रभुत्व रहा है, जिसमें अनुवाद को English copy के साथ one-to-one mapping माना जाता है
  • source language का grammar अनुवाद की अभिव्यक्ति क्षमता को सीमित करता है
  • इसी paradigm को बदलने के लिए Fluent बनाया गया
    • translators को developers से अनुमति माँगे बिना भाषा की पूरी अभिव्यक्ति क्षमता का उपयोग कर सकना चाहिए
    • Fluent में अनुवाद असममित होते हैं। English की एक सरल string दूसरी भाषा में एक जटिल multi-variant translation से map हो सकती है
  • Fluent का उपयोग करने पर source language की परवाह किए बिना अलग-अलग भाषाओं के grammar और style की ज़रूरतें पूरी की जा सकती हैं
  • यह स्वतंत्र है
    • अगर कोई एक भाषा advanced logic के लाभ उठाती है, तो उसे लागू करने के लिए दूसरी localizations की ज़रूरत नहीं होती
    • हर localization यह स्वयं नियंत्रित करती है कि उसका अनुवाद कितना जटिल बनेगा

4 टिप्पणियां

 
yangeok 2024-05-09

ओह, पुराने 1:1 matching paradigm से बाहर निकलना काफ़ी दिलचस्प है।

 
iolothebard 2024-05-03

JavaScript-केवल gettext का कमतर वर्ज़न।

 
xguru 2024-05-03

https://github.com/projectfluent/fluent/wiki/Fluent-vs-gettext

अगर आप ऐसा कह देते हैं, तो आप इस प्रोजेक्ट को बहुत हल्के में ले रहे हैं।

 
iolothebard 2024-05-13

जवाब इतना मेहनत से लिखा हुआ नहीं लगा होगा, इसलिए आपको ऐसा लग सकता है। मैं इसे थोड़ा और मन लगाकर लिखता हूँ.

तुलना तालिका वैसे भी इस बात पर निर्भर करती है कि तुलना किसके आधार पर की जा रही है, इसलिए उसका बहुत बड़ा मतलब नहीं है,

मुझे इसे downgraded version जैसा महसूस होने की वजह यह है... कि लंबे समय में बहुत सारे लोगों द्वारा gettext में जमा की गई know-how का सम्मान नहीं किया जा रहा, ऐसा एहसास होता है।

कहा गया कि gettext सिर्फ C भाषा में काम करता है, लेकिन major languages में ऐसी कौन-सी भाषा है जो gettext को support नहीं करती?
शब्द क्रम की समस्या को ध्यान में रखकर key-based parameter इस्तेमाल किए गए हैं, लेकिन सभी भाषाओं में dictionary बेसिक रूप से built-in नहीं होती, तो ऐसी भाषाओं में अतिरिक्त तरीका चाहिए होगा (उदाहरण: Java में Map जैसा)। gettext position-based है, लेकिन शब्द क्रम बदलने के मामले को वह ध्यान में रखता है।

मैंने लंबा-चौड़ा लिख दिया,
असल में... शुरू से ही मुझे यह इसलिए पसंद नहीं आया क्योंकि यह ${...} नहीं बल्कि {$...} था^^

व्यक्तिगत रूप से मुझे "पहिया फिर से बनाना" बहुत पसंद है, लेकिन जैसे मानो दुनिया में पहले कभी न रहा हो ऐसा नया पहिया बना लिया हो, इस तरह बढ़-चढ़कर कहना मुझे खास अच्छा नहीं लगता।