Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:48002
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fmethod.com from 72.14.220.152 cause and error)
Message-ID: <6BF24C36133C4E919CFAA5A66278D531@pc>
To: "Adam Harvey" <aharvey@php.net>,
	<internals@lists.php.net>
References: <r2se50d0a481004182058i1ca96f6ka9f7a4e545c98e5e@mail.gmail.com>
Date: Mon, 19 Apr 2010 07:59:15 +0300
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="UTF-8";
	reply-type=original
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Turkish/Azeri locale support
From: sv_forums@fmethod.com ("Stan Vassilev")

>As at least some of you would already be aware, there's a
>long-standing issue with using PHP in a Turkish or Azeri locale,
>namely that case-insensitive lookups within the Zend engine (method
>names, for example) fail on lookups involving upper-case I characters,
>since lower-case I in those languages is ı instead of i (note the lack
>of a dot).

>The long term plan for this, per bug #35050 and any number of
>duplicates, was to deal with it in PHP 6. Since PHP 6 isn't going to
>happen in its original form, I think we're going to need to revisit
>how we want to deal with this. There's a patch linked in the bug from
>Tomas Kuliavas and Marcus that fixes the problem by simply redefining
>zend_tolower() to a simple locale-insensitive ASCII tolower()
>function, which does fix the Turkish and Azeri locales.

As you illustrated in your post, fixing it for locales becomes... 
complicated.

If you ask me, there's only one way to fix this, which is how most other 
languages fixed it: make the next major version of PHP case-sensitive for 
all identifiers. For less bugs, less locale problems and more performance.

It was somewhat-the-plan, even before the Turkish locale issue was brought 
up.

Regards,
Stan Vassilev