Warning: Can't synchronize with repository "(default)" (Unsupported version control system "svn": No module named svn). Look in the Trac log for more information.

Ticket #1323 (closed defect: fixed)

Opened 12 years ago

Last modified 11 years ago

CalendarDatePicker choose wrong javascript encoding

Reported by: guest Owned by:
Priority: normal Milestone: 1.5
Component: unassigned Version: 1.0
Severity: normal Keywords:
Cc:

Description

There is a problem with the way CalendarLangFileLink choose javascript language file for CalendarDatePicker. It parses request's Accept-Charset header and tries to find javascript file according to charset. But it doesn't pass selected charset name to browser currently. For example, my browser puts the following headers:

Accepl-Language: uk,ru,en
Accept-Charset: windows-1251,utf-8

So it could pick for me russian localization encoded in windows-1251. But how would my browser know that this file is encoded in windows-1251? So my browser made wrong assumption that file is encoded in utf-8 as the rest of site content, and it leads to unreadable calendar. Maybe server could send appropriate encoding in headers when sending javascript file, like this:

Content-Type: application/x-javascript; charset=windows-1251

But I don't know if it is currently possinble with cherrypy. So my assumption is that CalendarLangFileLink should base its guess not on Accept-Charset header but on kid.encoding application setting.

Change History

comment:1 Changed 12 years ago by alberto

  • Milestone changed from 1.0.2 to 1.0.3

comment:2 Changed 12 years ago by faide

Or we could encode all our js files into utf8... which would be a hacky way to avoid the problem ...

But you are right that if the site content is not UFT-8 then we need to have the header properly set for the javascript file also...

comment:3 Changed 12 years ago by faide

  • Milestone changed from 1.0.3 to 1.1

comment:4 Changed 11 years ago by chrisz

See also the related problem #1643 that the charset names are not normalized.

comment:5 Changed 11 years ago by chrisz

I think the proper solution would be to

  1. Add support for the charset and language attributes to the JSLink widget
  2. Set these attributes in CalendarLangFileLink?

comment:6 Changed 11 years ago by chrisz

Also, the CalendarLangFileLink? should only try to guess the language and charset from the HTTP header, when they are not already explicitly set as widget parameters.

comment:7 Changed 11 years ago by chrisz

I have now implemented point 1 in r4060. Note that the "language" attribute of JSLink refers to the script language only and is deprecated anyway, but the "charset" attribute is what should really help us here.

comment:8 Changed 11 years ago by chrisz

  • Status changed from new to closed
  • Resolution set to fixed

Point 2 is now implemented in r4061. Problem #1643 has also been solved in that same changeset.

Note: See TracTickets for help on using tickets.