[pmwiki-users] PmWiki.org UTF-8 migration complete
list_ob at gmx.net
Mon Oct 31 11:59:12 CDT 2011
Petko Yotov wrote:
>> and "xlpage-utf-8.php disabled" results in corect display.
>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.
I see. So every page file containing the charset definition
(ISO-8859-1 or UTF-8) will be displayed correctly regardless of the
xlpage settings, very good.
>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.
thanks for providing a painless way to migrate existing installations.
I like this much more than the earlier method to convert the page
I do the current tests on my private wiki (used as PIM), so I have
full control and no risk to annoy visitors.
Documentation is indeed important. As far as I understand, the three
entries do the following:
$DefaultPageCharset is a list of substitutions, e.g. "empty to
ISO-8859-1". Used for page files without or with wrong encoding.
xlpage-utf-8.php switches internal charset, output, (new) page storage
XLPage() loads a translation table which can in turn load a
Isn't the latter (xlpage-*.php from XLPage()) a relict from ages where
PmWiki didn't convert charsets on the fly?
The manual page file conversion mentioned in
http://www.pmwiki.org/wiki/PmWiki/UTF-8 shouldn't be necessary
There is also the statement that config.php encoding has an effect.
This should be explained in detail.
Oliver Betz, Muenchen (oliverbetz.de)
More information about the pmwiki-users