This page is part of the web mail archives of SRFI 29 from before July 7th, 2015. The new archives for SRFI 29 contain all messages, not just those from before July 7th, 2015.
> The SRFI doesn't discuss any existing localization APIs. > I suggest it might be a better to come up with an API > that can work with existing tools and standards. Specifically, > I would recommend an API that can be implemented using the > GNU gettext package. > > I suggest these two functions: > > (textdomain 'PACKAGE-NAME [LOCALE-DIR]) > Look for translations for the package named PACKAGE-NAME. > The translation files are in LOCALE-DIR, which has an > implemengtation-specific default. > > (gettext "MESSAGE") > Look for a translation for "MESSAGE". If one is found, > return it; otehrwise return "MESSAGE" unchanged. > > Example: > (textdomain 'hello-program) > (display (format (gettext "Hello, ~a!") myname)) > > A trivial no-op implementation: > (define (textdomain . args) 'ignore) > (define (gettext msg) msg) I think that this approach may be too specific to gettext. I'd rather modify the SRFI in such a way that it allowed bundles to be stored/retrieved to a system-provided localization service, but that it still accept association lists to create bundles from within Scheme. An implementation that uses gettext as a backend then need only implement declare-bundle to store to a gettext compatible format. This may not be sufficient, but in general my concern is that the SRFI is supposed to allow portable, local independent messages to be displayed, but if it requires translations into a bunch of system dependent localization formats, then its a failure. Scott
Description: PGP signature