[pmwiki-users] Headers are not sending charset !
Patrick R. Michaud
pmichaud at pobox.com
Mon Mar 12 08:27:15 CDT 2007
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.)
> 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
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.
More information about the pmwiki-users