>>     Since this is an API for */foreign/* interfaces, we can't know now
>>     what facilities the foreign systems might have for localization.
>>     We must provide our own for those who want to localize an
>>     interface to a system without localization,
>>
>> I don't see why that is a must, especially if we have a localization
>> API in pure Scheme. This is an interface to foreign facilities, and if
>> the facility doesn't localize errors, then it doesn't.
>
> True enough, the "we must provide" is the total ecosystem, in which this
> SRFI would as needed interface with a pure Scheme localization API.  Can
> we do that transparently, as
> https://github.com/johnwcowan/r7rs-work/blob/master/GettextCowan.md does, while
> also fulfilling Lassi and Marc's requirement to access the search engine
> friendly default English messages?
>
> Based on my study of your gettext just now, it appears to me that
> something like Lassi's locale aware API plus it could satisfy the
> requirement, whereas a naive use of gettext wouldn't.

It's even more complicated than that... in general, there is no
"default" language for error messages. And English messages are not
guaranteed to be installed even when some other language is.

US English is the lingua franca of computing, so in practice, most of
the time the canonical error messages are the US English ones. In this
sense it is often the "default" language in which the original messages
are by the software author.

However, another sense of "default" concerns the user's installation of
the software. If someone installs the Swedish version of Windows, then
Swedish is the "default" system language on that computer. Apparently
Windows allows individual users to change their language independently
of each other, so WinAPI has a separate concept of a user language,
which is another kind of "default".

In sum, there are so many different kinds of default that IMHO our
Scheme API should not talk about any "default" language at all. We
should just provide an alist of (language . message) pairs, and the
first entry in the list is effectively the "default".

1) Since we don't advertise anything as being the "default", we don't
break any promises if the first entry is in a weird language.

2) Individual Scheme libraries making foreign error objects can put the
languages in a sensible order so that the first one is something good
for most situations, utilizing context-sensitive knowledge that we as
SRFI writers can't have.

3) Users of this SRFI who really want a particular language can still
ask for that language explicitly, so they don't lose any functionality.

4) Calls to `(foreign-error:message ferr [locale]) → string|#f` can be
chained easily even for complex tasks:

(or ;; First try Swedish:
     (foreign-error:message ferr 'sv_SE)
     ;; If that didn't work, try US English:
     (foreign-error:message ferr 'en-US)
     ;; Then British English:
     (foreign-error:message ferr 'en-GB)
     ;; Then the first thing they have:
     (foreign-error:message ferr)
     ;; Else give up:
     "Unknown error")

We can also give results from this API to a generic gettext API if we
want to supply our own translations: (gettext (foreign-error:message
ferr 'en-US)). So things are nicely composable.

Here are (some of) the Microsoft docs:
https://docs.microsoft.com/en-us/windows/win32/intl/language-identifiers