>>     I don't like localized error messages for another reason. When you
>>     don't know what to do with the error message (say, a compiler warning)
>>     and you search the web for it, it works best if everyone uses the same
>>     search term and not some localized version. :)

Indeed. The localized ones can be baffling even to experts. This is
perhaps an advantage of free software / open source since the people
translating the messages are more technical on average and at any rate
it's easier for outsiders to send improved translations.

>> Not only are these things true, but there is already l10n on the C
>> side available, and I have a l10n pre-SRFI to use on the Scheme side.
>> I see no point in adding yet a third l10n facility inside this glue.
>
> https://github.com/johnwcowan/r7rs-work/blob/master/GettextCowan.md ??

Is this only for GNU gettext? The SRFI 198 localizations are meant to
come from arbitrary sources (any C API or other foreign API, whether
it's gettext, Windows FormatMessage() or anything else).

> Would need to be extended to allow the user to see both his default
> localisation and the standard English searchable one as Marc notes.
> Does not look like it creates another dependency on finalizing SRFI 170,
> depending on how that extension would work.

That seems right. Since SRFI 198 translations are just strings and are
all optional, they don't introduce a mandatory dependency on any other SRFI.