*** sjc has quit IRC *** sjc has joined #gnuenterprise *** sjc has joined #gnuenterprise *** dimas has quit IRC *** dimas has joined #gnuenterprise *** reinhard has joined #gnuenterprise *** sjc has quit IRC *** sjc has joined #gnuenterprise *** btami has joined #gnuenterprise reinhard you here? i'v reported a bug for johannes before (http://www.gnuenterprise.org/irc-logs/gnue-public.log.2004-09-17) johannesV: locale.getlocale() in i18n returns 1250 not cp1250 on win and ISO8859-2 not iso88569_2 on linux so it's not a valid Python encoding kilo, please svn-up btami, where does that encoding conflict ? errors.py line 127 LookupError: unknown encoding: 1250 and today i find others get this bug too in locale modul on win http://mail.python.org/pipermail/europython/2003-April/002904.html i just don't understand why johannes intoduced getencoding() and getlanguage() in i18n.py instead of using preinitialized language and encoding variables of this module anyhow, ISO8859-2 is a valid alias for iso8859_2 by Python docs but 1250 is not for cp1250 so some workaround needed on win btami: let me explain why it was necessary to do this imagine appserver is run on machine A and forms is run on machine B and C appserver is started with LANG=de_AT because it is in Austria machine B starts forms with LANG=hu_HU machine C starts forms against same appserver with LANG=it_IT so an exception passed to machine B must deliver hungarian error message and an exception passed to machine C must deliver italian error message so appserver has to change the language according to the connection but depending on the language, encoding is also different and to translatate things python delivers in local encoding (like exception messages) back to unicode to transfer them over the wire we must know the current encoding of the active session not the encoding that was active when appserver was started * reinhard hopes he was able to explain understandable but anyway it strikes me that it worked before when getdefaultlocale() was used that would mean that getdefaultlocale() would return "cp1250" while getlocale would return "1250" is that true? fwiw i am certainly ok with anthing it needs to fix it under windows that's even the reason we made this new getlanguage() and getencoding() functions in i18n instead of using locale.getlocale() directly we saw something like that coming :) reinhard: that would mean that getdefaultlocale() would return "cp1250" while getlocale would return "1250" i just saw your link answers that question and i wholeheartedly agree with the poster that this is a bug in python --- btami: even if it would mean to not distinguish between session (user) encoding and local (server) encoding at all under windows i would accept it *** psu has joined #gnuenterprise *** mixi has quit IRC *** mixi has joined #gnuenterprise *** psu has quit IRC *** kilo has joined #gnuenterprise *** qman has joined #gnuenterprise reinhard: ok, thx for explanation, fix committed night *** btami has quit IRC *** gsoti_away has joined #gnuenterprise *** reinhard has quit IRC *** kilo has quit IRC *** sjc has quit IRC *** MiXi^ has joined #gnuenterprise *** mixi has quit IRC *** qman has quit IRC *** qman has joined #gnuenterprise *** gsoti_away has left #gnuenterprise *** vinsci has quit IRC *** vinsci has joined #gnuenterprise *** ccfiel has joined #gnuenterprise hello.. *** ccfiel has left #gnuenterprise *** ccfiel has joined #gnuenterprise can somebody tel me...if gnue has been used in a production mode?