[Gambas-user] Format$ with different LANG

Benoît Minisini gambas at ...1...
Thu Jun 25 14:11:14 CEST 2009


> Benoît Minisini ha scritto:
> >> For LANG="POSIX"
> >>
> >> ? Format$(Val("14555888") / 1000, "#,###.000")
> >> 14,555.888
> >>
> >> ...this is OK
> >>
> >> LANG="es_ES.utf8" and for LANG="it_IT.utf8"
> >>
> >> ? Format$(Val("14555888") / 1000, "#,###.000")
> >> 14 555,888
> >>
> >> There is a space  where should be a . but I can cope with it
> >>
> >> For LANG="ru_RU.utf8"
> >>
> >> ? Format$(Val("14555888") / 1000, "#,###.000")
> >> 14??555,888
> >>
> >>   where ?? are 3F3F . These are not recognised as UTF-8 valid
> >> characters.
> >>
> >> In my GAMBAS program actually the two "3F" are rapresented by squares.
> >>
> >> ( http://www.qsl.nqt/zp4kfx/Linux/dblog.html )
> >>
> >> Best regards
> >>
> >> Pino
> >
> > On my Mandriva 2009, for es_ES.UTF-8, it_IT.UTF-8 and ru_RU.UTF-8 I get
> > "14 555,888".
> >
> > Maybe this is a bug in the GNU spanish locale if you get a space whereas
> > you want a point. I'm not spanish, so I can't be sure.
> >
> > And "3F3F" is a perfect valid UTF-8 byte sequence. It is actually ascii:
> > "??"
>
> I confirm that number formatting (and perhaps dates too - can't remember
> well) don't work as expected in italian locale (tried on Debian systems
> and recent Ubuntu's); I had to implement my specialized routines to do
> that. Particularly annoying was the space instead of dot, but also the
> date as MM/DD/YYYY in some situation.
>
> This is not to say that gambas has some kind of problem, but perhaps
> some investigation (and some improvement) can be done. When writing my
> formatting routines, at the time, I didn't want to ignore completely the
> system settings, so I tried first to deduce the correct character to use
> and the correct order for D/M/Y querying the system. It was tought (no
> straight way to that), and lastly I had to do ugly tricks.
>
> Regards,

Gambas takes the data from the standard glib functions. So I think, but I can 
be wrong, that the glibc locale data may be wrong. I know that for sure 
because the thousand separator returned for French is false. I added an hack 
in Gambas to fix that, but if other locales have incorrect data too, a better 
solution must be found.

I will check (again) what the interpreter does. At the same time, it would be 
cool if some people can check the locale data returned by Gambas for their own 
language (mainly date, time and thousand separator, and currency characters) 
and tell me what is wrong. I know French and US locale only!

Regards,

-- 
Benoît




More information about the User mailing list