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. -elf On 25/07/2020 20:53, xxxxxx@ancell-ent.com wrote: >> From: John Cowan <xxxxxx@ccil.org <mailto:xxxxxx@ccil.org>> >> Date: Saturday, July 25, 2020 12:29 PM >> >> On Mon, Jul 20, 2020 at 6:38 PM Lassi Kortela <xxxxxx@lassi.io >> <mailto:xxxxxx@lassi.io>> wrote: >> > > I'm swapping the order of the discussion, this was the last bit: > >> I'm coming from the expectation that the APIs from which we can >> get error message translations are as many and varied as the error >> messages themselves. In this world, the code that gets the error >> from C is best equipped to figure out where to get its >> translations (if any). Maybe it will use gettext, maybe it has to >> use something else. >> >> >> +1 > > 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, and have some standard method to access the > messages of a system with localization. > > For those creating//an error-set collection, make-foreign-error could be > handed an alist, keys are locale, values are the message, or based on > your thoughts below, a procedure to fetch one based on the optional > locale argument and the particular error, the latter data naturally > being in the foreign-error:code slot, like (number . 2) for the errno > error-set. > >> I probably misunderstood some aspect of your argument. Are you >> envisaging a world in which gettext() is the only C-side >> translation API, and all error message translations come from >> gettext catalogs? In that case your suggestion would indeed make a >> lot of sense. >> >> >> I was, yes. But I see now that that is inadequate. >> >> How about the simplest thing etc.? I think that would be on extra >> procedure (foreign-error:localized-message error-object >> locale-string), which does whatever's needed to fetch a localized >> version of the error message and returns it (or the original if it >> doesn't have anything else)? Of course the locale-string could just >> be an optional argument to foreign-error:message instead, in which >> case #f would mean "always use the original". > > The latter was Lassi's original design for the API in > https://github.com/lassik/scheme-foreign-error-wip: > >> (foreign-error:message ferr [locale]) → string >> >> (foreign-error:locales ferr) → list of symbols > > It strikes me as very simple and straightforward, vs. a > foreign-error:localized-message procedure like the one you initially > posit above. > > - Harold >
