Closed Bug 56017 Opened 24 years ago Closed 18 years ago

Sidebar uses wrong character coding to display Search results from Browser window

Categories

(SeaMonkey :: Search, enhancement, P5)

Product:
SeaMonkey
Component:
Search
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 145375
Milestone:
Future

People

(Reporter: tarahim, Assigned: samir_bugzilla)

References

(
URL
)

Details

(Keywords: intl)

Attachments

(1 file)

google.src : Google Search Plugin(UTF-8)
723 bytes, application/octet-stream
Details 
Open sidebar.
Go to www.google.com and set the language to Japanese and search Japanese sites.
The results in sidebar is not encoded in Japanese.
Confirming in 2000110108 on OS 9. This is a search bug, not a sidebar 
bug (the sidebar is working fine, search is only a module in the sidebar). 
Reassign to search folks.
Severity: major → normal
Status: UNCONFIRMED → NEW
Component: Sidebar → Search
Ever confirmed: true
QA Contact: shrir → claudius
Thx, Zach ! I wish everyone knew this.. :)
Keywords: nsbeta1
nav triage team: setting priority to P1. We need to verify if this really
happens and then whom to involve/reassign to - so that it can be fixed. Matt can
you drive that?  thanks, Vishy
Priority: P3 → P1
The problem here is that you need to specify in your sherlock file what charset 
to use. Please provide more details. Are you using a Japanese OS or a US OS? 
Whose sherlock file are you using? If you are using the Netscape_search.src 
file, then the problem is the charset specification as well as the fact that the 
URL for Google is not pointing to the Japanese template. Only the Japanese 
Google template will show Japanese characters properly, so if you are searching 
with US engines/templates, you will never see the characters properly.
You need to use the Japanese sherlock files to search Japanese properly.
This is under Japanese OS9.  I do not think this has anything to do with
Sherlock.  I am not sure why you ask about Sherlock plug-in, since I searched
from www.google.com all right in the browser window using Japanese as a default
language.  I am talking about the displayed result in the Sidebar which does not
seem to switch character encodings to  Shift-JIS, as used by www.Google.com.
OK, now I understand why you were asking about Sherlock.
I saw Mozilla send request to ireview.mac.com. after I hit search.
Since when this has been the standard behavior?  It used to have Google and
others in Sidebar.  Anyways, in the current settings, I manually switch the
character encodings to ISO-2022-JP in current window, type a keyword in Japanese
and hit search.  Result: Immediately the typed text changes to question marks,
and no search result is displayed.
Therefore, the bug manifests in both directions.
One: Searched in the browser window and the result in Japanese is displayed in
Sidebar without following the character codings.
Two: Search started in Sidebar and Japanese encoding is simply ignored.
The functionality you are seeing is because you are searching Google directly 
and the Google sherlock file that was shipped in Netscape 6 was only meant for 
the US searches. In order for the Japanese to appear correctly in the sidebar, 
the character encoding must be specified in the sherlock file. Otherwise, the 
browser does not recognize how the characters should be displayed. 

This bug is actually invalid because the sherlock file is as designed; however, 
there is a valid point that if someone searches directly using Google, s/he will 
automatically receive results displayed in the sidebar, and if the language 
happens to be something other than English, the results may appear as garbage. 
The only way to "fix" this problem is to disable the sherlock file when a user 
is searching from the main browser window, but I don't know if this is even 
possible.
I got back to Preferences and found some Japanese capable plug-ins like Excite
and Infoseek.  When I switched to those plug-ins, it kind of worked.  I also
tested Advanced Search where the serach was set to Japanese Engines.  These
seemed to work OK.  Therefore, the bug here is limited to the original
description, where a search is performed in the browser window, and the result
is displayed in the sidebar.
BTW, only Google.com seem to send the results in a manner they get displayed in
Sidebar.
Changing summary to clarify the point.
Summary: Sidebar can not handle Japanese in Search → Sidebar uses wrong character code to display Search results in Japanese from Browser window.
 I see your point.  So, this is Sherlock plug-in dependent.  Then, why Mozilla
depends its char code settings in Sidebar display strictly on Sherlock even when
it is merely receiving data?  I thought it was just like a browser window
following the information in the content.
Priority may be low, but I wish there be a fix some day.
The sidebar search panel is not an HTML page, so no character set exists for it. 
The only way that the charset can be defined is by specifying the charset in the 
sherlock file. This is by design, since a user should be able to search using 
sherlock files for various languages. Unfortunately, the problem with this 
design is that if a user selects a sherlock file designed specifically for US 
English searches and then attempts to perform a search in a different language 
(esp. double-byte), the results will be garbage. This is the same type of 
functionality you would see if you tried to perform a search for a double-byte 
word using a search engine that doesn't support double-byte. I don't think there 
is a workaround for this problem. Chau, Daniel, would you care to comment?
Will it get any help by bug 63507?
The bug you are referring to actually is related to the advanced multi-engine 
search that provides results in the main browser window, so I don't think it's 
related, although at first glance it appeared to be.
> The sidebar search panel is not an HTML page, so no character set exists for
> it.

Then one solution would be to turn the search panel into an HTML page. (This 
would also solve other bugs, such as bug 60348, as well as allowing Mozilla 
distributors to maintain a search page remotely).
Target Milestone: --- → mozilla0.8
i'm moving this bug to a request for feature.
Lynn is right when she says it depends on the sherlock file.
Thus the user needs to download a lang. specific sherlock file.
This is all by design.
Keywords: nsbeta1
Priority: P1 → P5
Summary: Sidebar uses wrong character code to display Search results in Japanese from Browser window. → [RFE]Sidebar uses wrong character code to display Search results in Japanese from Browser window.
Target Milestone: mozilla0.8 → Future
*** Bug 68655 has been marked as a duplicate of this bug. ***
Adding 'intl' keyword'
Keywords: intl
*** Bug 72153 has been marked as a duplicate of this bug. ***
Google result page has a META tag which specifies a charset. We can parse it and 
use it for charset conversion.
The current problem cannot be resolved even if the user downloads a localized 
version. When multiple sherlock files pointing to the same site (e.g. google), 
the first sherlock file name in ascending ASCII order to be always picked up.
We could change it to ignore the files which are not explicitly checked by the 
user in case of multiple files for one engine.

jaime, can you comment on when we shd look at this bug. currently inclined to 
schedule to mozilla0.9.5, after eMojo. 
You can modify the US Google sherlock file to work with Japanese by adding this 
string to the file in the "<INTERPRET" section:

	charset="Shift-JIS"

The browser would then interpret what it receives as results in shift-JIS.
nav triage team:

Marking nsbeta1-, we need to fix the general problem of using a language that
isn't the same as the version that mozilla/NS6 is localized for (i.e. Japanese
on a US localized version of mozilla). I think we've seen similar bugs
Keywords: nsbeta1-
Did you try  Japanese Search Plugins?
These plugins are localized to Japanese.

http://www.mozilla.gr.jp/tools/search/
(Japanese Only)
*** Bug 106426 has been marked as a duplicate of this bug. ***
reassigning matt's old bugs to default owner.
Assignee: matt → sgehani
Google now has ie(Input Encoding) and oe(Output Encoding) arguments. If we set
UTF-8 to them, We can search any language supported in UTF-8. This one is
hacked Google Search Plugin to support UTF8. This enhancement helps
Simplified/Traditional Chinese as well.
installation page for #26
(Just in the case.)
http://www.gashu.org/mozilla/moz03_misc.html#tools
See bug 62409
If the search plugin contains the following attributes:
queryCharset="ISO-8859-1"
charset="ISO-8859-1"
(and replace the ISO-8859-1 by the japanese charset) then everything works fine.
I just had the same issue with a Korean plugin by the way.

All the folks "complaining" about the broken plugins inside of Mozilla, please
check out the mycroft project on Mozdev http://mycroft.mozdev.org/. Our plugins
are usually more up-to-date than those in the Mozilla tree or on the partner
websites.

Also have a look at bug 145375 which is about adding Unicode to Google (same
thing you did here). Wouldn't it be wise to dupe one of these bugs?
Depends on: 172120
Blocks: 172120
No longer depends on: 172120
[RFE] is deprecated in favor of severity: enhancement.  They have the same meaning.
Severity: normal → enhancement
URL: www.google.com → http://www.google.com
Summary: [RFE]Sidebar uses wrong character code to display Search results in Japanese from Browser window. → Sidebar uses wrong character code to display Search results in Japanese from Browser window.
*** Bug 174027 has been marked as a duplicate of this bug. ***
Is this bug really Japanese / Mac specific?
I have a similar problem with Russian characters under OS/2.

*** Bug 169053 has been marked as a duplicate of this bug. ***
OS/Platform=All/All per previous comments...
OS: Mac System 8.6 → All
Hardware: Macintosh → All
Summary: Sidebar uses wrong character code to display Search results in Japanese from Browser window. → Sidebar uses wrong character coding to display Search results from Browser window
This has been fixed for a long time:
http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/xpfe/components/search/datasets/google.src&rev=HEAD&mark=1.4

There remains an issue with the shipped Ask.com plugin which can be dealt with in bug 360428.

*** This bug has been marked as a duplicate of 145375 ***
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: