Re: SRFI 198 Foreign Interface Errors: abusing alists for fun and non-profit Lassi Kortela (26 Jul 2020 21:08 UTC)
Interaction of gettext and SRFI 198's localization feature Lassi Kortela (26 Jul 2020 21:21 UTC)

Re: SRFI 198 Foreign Interface Errors: abusing alists for fun and non-profit Lassi Kortela 26 Jul 2020 21:08 UTC

> Pardon me if this is stupid, or if i missed part of the conversation...
> but since when are error messages the only things needing localisation?
>
> Wouldn't the simplest interface be something along the lines of
> (foreign-message:localised <type/id/whatever>)
>
> You could expand this into two fields of
> (foreign-message:localised <type> <id>)
> where <type> could be 'error, 'info, etc and <id> could refer to the
> specific message being fetched - basically making life easier by
> namespaces - unless i missed something earlier.

A big part of the raison d'etre for SRFI 198 is to provide just such a
classification system - but for errors, not for messages in general.

Why classify errors, and not more general things? The idea is to follow
the way C APIs are built. Most featureful C APIs have an error table
like this:

#define LIBFOO_ERROR_NO_SPACE 1234
const char *libfoo_error_message(int error_code);

The most full-featured ones are essentially like this:

#define LIBFOO_ERROR_NO_SPACE 1234
const char *libfoo_error_message(int error_code, int language);

Or:

int libfoo_error_code(libfoo_context_t ctx);
const char *libfoo_error_message(libfoo_context_t ctx);

Anyone writing Scheme FFI bindings to libfoo would have easy access to
these functions, so if they can return localized or context-aware error
messages, we should take advantage of the opportunity and provide a way
to return those to Scheme. The most natural way to do that is to stash
them in the error object that the libfoo binding is going to return anyway.

Of course, nothing prevents Scheme programmers from translating, say,
the English libcurl error messages to Swahili, shipping those message
catalogs with their Scheme program, and using a generic gettext
procedure to turn the English error messages from libcurl into Swahili.

This may seem like feature creep, but it's worth remembering that a
prefectly adequate API is just (error-message error-object [language])
-> string|#f. This is not complex stuff, and wrappers for C APIs that
know they only return English messages can just return #f for everything
else.