[Mailman-i18n] Pipermail and non-English lists

[James Henstridge]

Barry A. Warsaw wrote:

>>>>>>"BAW" == Barry A Warsaw <barry@python.org> writes:
>>>>>>            
>>>>>>
>
>    BAW> But it looks like the thread indices and the list archive
>    BAW> overview pages either don't have http-equiv's or they're
>    BAW> incorrect.
>
>    BAW> I'll try to fix those.
>
>Ok, that was fun. :/
>
>I fixed things so that the index.html page adds an http-equiv header
>with the proper charset information, but that wasn't working as
>expected.  Dumping the page source indeed showed the proper http-equiv
>meta tag, but the page was still being displayed incorrectly.
>
>Turns out, my Apache config had this line in it:
>
>    AddDefaultCharset ISO-8859-1
>
>And because these pages are vended right from the file system, Apache
>dutifully adds "charset=iso-8859-1" to the Content-Type header.  This
>is documented to override the meta tag setting, so that part works
>correctly <wink>.
>
>A weird browser incompatibility exists between Moz1.1 and NS4.7x (all
>I've tried so far).  Moz will always believe the http header, trying
>to display the page in iso-8859-1, which isn't what we want.  NS will
>do the same thing -- until you hit the back button!  Then it picks up
>the koi8-r charset in the meta tag (I surmise) and displays it in the
>Russian charset.
>
>The solution was to comment out this line (not withstanding the
>security scare hinted at in the config file, but not in the
>documentation), or set it to
>
>    AddDefaultCharset off
>
>which is the default.  Now it seems to work just fine.  I guess I have
>to add this to the docs.
>
>Hmm, maybe this is another reason to want a cgi in front of even
>public archives?
>
>I'll check in a bunch of changes as soon as SF's cvs comes back
>on-line :(
>  
>
I ran into this same issue for the GNOME reference documentation.  We 
had our stylesheets set up to output UTF-8 docs, which caused problems 
when placed on a web server configured like this.

It looks like the default Apache 2.0 config includes this directive (and 
so do a number of distributors' apache-1.3 packages), so we decided to 
switch back to outputting ISO-8859-1, and encoding other codepoints as 
character references.  The comments in the config file say that they add 
the charset to the content-type to work around security bugs in some web 
browsers.

Having it set is a bit annoying, but we ended up deciding to work around 
this common configuration.

James.

-- 
Email: james@daa.com.au              | Linux.conf.au   http://linux.conf.au/
WWW:   http://www.daa.com.au/~james/ | Jan 22-25   Perth, Western Australia.