[pmwiki-users] Headers are not sending charset !

[Patrick R. Michaud]

On Mon, Mar 12, 2007 at 08:51:47AM +0200, Athan wrote:
> "Patrick R. Michaud" <pmichaud at pobox.com> wrote in message 
> news:20070311230731.GE1629 at host.pmichaud.com...
> 
> > Which xlpage-* scripts aren't properly setting $HTTPHeaders?
> > (I know that several of them do not set $HTMLHeaderFmt yet... but
> > all of them should be setting $HTTPHeaders.)
> 
> Patrick,
> 
> The problem is that most people, including myself, expect that the 
> xlpage-i18n encoding, declared in translation XLPage, will be automatically 
> injected in both http and html headers (a w3c recommentation). Unfortunately 
> that is only happening with encodings that have an associated i18n file 
> (iso-8859-2, 9, 13 and utf-8). 

Oh, I understand now.  Technically speaking, this is really an error
in expectation.  The 'xlpage-i18n' translation in XLPage doesn't
specify a charset, it specifies the name of an xlpage-* script to
be loaded in order to support a given character set.  (That's why 
the translation phrase is 'xlpage-i18n' and not 'charset'.)

So, the real problem here is that we haven't yet created an 
xlpage-iso-8859-7.php script.  I'll see about doing that
shortly.

A second approach might be for PmWiki to treat xlpage-i18n as though
it is a simple charset declration whenever an associated xlpage-*
script doesn't exist.  Thus, if someone sets 'xlpage-i18n' to
'euc-jp', and there's no 'xlpage-euc-jp.php' file in the scripts/
directory, then PmWiki defaults to setting the charset
declarations in $HTTPHeaders and $HTMLHeaders.  But I'm not
sure I like this solution...

> Sorry but I still don't understand why isn't possible for core to assign 
> encoding in both http and html header, before including xlpage-$i18n.php
> That way, pmwiki will always include the right html/http header, even when 
> there is no xlpage-$i18n.php file available.

...because in general simply setting the charset= parameter of the
html/http headers isn't sufficient to get things to work properly.
In addition to setting the headers, PmWiki often needs to re-evaluate
the value of $pagename in the context of the new character set, as well
as potentially change the settings for a few other variables 
(e.g., $KeepToken) to avoid collisions between pagenames and PmWiki's
internal string markers.

So, perhaps the real solution here is to have PmWiki abort with an
error message when a non-existent xlpage-i18n page is requested.
The error message would then say to contact the mailing list to
get an appropriate xlpage-i18n file created for distribution.

Pm