Yes I understand but unfortunately I don't speak Japanese. Rui, is it possible for you to try and get more involvement from the team that worked on this and get more tests?
Btw, I think if we use the existing infrastructure Rui and the team built (see no big reason why not for 5.3) then we can also go somewhat lighter on the amount of testing as there'll be less chances for breakage. Andi > -----Original Message----- > From: Marcus Boerger [mailto:[EMAIL PROTECTED] > Sent: Monday, March 24, 2008 4:36 PM > To: Andi Gutmans > Cc: Alan Knowles; Johannes Schlüter; Hannes Magnusson; Rui Hirokawa; > internals@lists.php.net > Subject: Re: [PHP-DEV] Re: PHP's Zend multibyte support > > Hello Andi, > > claiming you have heard doesn't bring us any further though. Please > provide tests other wise I cannot fix and reimplement what is there. > Right > now I only got one extremely basic test that only checks for a very > very > limited part of what the stuff is designed for. > > marcus > > Monday, March 24, 2008, 11:15:21 PM, you wrote: > > > I think many of these encodings are still very much alive. I am > pretty > > sure that still a large amount of the Japanese market uses Shift-JIS. > The > > majority of the tools/text editors use this format as opposed to UTF- > 8. > > > Andi > > >> -----Original Message----- > >> From: Alan Knowles [mailto:[EMAIL PROTECTED] > >> Sent: Monday, March 24, 2008 8:13 AM > >> To: Johannes Schlüter > >> Cc: Hannes Magnusson; Marcus Boerger; Rui Hirokawa; > >> internals@lists.php.net > >> Subject: Re: [PHP-DEV] Re: PHP's Zend multibyte support > >> > >> Reading through this, It looks like this is aimed at Big5/shiftJS/? > >> maybe korean?? > >> > >> I know from HK and probably TW, who use Big5 (traditional chinese > >> encoding), that it's pretty much been phased out with the > introduction > >> of unicode (basically AFAIR Windows 95/98/ME/NT chinese editions > used > >> these encodings, latter versions of windows have used UTF8). This > >> tended > >> to be an issue that old browsers on these platforms tended to need > Big5 > >> encoded web pages, so alot of stuff was written at Big5. > >> > >> Basically I don't think these days (in the last 3 years at least) > >> anyone > >> develops sites that target Big5, (we all use UTF8) and if they do, > it's > >> probably only done as a last stage iconv conversion. > >> > >> So is there a current need for this? - or is it just a legacy issue, > >> which could be dropped anyway for PHP6? > >> > >> Regards > >> Alan > >> > >> > >> > >> > >> Johannes Schlüter wrote: > >> > Hi, > >> > > >> > On Sun, 2008-03-23 at 15:26 +0100, Hannes Magnusson wrote: > >> > > >> > > >> >>> You can provide a --SKIPIF-- section to detect MB support > >> (http://qa.php.net/write-test.php ). > >> >>> --SKIPIF-- > >> >>> <?php > >> >>> if (!in_array("detect_unicode", array_keys(ini_get_all()))) { > >> >>> die "skip Requires --enable-zend-multibyte option"; > >> >>> > >> >> WTF? Where did that INI entry come from? :) > >> >> > >> >> It isn't in php.ini-dist and the only docs I can find is > >> >> (http://no.php.net/manual/en/ini.php): > >> >> detect_unicode "1" PHP_INI_ALL Available since PHP > >> 5.1.0. > >> >> Removed in PHP 6.0.0. > >> >> > >> > > >> > According to my research when the MB issues popped up that setting > >> was > >> > added as a hack to help the scanner to have less confusion with > it's > >> > encoding detection when using __HALT_COMPILER(); There's an > internals > >> > discussion, but i don't have it at hand right now. > >> > > >> > > >> >> Is it really PHP_INI_ALL? That doesn't make much sense to me. I > >> >> thought the multibyte scanning was compile time? > >> >> (Or is it like the current short_tags proposal; > >> >> ini_set("detect_unicode"); include "..."; ?) > >> >> > >> > > >> > Yes, it's for the latter, I guess. > >> > > >> > johannes > >> > > >> > > >> > > >> > >> > >> -- > >> PHP Internals - PHP Runtime Development Mailing List > >> To unsubscribe, visit: http://www.php.net/unsub.php > > > > Best regards, > Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
