<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - New intl-numberformat.js test fails on many Linux platforms"
href="https://bugs.webkit.org/show_bug.cgi?id=154530#c4">Comment # 4</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - New intl-numberformat.js test fails on many Linux platforms"
href="https://bugs.webkit.org/show_bug.cgi?id=154530">bug 154530</a>
from <span class="vcard"><a class="email" href="mailto:clopez@igalia.com" title="Carlos Alberto Lopez Perez <clopez@igalia.com>"> <span class="fn">Carlos Alberto Lopez Perez</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=154530#c3">comment #3</a>)
<span class="quote">> There are two separate questions here:
>
> One is how to make WebKit and JavaScriptCore properly choose a default
> locale for each platform. I don’t know what the right way to do that is for
> Linux in general. Fixing that for WebCore is what <a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - Intl.Collator uses POSIX locale (detected by js/intl-collator.html on iOS Simulator)"
href="show_bug.cgi?id=152448">bug 152448</a> is all about.
> But it almost certainly needs to be fixed for direct JavaScriptCore use too.
> At least I know it does need to be done on the Apple platforms. So we may
> need a bug to track that.
> </span >
With glibc (GNU/Linux) the default locale is defined on the environment variable LANG. If LANG is not defined, then the locale defaults to 'C' (also known as 'POSIX') which is the default portable locale.
This default locale can be overridden with the environment variable LC_ALL.
So perhaps we can just do setenv("LC_ALL", "C") before starting the tests. This will override any locale defined by the user, and it will be portable across operating systems
Some quick tests:
# Linux
$ LANG=es_ES.UTF-8 WebKitBuild/Release/bin/jsc -e "print(Infinity.toLocaleString())"
∞
$ LC_ALL=POSIX LANG=es_ES.UTF-8 WebKitBuild/Release/bin/jsc -e "print(Infinity.toLocaleString())"
INF
$ LC_ALL=C LANG=es_ES.UTF-8 WebKitBuild/Release/bin/jsc -e "print(Infinity.toLocaleString())"
INF
# MacOS
$ LANG=es_ES.UTF-8 WebKitBuild//Release/JavaScriptCore.framework/Versions/A/Resources/jsc -e "print(Infinity.toLocaleString())"
∞
$ LC_ALL=POSIX LANG=es_ES.UTF-8 WebKitBuild/Release/JavaScriptCore.framework/Versions/A/Resources/jsc -e "print(Infinity.toLocaleString())"
INF
$ LC_ALL=C LANG=es_ES.UTF-8 WebKitBuild/Release/JavaScriptCore.framework/Versions/A/Resources/jsc -e "print(Infinity.toLocaleString())"
INF
<span class="quote">> The other is how to make the test harness set a consistent language so that
> tests are reliable, rather than being sensitive to the language the user
> running the tests happens to prefer. That's something we need to address
> separately. There are lots of calls to setenv in various test tools, so it
> could be as simple as doing a setenv("LANG") in the right place for the
> appropriate platforms in some of the test tools.</span >
As explained above, just doing setenv("LC_ALL", "C") before starting the tests should work for all use cases.
More info: <a href="http://man7.org/linux/man-pages/man3/setlocale.3.html">http://man7.org/linux/man-pages/man3/setlocale.3.html</a> and <a href="https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/locale.1.html">https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/locale.1.html</a></pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>