> We have previously contemplated what to do about current-locale, per
> Lassi it's much less useful than us US people would think, although John
> noted it's important for date formatting, and I note it's grossly
> under-specified unless we just return something like what the Linux
> locale(1) returns on my two systems:

Your lists are a great example of how much stuff we will have to deal
with if we choose to include locale stuff in the OS SRFIs :)

> Perhaps defer to a localization SRFI?

I would be strongly in favor of that. It might even make sense to have
more than one localization SRFI (one with the essentials to solve the
80% case, and another with some kind of full support that people like
John and Shiro know much more about).

One of the most common use cases for the locale stuff is simply
(get-localized-string "some string"). Optionally with printf-like
parameters. That would make for a pretty simple SRFI (at least it seems
simple now :D)

> Which could ideally allow fine
> grained control so one could for example run a Japanese Scheme
> application such that it think it's native, with an Input Method Editor
> (IME), while the system is naively Anglosphere or European.

We should definitely ask Shiro about how to best support that. He's put
a lot of effort into Gauche's multilingual support.