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) _______________________________________________ pmwiki-users mailing list [email protected] http://www.pmichaud.com/mailman/listinfo/pmwiki-users
