[Webkit-unassigned] [Bug 7172] Japanese block text translation on Babelfish does not work with Default encoding
bugzilla-daemon at opendarwin.org
bugzilla-daemon at opendarwin.org
Sat Feb 11 14:09:33 PST 2006
http://bugzilla.opendarwin.org/show_bug.cgi?id=7172
ap at nypop.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|HTML DOM |WebKit Misc.
------- Comment #3 from ap at nypop.com 2006-02-11 14:09 PDT -------
Here is what's happening here:
1) When the translation page is first loaded, Babelfish uses a charset from the
client's Accept-Charset header to decide which charset to send in its
Content-Type header. The HTTP META isn't changed accordingly, but it doesn't
affect anything, either. Safari doesn't send Accept-Charset at all, and gets
ISO-8859-1 in the response. When Firefox sends
"windows-1251,utf-8;q=0.7,*;q=0.7", it gets UTF-8.
2) The browser encodes the text to be translated according to the page charset.
E.g., ToT WebKit sends %26%2326908%3B for U+691C (which is correct for
ISO-8859-1, but Babelfish apparently doesn't understand entities). Firefox
sends %E6%A4%9C (UTF-8).
3) To determine the request encoding, Babelfish looks at Accept-Charset again.
It also tries some default encoding for the "from" language. Since Safari
doesn't send Accept-Charset, and the default encoding for Japanese is
Shift-JIS, Babelfish thinks it should be Shift-JIS.
This looks like an abuse of Accept-Charset to me, but might mean that we have
to send one.
--
Configure bugmail: http://bugzilla.opendarwin.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