On Mon, Mar 12, 2007 at 08:51:47AM +0200, Athan wrote: > "Patrick R. Michaud" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > > 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 _______________________________________________ pmwiki-users mailing list [email protected] http://www.pmichaud.com/mailman/listinfo/pmwiki-users
