![\"code1\"](\"https:\/\/jurn.link\/jurnsearch\/2009\/02\/code1.jpg\" "\\"code1\\"")
into the search box after a search, when it should show ![\"character\"](\"https:\/\/jurn.link\/jurnsearch\/2009\/02\/character.jpg\" "\\"character\\"")
. <\/p>\nI’m trying to fix a problem with JURN returning into the search box after a search, when it should show . <\/p>\n
being the “raw” HTML codes for those Chinese characters.<\/p>\n
Tweaking the supplied code snippet from UTF-8 to iso-8859-1 seems to cure it. But then that results in nothing<\/strong> being returned to the search box at all, even for English queries. Which is obviously a non-starter, since I’m not going to cripple JURN in English.<\/p>\n It seems the bug results from a combination of Google’s remote “show_afs_search.js” javascript file (which I can’t change), and my showing the results on the same page as the search box (i.e.: the “iframe hosting option”). The language encoding for the search terms is getting stripped out, somewhere in the loop back to the search-box. <\/p>\n Other people’s Custom Search Engines seem to handle the problem, but only by displaying the results on a new second page. I may have to look into having a second interface for non-English users, showing the results on a second page, when JURN makes the move to its own domain. Or you can just use the “raw” Google page<\/a> for JURN.<\/p>\n Unless someone can offer a solution? But I’ve searched the support forums with no result. It seems it may well be a genuine bug with the “iframe hosting option”. The same bug also causes JURN to refuse non-English accents (i.e.: diacritics) on search terms. So “pate” will work and will find “pate” and “pâté”, — but “pâté” on its own won’t be accepted as a valid search term.<\/p>\n","protected":false},"excerpt":{"rendered":" I’m trying to fix a problem with JURN returning into the search box after a search, when it should show …<\/p>\n