2024年8月17日(土) 9:17 Mike Schinkel <m...@newclarity.net>: > > > On Aug 16, 2024, at 8:02 PM, Rowan Tommins [IMSoP] <imsop....@rwec.co.uk> > > wrote: > > On 17 August 2024 00:25:13 BST, Mike Schinkel <m...@newclarity.net> wrote: > >> I am not sure I agree with you that adding Unicode support is the wrong > >> angle, per se. > >> > >> A strong argument could be made that Unicode support is a necessary but > >> not sufficient building block for "internationalization support." IOW, if > >> you want to get to the latter it is probably a lot easier to start with > >> the former as the scope of the latter is by-nature larger. After all, > >> perfect is the enemy of the good and waiting for a full-press effort for > >> internationalization support could well push off Unicode support long down > >> the road. > > > > Again, that's not really what I intended to say, but I'm probably not > > expressing myself clearly. > > > > I was thinking about the way we frame the conversation, the words we focus > > on, and how that shapes the conversation. > > > > The example that keeps coming to mind is password_hash/password_verify. It > > seems to me that for years, the conversation was framed around > > "cryptographically safe hashing functions", and teaching users why and how > > to use powerful but confusing functions like hash() and crypt(). Then it > > got reframed from the point of view of a web developer wanting to implement > > logins, and we ended up with fantastically easy to use functions. > > > > In the same way, I think "Unicode support" should be the awkward background > > work that we do *because we're trying to solve specific problems involving > > text*. > > > > In the case of this thread, I think the actual user story is "I want to > > allow users to enter a wide range of characters, but restrict them in > > contextually appropriate ways to ensure various types of safety and > > security". The implementation of that involves a lot of technicalities > > about how Unicode works, but ideally we want to find meaningful > > abstractions of those technicalities, not just require every user to > > understand them. > > We are in no real disagreement there. > > -Mike > > P.S. I do think we could reach the same end-goal by taking either direction > since Unicode support is a building block of solving specific problems > involving text, and thus needs to happen either way. > > But, as I implied earlier, whichever road takes us there works for me so no > need for me to further bikeshed it, as long as the road we take will not > result in a dead-end.
Hi, internals I added `grapheme_str_split` in PHP 8.4. I added this because I thought the function of grapheme function was missing. I think grapheme functions is still lacks functionality. I would like to add grapheme function. PHP's Unicode support is still not sufficient. I would like to strengthen PHP's Unicode support. After a while, I have plans I would like add RFC for Unicode functions. Regards Yuya -- --------------------------- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai -----------------------------
