>>     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.

Enthusiastically agreed:

- SRFI 198 should use neither the C gettext library nor a Scheme gettext
wrapper/reimplementation.

- Individual library bindings returning SRFI 198 error objects should
only use gettext if the binding's author knows that gettext is the
officially blessed source for error message translations for the library
being wrapped.

- If gettext is not the officially blessed localization source, then the
binding should only return messages from the official source (perhaps
only in US English or whichever language is the official one). Scheme
programmers who want to translate those messages can manually pass the
result from `foreign-error:message` to the gettext SRFI.