[pmwiki-users] PmWiki.org UTF-8 migration complete
5ko at 5ko.fr
Mon Oct 31 10:53:00 CDT 2011
On Monday 31 October 2011 09:14:23 Oliver Betz wrote:
> there is no difference between "xlpage-utf-8.php after XLPage()" and
> "xlpage-utf-8.php disabled", both result in correct display for old
> and new pages but wrong XLPage translations.
> Seemingly that's because PmWikiDe.XLPage causes xlpage-utf-8.php to be
> included, correct?
Correct, but I plan disabling this inclusion in a future version and have
admins add the include_once() line in config.php.
> Next step: After removing the 'xlpage-i18n' => 'utf-8' entry from
> PmWikiDe.XLPage, I get different results:
> "xlpage-utf-8.php after XLPage()" results in wrong display of old
Right, old pages, as well as some other pages like RecentChanges last modified
with version 2.2.29 or earlier, and possibly pages written by recipes with
PmWiki version 2.2.30 and earlier. Newer versions of PmWiki always store the
charset= attribute, with previous versions this attribute was not enforced if
it was missing.
> and "xlpage-utf-8.php disabled" results in corect display.
> Well, that's somewhat surprising. Can it be true that removing UTF-8
> entries completely fixes the display problems? Even if this is true,
> it's no solution, because new pages are stored as ISO-8859-1 instead
> of UTF-8.
Yes, but your wiki is no longer in UTF-8. This is the usual case of someone
upgrading from an earlier version without migrating to UTF-8: even if the
documentation is UTF-8, PmWiki will convert it on the fly to the older
encoding. It is supposed to work without flaw.
> Next step (suggestion from your other mail):
> $DefaultPageCharset = array(''=>'ISO-8859-1');
> seems to cure the problem: New pages are UTF-8, pages without
> declaration and XLPage translations are dispalyed correctly, and it
> doesn't matter whather PmWikiDe.XLPage contains "'xlpage-i18n' =>
> 'utf-8'" or not.
This looks correct.
> Gladly I have neither other encodings nor page names with
> international characters.
Absolutely. But we'll have to migrate wikis with international page names too.
> Is $DefaultPageCharset = array(''=>'ISO-8859-1'); only used to guess
> the charset of pages not containing a definition, or are there other
It will be also used to override a wrong charset for pages saved with versions
2.2.29 and earlier in the encodings ISO-8859-2, *-9 or *-13.
Thanks a lot for trying the UTF-8 migration and reporting what you find. Even
if I wrote on Sept. 18 that this migration is not trivial and shouldn't be
rushed until we document it, your reports will help us document it.
More information about the pmwiki-users