Bug #18556 [Com]: Setting locale to 'tr_TR' lowercases class names

Edit report at https://bugs.php.net/bug.php?id=18556&edit=1 ID: 18556 Comment by: tolga dot korkunckaya at gmail dot com Reported by: spud at nothingness dot org Summary: Setting locale to 'tr_TR' lowercases class names Status: Closed Type: Bug Package: Scripting Engine problem Operating System: Linux (RedHat 7.2) PHP Version: 5CVS, 4CVS (2005-10-04) Assigned To: stas Block user comment: N Private report: N New Comment: Here is the env information I've tested this issue: root@debian9:~# lsb_release -da No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux testing (buster) Release: testing Codename: buster root@debian9:~# uname -a Linux debian9 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) x86_64 GNU/Linux root@debian9:~# php -v PHP 7.2.4-1+b2 (cli) (built: May 29 2018 02:53:13) ( NTS ) Copyright (c) 1997-2018 The PHP Group Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies with Zend OPcache v7.2.4-1+b2, Copyright (c) 1999-2018, by Zend Technologies root@debian9:~# cat /etc/locale.gen | grep -v "#" en_US.UTF-8 UTF-8 tr_TR.UTF-8 UTF-8 root@debian9:~# apache2ctl -v Server version: Apache/2.4.33 (Debian) Server built: 2018-05-28T17:29:02 Previous Comments: ------------------------------------------------------------------------ [2018-06-24 03:03:46] tolga dot korkunckaya at gmail dot com The problem with the class names seems to be solved as of php version 7.2 However, the issue with lowercasing uppercase I (İ) and uppercasing lovercase i (ı) is still problematic. I'll create a new issue about this. ------------------------------------------------------------------------ [2018-05-17 10:48:01] requinix@php.net @klemen: Please be specific about what works and what does not. Example code would be nice. Also, PHP 7.0 is not actively supported anymore so make sure the problem occurs in 7.1 and/or 7.2. ------------------------------------------------------------------------ [2018-05-17 10:43:55] klemen dot praznik at innovatif dot com fyi it seems that this bug has resurfaced in PHP 7.x PHP 7.0.27-0+deb9u1 (cli) (built: Jan 5 2018 13:51:52) ( NTS ) Copyright (c) 1997-2017 The PHP Group Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies with Zend OPcache v7.0.27-0+deb9u1, Copyright (c) 1999-2017, by Zend Technologies ------------------------------------------------------------------------ [2016-04-29 14:59:17] marcin dot filip at gmail dot com Code to test is: $locales = array ( $language, $language.'.UTF-8', $language.'_'.strtoupper($language === 'en' ? 'us' : $language), $language.'_'.strtoupper($language === 'en' ? 'us' : $language).'.UTF-8' ); putenv('LC_ALL='.$locale); setlocale(LC_ALL, $locales); setlocale(LC_CTYPE, 'en_US'); bindtextdomain('messages', APPPATH.DS.'locale'); textdomain('messages'); bind_textdomain_codeset('messages', 'UTF-8'); In this example when you will set $language to "tr" everything is working but you must set LC_TYPE to en_US so in that moment we loose information about specific data from full locale data like currency, money formmating for that specific country. For me personally it's not problem but some of the coders that wish to use those features of local setting will be not able to do. Because they will be not able to follow the locale specification. Any ideas about to make it strait one like should be and have peaceful head? It is hard to isolate interpreter setting from global one? To always match php code in same way? This is code from my test of setting locale. And result are some if you will remove setting LC_TYPE to en_US you will end with wrong class names and than autoloader is not finding classes because they end with bad names where i is not i and everything is lowercased i names. I think you have same problem with this for long time and not provide proper architecture of in! terpreter to avoid change of crusial settings from php code level. ------------------------------------------------------------------------ [2016-04-16 12:30:11] nikic@php.net @necmettin: Per the previous comments of stas and jpauli, this issue has been fixed in PHP 5.5 and above only, so this issue persisting on 5.4 is to be expected. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=18556 -- Edit this bug report at https://bugs.php.net/bug.php?id=18556&edit=1