Hi, Michal,
you definitely are a hard-core newsgroup/ml guy, aren’t you?!
Me, too. 
But: just not to forget the (more or less explicit) subject of this
thread,
it refers to the “POSIX locale concept” and the ruby (non-)compliance
with it.
And we got carried away from it, didn’t we?
“MS” == Michal S. [email protected] writes:
MS> yes, the problem is that you have to deal with strings also
outside of
MS> view, and you want to do that independently of the view and its
MS> locales.
>>
>> That's what I like and appriate with academical people:
>> they are not pragmatic, and they don't need to be ;-)
>> And it's good that way. Serious.
>>
>> Dear Michal, you are right in that it should be dealt with
software with
>> multiple user interfaces,
>> all dealing with users in entirely different locales.
MS> No, I meant software dealing with texts in different languages.
MS> Different languages have different sorting rules (even for the
same
MS> letters) but you have only one locale.
MS> That's why I don't really like the idea of using locale too
much.
That’s fine, but I do want to use it,
and it comes for free in any UNIX / Linux / Mac / Cygwin (/ Windows?!?)
environment
so why not simply pass it through w/o confusing the interpreter’s
runtime system
and enjoy it.
I mean: re-implementing it in ruby,
just because it’s nicer (+ slower) in ruby,
is …
>> > no, it's avoiding it. The locale was set to "C" in 1.8,
>> > and now only LC_CTYPE is set.
>>
>> Oh, and that's not set *to* *a* *value*?
>>
>> Matz wrote, that this is done:
>>
>> setlocale(LC_CTYPE, "");
MS> Yes, it's correct. It means "set locale from the environment
variable"
So why does my example not work with my ruby1.9, just downloaded and
built yesterday?
$ env LC_ALL=fr_FR /usr/local/ruby1.9/bin/ruby
-e ‘t = Time.now; puts t.strftime(“%A”)’
Friday
$ env LC_ALL=fr_FR date ‘+%A’
vendredi
MS> With ruby 1.9 you get exactly that.
I would love to see that,
but it seems to be incorrect.
MS> Yes, this is ruby's strftime that operates on ruby Time values
and has
MS> nothing in common with the libc strftime except the name 
It does have in common most of it,
so not complying 99.5 % is what I call “camouflage” and simply
misleading the programmer user.
I assume, you will agree here.
MS> You cannot just pass them.
MS> It's not too hard
MS> to convert limited subset of possible ruby valus
MS> to C values and use the C localized functions on them.
MS> But you probably cannot format all Time values,
Probably, so let’s assume returning strings on the ruby heap or stack
would actually work.
You know my roots are in the compiler and interpreter business of the
80-s.
I implemented a code generator and a runtime system for Ada on a
Motorola 68k on a bare machine and also within a SysV UNIX,
I helped the Modula2 compiler guys from next door,
in implementing a first I/O library based on the C printf/scanf
utilities,
I made use of the Tcl-C interface,
…,
so I can dare to say,
that things in that area are not overly complex
and with a quality approach it can even be achieved w/o creating memory
leaks and “almost” bugfree.
Regular business.
MS> and certainly not all Bignums.
Alright.
MS> I am not very fond of localized date/time formats.
MS> I find them confusing.
MS> Anybody and anything should be able to parse 2008-01-18,
MS> and it even sorts correctly in dictionary order.
I fully agree to you.
I started using this ISO date format next to my signature on forms back
in the early eighties.
And I learned esperanto then.
But in real life people want to speak French, Czech, German, Portugues,
Spanish, Russian, and also English,
and they want to use their familiar date format.
MS> Still it should not be too hard to use the C strftime
MS> if anybody wants to do so.
MS> You are welcome to update the ruby-locale extension if you are
so concerned
I feel, like my enhancements would also not find their way into the
released source,
just like the patch stemming from 2002.
And how can I recommend using such a crappy enhancement to people in my
local user group?
Kind regards,
J.