[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