[pmwiki-users] PmWiki.org UTF-8 migration complete

[Oliver Betz]

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
files.

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
to UTF-8.

XLPage() loads a translation table which can in turn load a
xlpage-*.php.

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
anymore, correct?

There is also the statement that config.php encoding has an effect.
This should be explained in detail.

Oliver
-- 
Oliver Betz, Muenchen (oliverbetz.de)