There is a bug concerning charsets popping though in oacs-5-3 (not in head). The site-master.tcl sets via
"text/html; charset=[ad_conn charset]"
the value of
<meta http-equiv="content-type" ...>
to text/html followed by the charset returned by
ad_conn charset
. ad_conn gets initialized with the
mime_charset
of
ad_locales
select locale,mime_charset from ad_locales;
->
locale | mime_charset
--------+-----------------
en_US | ISO-8859-1
...
via ad_conn -set charset [lang::util::charset_for_locale [ad_conn locale]]
.
So, for the locale en_US, it uses always the charset ISO-8859-1 and ignores the value of aolserver config value OutputCharset
. Since the OutputCharset
is used in the HTTP headers, there is a mismatch in cases, where OutputCharset
differs from the settings in the locale table. The W3C validator flags this as an error.
As quick fix I have have changed in oacs-5-3 the settings of http-equiv to
"text/html; charset=[ns_config ns/parameters OutputCharset [ad_conn charset]]"
which does the trick. Most probably, one should not set this meta-field at all (not sure, why it was put in), and should discourage the use of
ad_conn charset
to determine the charset settings of the connection.