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

On Fri, Apr 12, 2002 at 11:18:08AM -0700, Per Bothner wrote:
> 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.)
I don't have an argument against chaning the tag to a string in the
primary language, but I still believe that 'PACKAGE is necessary to
divide multiple distinct programs into namespaces to avoid conflicts.  

Also, as an argument against "MESSAGE", it causes you to sprinkle ugly 
templated messages all over the source code.  This is debatable of 

> Secondly, specifying the PACKAGE on each usage is tedious. Instead,
> it is more convenient to just use an initial textdomain declaration.
Not if you have one piece of code calling another, both independently 


Attachment: pgpJvi4amBNi4.pgp
Description: PGP signature