[php-src] Issue #8096: mb_convert_case($str, MB_CASE_TITLE, "UTF-8"); doesn't convert the Greek last letter to ς but to σ

From: Date: Sat, 09 Apr 2022 18:13:17 +0000
Subject: [php-src] Issue #8096: mb_convert_case($str, MB_CASE_TITLE, "UTF-8"); doesn't convert the Greek last letter to ς but to σ
Groups: php.bugs 
Request: Send a blank email to php-bugs+get-240817@lists.php.net to get a copy of this message
Issue: https://github.com/php/php-src/issues/8096 Comment Author: alexdowad > I think basing this off mbstring.language is viable, though we'd want to make sure that > the language can also be passed explicitly to the relevant case-conversion functions, so as to avoid > dependence on global state. I don't think that adding per-language functions makes sense. OK, cool. Would adding an optional 3rd argument to mb_strtolower et al require an RFC or something? The languages recognized by mbstring are English, German, Armenian, Japanese, Korean, Russian, Turkish, Ukrainian, and Chinese. Then we have languages called "neutral" and "universal". 🤷‍♂️ So we would need to add Lithuanian and Azeri there? > Supporting Turkish case folding rules at least would probably be of some value, as the way > dotted i is handled under default case folding is often perceived as undesirable (creates I with an > additional combining mark). I believe we already special-case one Turkish legacy encoding in this > regard. OK. More homework for me to look into that. I guess we would keep the same behavior to avoid a BC break, even if mbstring.language is not Turkish? > Yes, locales are easily one of the contenders for "worst design mistake in C", though > of course there is a lot of competition in this space ;) OK, thanks for confirming my feelings on that issue. Side note: Have you ever seen the implementation of the POSIX/C locale APIs in musl libc? It's not to be missed.

« previous php.bugs (#240817) next »