Bug 79218 – [EFL] Change parameter of setlocale in the platformLanguage.

• Status: RESOLVED
• Resolution: WONTFIX
• Component: WebKit EFL

[Kihong Kwon]

LC_CTYPE which is a parameter of setlocale is not proper for navigator.language.
LC_MESSAGES is better then LC_TYPE.

This is a description of "man setlocale".
LC_CTYPE
    for  regular  expression matching, character classification, conversion, case-sensitive comparison, and wide character functions.
LC_MESSAGES
    for localizable natural-language messages.

[Kihong Kwon]

Created attachment 128168 [details]
Patch.

[Gyuyoung Kim]

Comment on attachment 128168 [details]
Patch.

View in context: https://bugs.webkit.org/attachment.cgi?id=128168&action=review

I'm not sure whether this patch is right. IMHO, we should verify if LC_MESSAGES is able to support navigator.language specification first. In Mozilla case, window.navigator.language represents RFC 4646. If so, GTK port needs to be changed as well. GTK port is using LC_CTYPE.

> Source/WebCore/ChangeLog:9
> +        LC_MESSAGES is better then LC_TYPE.

%/LC_TYPE/LC_CTYPE/g

[Gyuyoung Kim]

CC'ing Martin, if this patch is right, I think GTK port also needs to use this patch.

[Martin Robinson]

(In reply to comment #3)
> CC'ing Martin, if this patch is right, I think GTK port also needs to use this patch.

What values do Firefox and Chromium use? Perhaps we should check LC_MESSAGE, LC_CTYPE and LC_ALL in succession.

[Kihong Kwon]

(In reply to comment #4)
> (In reply to comment #3)
> > CC'ing Martin, if this patch is right, I think GTK port also needs to use this patch.
> 
> What values do Firefox and Chromium use? Perhaps we should check LC_MESSAGE, LC_CTYPE and LC_ALL in succession.

I have checked setlocale() in the windows, mac and ubuntu.
Windows and Mac don't support this function properly, for example:
In case of Windows7,
LC_CTYPE : C.UTF-8
LC_MESSAGES : C.UTF-8

In case of MAC OS X 10.6,
LC_CTYPE : UTF-8
LC_MESSAGES : C

I think only Linux(Ubuntu 11.04) can support this properly, that is:
LC_CTYPE : en_US.UTF-8
LC_MESSAGES : en_US.UTF-8

IMHO, LC_CTYPE indicates system's regional information whereas LC_MESSAGES indicates language.
In addition, Qt and Chromium ports implement this in the browser(app), i.e., not implemented in the webkit.
Similarly, what would you think, for Efl and Gtk ports, implement this function (i.e., getting navigator's language information) in the browser instead of in the WebKit.



How about efl and gtk implement this like qt an chromium.

[Soo-Hyun Choi]

View in context: https://bugs.webkit.org/attachment.cgi?id=128168&action=review

> Source/WebCore/ChangeLog:10
> +

English: LC_CTYPE, a setlocale parameter, is not working correctly for navigator.language.

Typo?
%s/better\ then/better\ than/g

[Martin Robinson]

(In reply to comment #5)

> In addition, Qt and Chromium ports implement this in the browser(app), i.e., not implemented in the webkit.

This is not actually the case for Qt. It happens in the toolkit:

http://code.google.com/codesearch#OtNR_hPxrO0/trunk/abanq-port/src/qt/src/tools/qlocale.cpp&q=QLocale&type=cs&l=2977

It seems the behavior it takes is to test LC_NUMERIC, LC_ALL, and LANG in succession.

Chromium seems to do something similar without a slightly different precedence:

http://code.google.com/codesearch#wZuuyuB8jKQ/chromium/src/ui/base/l10n/l10n_util.cc&q=chromium%20language%20lc_&type=cs&l=415

[Gyuyoung Kim]

Kihong, if you need time to prepare new path, it is better to clear flags.

[Michael Catanzaro]

Closing this bug because the EFL port has been removed from trunk.

If you feel this bug applies to a different upstream WebKit port and was closed in error, please either update the title and reopen the bug, or leave a comment to request this.