On Sat, May 14, 2011 at 7:28 AM, Platonides <[email protected]> wrote:
> TS-852 was a change done later than October 2010. There was a change
> to php involving setlocale() that could be related, though.
Do you know about the details of the change?
Is there a particular reason to use "en_US.UTF-8", not "C" for
LC_CTYPE? Currently, setlocale("LC_CTYPE", "0") in PHP returns
"en_US.UTF-8", which seems unreasonable. All others are filled with
"C", as setlocale("LC_ALL", "0") returns "/en_US.UTF-8/C/C/C/C/C".
I hope we can change it to "C". As I mentioned in TS-923, with "C",
the ucfirst and strtoupper doesn't corrupt strings.
- Whym
On Sat, May 14, 2011 at 7:28 AM, Platonides <[email protected]> wrote:
> On Fri, May 13, 2011 at 11:51 PM, Giftpflanze <[email protected]> wrote:
>>> The behavior of string
>>> processing seem to have changed in different programs almost
>>> simultaneously, somewhere around October 2010.
>>
>> It may be connected with TS-852 [*] which was resolved on 2010-12-08.
>
> TS-852 was a change done later than October 2010. There was a change
> to php involving setlocale() that could be related, though.
>
> _______________________________________________
> Toolserver-l mailing list ([email protected])
> https://lists.wikimedia.org/mailman/listinfo/toolserver-l
> Posting guidelines for this list:
> https://wiki.toolserver.org/view/Mailing_list_etiquette
>
_______________________________________________
Toolserver-l mailing list ([email protected])
https://lists.wikimedia.org/mailman/listinfo/toolserver-l
Posting guidelines for this list:
https://wiki.toolserver.org/view/Mailing_list_etiquette