[Webkit-unassigned] [Bug 18994] LANG/LC_ALL influences the result of element.style.opacity
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Tue May 20 12:11:47 PDT 2008
http://bugs.webkit.org/show_bug.cgi?id=18994
------- Comment #9 from vbs85 at gmx.de 2008-05-20 12:11 PDT -------
(In reply to comment #6)
> I couldn't find anything :/ I doubt that glibc offers this after finally
> offering automatic locale specific formatting.
>
> Why does the parseDouble() function expect "." even when the locale specifies
> ","?
>
> Also, I wonder what a fix in String::format() would break. Will it work for
> JavaScript, too? Like:
>
> var x = 1.5;
> var s = "" + x;
> assert "1.5" == s;
>
> My next idea was to set LANG/LC_ALL in the startup script but that would break
> if someone would embed WebKit in an application.
>
> Or we could patch the field "decimal_point" in "struct lconv". But that might
> introduce even more hideous bugs during embedding, especially when threads are
> used.
>
> Which leads to another question: Might the web developer want to *show* float
> values to the user? In this case, which locale should be used to format them?
> C? The locale of the page? The locale in which the browser runs?
>
> Argh... a Pandora Bug!
>
> If everyone was using String::number(double) to format double values, we could
> replace "," by "." in there. But that isn't very safe as long as
> String::format() is not private (someone might try to format double values
> manually, for example in a more complex format string).
>
> The GNU header file locale.h mentions that there is some proof of concept code
> to allow per-thread locales. But I'm not sure how fast this is (i.e. getting
> the current locale, replace it with C, set it back after the double value has
> been formatted).
>
> *sigh* It would be easier if style.opacity would simply return a double value
> :)
>
> I'll keep my eyes open for a solution for this but half an hour on Google
> didn't turn anything really useful up. Maybe ask the glibc maintainers for
> help?
>
It's not only the decimal-point: (from man printf)
For some numeric conversions a radix character (decimal point) or
thousands grouping character is used. The actual character used depends on
the LC_NUMERIC part of the locale. The POSIX locale uses . as radix
character, and does not have a grouping character. Thus,
printf("%.2f", 1234567.89);
results in 1234567.89 in the POSIX locale, in 1234567,89 in the nl_NL
locale, and in 1.234.567,89 in the da_DK locale.
--
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
More information about the webkit-unassigned
mailing list