[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