Follow-up Comment #25, bug #12910 (project mldonkey): @JongAm Park
1) Can you change the LC_CTYPE environment variable to "ko_KR.UTF-8" and see if the output of mlnet gives "...Current language of the target machine is KR ..." 2) i think this core uses the nl_langinfo but not the locale_charset () from libcharset... There is a report stating that nl_langinfo(CODESET) returns "US-ASCII" on mac in the case the environment variables LANG, LC_CTYPE, LC_ALL are not set by the system. http://lists.gnu.org/archive/html/bug-gnulib/2005-02/msg00048.html but mlnet works well. otherwise we would fall back to the string "ASCII" but not to "US-ASCII". @spiralvoice and amorphous The language detected by mlnet is given by LC_CTYPE that is the category related to encodings as per definition of a LOCALE model. Maybe we should change ml_get_default_language by testing LANG first, then LC_ALL and then only LC_TYPE for all platforms? For MacOS X, we should modify ml_locale_charset. There is this paper from Bruno Haible (Author of the GNU libiconv) http://www.caddr.com/macho/archives/sbcl-devel/2004-11/4221.html As suggested, on MacOS X, the default encoding UTF-8 has to be supposed. Or instead of nl_langinfo on MacOS X, we could try to catch LANG, LC_ALL with getenv before to fallback to "UTF-8". _______________________________________________________ Reply to this item at: <http://savannah.nongnu.org/bugs/?func=detailitem&item_id=12910> _______________________________________________ Message sent via/by Savannah http://savannah.nongnu.org/ _______________________________________________ Mldonkey-bugs mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/mldonkey-bugs
