character problem

When I turn the "locale" string, I get errors like this.
I think it's because the letters "I" and "i" are different in Turkish.
What can I do for it.

lower case: ı upper case: I
lower case: i upper case: İ

Not an official answer but I believe the uppercase string references should remain in English and only the strings themselves need translation. At least in the translations I've done, I haven't touched the original uppercase references.

Adam said

Not an official answer but I believe the uppercase string references should remain in English and only the strings themselves need translation. At least in the translations I've done, I haven't touched the original uppercase references.

From “How to convert my website to Composr cms”, 30th Apr 2020

I doubt this is it. Likely somewhere in the code is making a bad assumption about Unicode, that breaks when his locale is set.
Will look into it.

I only get errors when I change this.
old:    locale=en-GB.UTF-8,en_GB.UTF-8,en-US.UTF-8,en_US.UTF-8,en.UTF-8,en-GB,en_GB,en-US,en_US,en
new:  locale=tr-TR.UTF-8,tr_TR.UTF-8,tr.UTF-8,tr-TR,tr_TR,tr

What operating system is PHP running under? (Linux, Mac, Windows?)

Actually I can now reproduce on Linux with a simple test script, after I manually installed the Turkish locale on my box…


Outputs i, not I.

It's a fascinating problem, I had no idea it existed. I assumed that all the a-z latin characters had consistent casing and that Unicode would provide a new character if any language had any of its own behaviours.

I'll be thinking about how to solve this now.

Btw, it's been great seeing all the progress on Transifex for Turkish.

Ok, a workaround is now committed to git. It will be released with the next patch release.

A new language string 'locale_ctype_hack' is in Transifex and needs to be set to '1'.

The workaround disables the locale for upper/lower case stuff ('ctype'), and temporarily re-enables it only when doing upper/lower case for Unicode stuff. I think it should work well.

In the ideal world there'd be a cleaner solution, but my testing showed even PHP can't handle Turkish locale properly.
https://twitter.com/occhris/status/1155483073456365568

I was using Linux. The hosting service is also a temporary problem. I will try. There is no problem when I try it on the wamp server.
I used "locale_subst" for dates.
There are also php errors in the "compsr news" section in the admin zone. I think the reason is the same.
Thank you.

Chris Graham said

Ok, a workaround is now committed to git. It will be released with the next patch release.

A new language string 'locale_ctype_hack' is in Transifex and needs to be set to '1'.

The workaround disables the locale for upper/lower case stuff ('ctype'), and temporarily re-enables it only when doing upper/lower case for Unicode stuff. I think it should work well.

In the ideal world there'd be a cleaner solution, but my testing showed even PHP can't handle Turkish locale properly.
https://twitter.com/occhris/status/1155483073456365568

From “Post #5945”, 1st May 2020

I couldn't find the string you said on Transifex.
In the meantime, the main page translation is not done.

Sorry, it didn't push properly. It is there now. Remember though it won't make any difference until the next patch release is out and upgraded to.


Regarding the 'Home' issue – If things are already saved into the database (e.g. by the installer), they are outside the control of the language pack. In this case the 'Header-menu call string' config option's default setting (Admin Zone > Setup > Configuration > Theme options > General) has already been saved to contain 'Home'.

hank you for your help. I continue to receive different errors. It would be best to continue in English until the problems are resolved.
Thank you very much again.