[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.

Scott G. Miller wrote:
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.

You've addressed the use of the gettext backend, but I'm also concerned
about the API for getting a localized string.  I think we should
discuss that separately.

Specifically, I think:
  (gettext "MESSAGE")
is simpler to use than:
  (localized-template 'PACKAGE 'MESSAGE-TAG)

I.e. instead of having to come up with a MESSAGE-TAG for each
message, why not use the primary-language "MESSAGE" as it's own
template?  This is much simpler and convenient, plus of course
it is compatible with the GNU gettext paradigm, which I think is
desirable.  (Primary-language need not mean English, of course, but
it should be one that both the programmers and likely translators
are comfortable with.)

Secondly, specifying the PACKAGE on each usage is tedious. Instead,
it is more convenient to just use an initial textdomain declaration.

If you make these changes, you might as well call the function
'gettext', regardless of the back-end format.  You can still
have declare-bundle.
	--Per Bothner
per@xxxxxxxxxxx   http://www.bothner.com/per/