[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gettext-based localization

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.


Attachment: pgp8Pc7jprhaK.pgp
Description: PGP signature