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.
(PS I think I accidentally called you Rob just now; sorry!)
Rowan Tommins
[IMSoP]
