> I continue to think that translation within SRFI 198 is not necessary;
> translate on the C side or on the Scheme side using a SRFI designed for
> the purpose.

I understand that general-purpose translation APIs are useful, but I
don't understand the argument that the error message translation API
should be fully decoupled from the error message API.

A wholly different translation API is all well and good if you do all
your own translations of error messages. But SRFI 198 is meant primarily
to bring _other people's_ error messages into _your_ application,
without work on your part. Some error message collections (e.g. WinAPI)
have already been translated by the vendor and the translations are
available via the same C API as the English messages. In this sense the
natural thing to do is to ask that API. For example, to get the error
from WinAPI use FormatMessage(). Getting a translated message is the
same FormatMessage(), just pass a different language ID to it. That's
what my proposal for localized message support is getting at.

Independently of this, a generic localization SRFI should exist, but I
don't see how this is not also useful.