Re: SRFI 198 Foreign Interface Errors: abusing alists for fun and non-profit
Lassi Kortela 17 Jul 2020 19:04 UTC
>> 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.