Closed Bug 26260 Opened 25 years ago Closed 25 years ago

ISO 8859-x characters displayed as HTML entities or just garbage in the sidebar

Categories

(Core :: Internationalization, defect, P3)

x86
Windows NT
defect

Tracking

()

VERIFIED DUPLICATE

People

(Reporter: jbetak, Assigned: jlinley)

References

()

Details

(Whiteboard: [nsbeta2+][PDT-])

Try navigating to the German newspaper Süddeutsche Zeitung or lookup two communal web site in Central Europe: 1) Süddeutsche: -the first related link reads "© Verlag der Tagesspiegel 1999", it should display the copyright symbol -the second related link reads "Saarbücker Zeitung" instead of "Saarbrücker Zeitung" 2) Augsburg: - the first link reads "Aktuelle München-informationen" instead of "Aktuelle München-informationen" 3) Nitra: - the socond link reads "Vitajte v PreAjove" instead of "Vitajte v Pre?ove" Although this bug appears to be related to http://bugzilla.mozilla.org/show_bug.cgi?id=24933 it is not the case. I fixed 24933 in my build and verified with official nigthly builds (the latest one was 2000020108). Unless Alexa's database is causing the problem (the links show up fine on IE 4.0 with the Alexa plugin) I would consider it a Beta blocker. "Aktuelle München-informationen" not "Aktuelle München-informationen"
Changed QA contact to blee@netscape.com
QA Contact: teruko → blee
What happened is the related link server does not decode HTML name entity and convert it to NCR or UTF-8 before send to us. $.x show ? since it cannot understand the entity. Reassign this to Cindy. Cindy please ressign this to the right NetCenter person.
Assignee: ftang → roberts
Keywords: beta1
Cheri Melville cherim@netscape.com owns the Alexa relationship
Erik, should this UTF8 encoding be handled by the Latin1 conversion tool on the Alexa server? If so, will send this to paul@alexa to follow up, as it would seem to be related to bug #14222
It might be separate from bug 14222. This bug concerns Character Entity References (aka named entities). In Netscape 4.X, we had a lenient XML parser that would accept those. In Mozilla, we have a strict XML parser that should remain strict. It would be better to change the CERs to UTF-8 on the Netcenter side (i.e. Alexa's side). Mozilla's XML parser accepts UTF-8, but not CERs.
PDT-
Whiteboard: [PDT-]
PDT folks, This is not a browser bug. The WR servers is sending bad data.
erik: In Netscape 4.X, we had a lenient XML parser that would accept those. Not really, it is worst in 4.x, it convert to any entity to ? except those 3 XML entity. This should be fix not only for SeaMonkey, but also 4.x NetCenter issue. Please reassign to NetCenter bugzilla account.
Assigned to kristif as cheri doesn't have a bugzilla account
Assignee: roberts → kristif
Working with Cheri Melville to resolve through Alexa.
Status: NEW → ASSIGNED
*** Bug 24972 has been marked as a duplicate of this bug. ***
Reassigning to Jared Linley, Netcenter Producer for What's Related. He has access to the Netcenter engineers who are working with Alexa.
Assignee: kristif → jlinley
Status: ASSIGNED → NEW
New Alexa database installed on Production fixed this bug.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
The problem still happens in 04-14-07-M15 (Win) bld as described originally. Reopening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Keywords: beta1nsbeta2
Putting on [nsbeta2+] radar for beta2 fix.
Whiteboard: [PDT-] → [nsbeta2+][PDT-]
*** Bug 33692 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of 35630 ***
Status: REOPENED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → DUPLICATE
Verified using Winn32 05-24-09-M16 bld.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.