Re: [Phpwiki-talk] (unstable) utf-8 developer version available on request

[Reini U. <ru...@x-...>]

Reini Urban schrieb:
> I prepared now a multibyte string aware phpwiki version (UTF-8), which 
> requires PCRE with UTF-8 support, and the mbstring extension.
>   (probably the iconv extensions also)

I'v put the patch (gzipped) at 
http://phpwiki.sourceforge.net/demo/phpwiki-1.3.11-utf8.patch.gz (34kb)

described in http://phpwiki.sourceforge.net/phpwiki/Utf8Migration

> Additionally all locale po files and pgsrc files must be converted 
> (there's a script) and all pages cache must be purged, or better load a 
> fresh virgin wiki.
> 
> It required hundreds of changes to most string functions, like prefixing
> substr,strlen,strtolower,strotupper,strpos,... with "mb_",
> adding the "u" modifier to all pcre_* calls, and so on.
> 
> As long as the DB backends don't support it that well, I don't want to 
> maintain it, but I try to keep it up-to-date.
> I still have a lot of InlineParser errors with the $hugepat
>   lib\InlineParser.php:188: Warning[2]: Compilation failed: invalid 
> UTF-8 string at offset 1440
> Either pcre is broken, or some string function destroys a string.
> There are still some string functions left, for which no equivalent mb_ 
> function exists. (str_replace e.g.)
> Does anybody want to have a look or should I hack away until it works 
> (if time permits)?
> 
> Sometimes, we must switch to UTF-8 anyway. See PhpWiki:Utf8Migration.
> 
> For now I think it is enough to use the mbstring and PCRE detection 
> functions in CVS HEAD, and display a proper warning. e.g. sf.net has 
> such an old php (4.1.2) and no mbstring, that utf-8, chinese and 
> japanese cannot work there. maybe that's why the wikipedia folks have to 
> maintain their own set of webservers with current PHP versions.
> 
> I don't really want to maintain an utf-8 CVS branch. Tested snapshots 
> are enough I think.


-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/