From: Jochen Hayek Date: 2008-01-16T01:53:39+09:00 Subject: Re: does ruby's strftime not attempt POSIX-compliance? Michal Suchanek wrote: > On 15/01/2008, Jochen Hayek wrote: >> >> Are we talking about software with a web GUI like rails?!? >> Aren't they MVC-based?!? >> Are they really talking to more than one user per instance?!? >> Don't we have a fresh process for a request each time any way?!? > > Note that if some ruby methods will start acting differently in > different locale it will affect all programs, not just rails. > Ruby is more than rails, That's right, but ... > and there are real multithreaded ruby applications. ... will a single instance of a non-web software usually serve more than a single user-interface. An let us assume for the time being, that a single-user interface usually comes with a single language! > I suspect you misunderstand the way locale is currently handled. > It is not used by ruby, it is avoided. Well, as long as MRI is written in C and makes use of host libraries esp. like (g)libc, "avoiding" is better replaced by "defaulting", because *there* *are* language strings emitted by C library routines and passed through to ruby class resp. object methods, and it's probably not too wrong to assume these strings are "very similar" to en_US. That is a locale de facto, isn't it?!? > The only recent change was adding the > setlocale() call in the ruby interpreter > that is required for some > extensions to work properly in different locales. Extensions built on assumptions *like* "you always work with en_US", of course, that simplifies life tremendously, but you don't real want to discuss this bad idea with me, right? > And small fixes were required to some core ruby classes > to work properly after that. > > If you want to call setlocale() yourself > there is a ruby-locale extension for quite some time Last released around Dec. 2002, and you will agree with me, we should regard such software as abandoned, right? Unlikely to be compatible with 1.8.5, 1.8.6, 1.9, and certainly for "good reason" not released with MRI itself. > that you can use for that. I am awfully sorry, but I mistrust that suggestion. Again: MRI, rubinius, and jruby should get it right: * no locale dependencies between core and middleware (HTTP protocol and whatever XML dialect implementation), * passing (g)libc capabilities straight through, where not too much speaks against it * implement nicer locale capabilities, when there are any coding resources left You do see, how people struggle for I18N in rails apps in a desperate and strange way, just because available locale capabilities most easy to get passed through from the interpreter's runtime system are twisted suboptimally? Again: it's already there, just set it free! Thanks a lot for your time and ideas! J. -- Posted via http://www.ruby-forum.com/.