I've put up a gettext-like package for download at
randallsquared.com/download/ .
This package is versioned at 0.8, and has ~80% of the functionality
that I'd like in such a thing, right now. The main things missing
are saving and loading of domains (terminology deliberately stolen
from GNU gettext), but gettext exports save and load methods, so
you can define these yourself without messing around in the package.
It's less than 150 lines total, including documentation.
Why am I cluttering cll with releases of tiny libraries? Well,
because these are things I looked for when first seriously considering
learning Common Lisp, and not finding anything like them kept me
from bothering with CL for some time. Further, it's faster and
easier to just announce this here than to write lots of explanatory
text for the my website, which is more business-oriented anyway.
But aren't these libraries trivial (I hear you cry)? :)
Yep, they are. However, when I was first learning CL, the argument
that these sorts of libraries didn't exist publicly because they were
so *easy* seemed bogus. So while those of you who've been using CL
for more than a few months will undoubtedly find little of use in
things like my gettext package and unicode package, I want those
searching for these in the future to find them, so it's clear that
such things do exist.
--
Randall Randall <·······@randallsquared.com>
Property law should use #'EQ , not #'EQUAL .
+ Randall Randall <·······@randallsquared.com>:
| But aren't these libraries trivial (I hear you cry)? :)
|
| Yep, they are. However, when I was first learning CL, the argument
| that these sorts of libraries didn't exist publicly because they
| were so *easy* seemed bogus.
As far as I recall those discussions, /ease of implementation/ was
just half of the argument. The other half, as I understand it, is
that good /library design/ is actually quite /hard/. I'm not talking
about implementation now, but protocol. Once you have the protocol
right, users will not be tempted to screw around with the internals of
the library because they can get what they want through the protocol.
(They may be tempted to impove on the implementation, but so long as
the protocol remains unchanged that's OK.) If the protocol is not
well thought out, the library will fall into disuse, or it will fork
into umpteen versions using different protocols, and confusion will
result.
| So while those of you who've been using CL for more than a few
| months will undoubtedly find little of use in things like my gettext
| package and unicode package, I want those searching for these in the
| future to find them, so it's clear that such things do exist.
I think it's good that you do this, the above comments
notwithstanding. Your libraries cover a need, and if nothing else,
people can look at them and borrow code and ideas for their own
implementation. If you're onto something, maybe you'll get enough
good feedback for the libraries to evolve into something
semi-standard. (If they're not good enough already. I haven't looked
at them yet, so none of the above should be construed as criticism.)
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
Harald Hanche-Olsen wrote:
> the protocol remains unchanged that's OK.) If the protocol is not
> well thought out, the library will fall into disuse, or it will fork
> into umpteen versions using different protocols, and confusion will
> result.
It's my opinion that having umpteen widely varied versions is preferable
to none at all. So, even if the protocols in question aren't well
thought out, either some better protocol will appear, and we'll all
switch, or it won't, and the poorly thought out one will at least be
available.
> | So while those of you who've been using CL for more than a few
> | months will undoubtedly find little of use in things like my gettext
> | package and unicode package, I want those searching for these in the
> | future to find them, so it's clear that such things do exist.
>
> I think it's good that you do this, the above comments
> notwithstanding. Your libraries cover a need, and if nothing else,
> people can look at them and borrow code and ideas for their own
> implementation. If you're onto something, maybe you'll get enough
> good feedback for the libraries to evolve into something
> semi-standard. (If they're not good enough already. I haven't looked
> at them yet, so none of the above should be construed as criticism.)
Well, they're not at 1.0, which is evidence that even I
don't consider them good enough, yet. My largest reason
for writing them is still my own personal use, of course;
if any of you find them useful, that's a nice bonus. :)
--
Randall Randall <·······@randallsquared.com>
Property law should use #'EQ , not #'EQUAL .
The "real" GNU gettext has support for Common Lisp since version 0.11,
more than two years ago. You can use 'xgettext' on a Lisp program like
you would on a C program. See
http://www.gnu.org/software/gettext/manual/html_node/gettext_200.html
for details.
The only Common Lisp implementation so far that provides the run-time
support (for loading GNU .mo files, in particular) is GNU clisp. Its
API is described in
http://clisp.cons.org/impnotes/i18n.html#ggettext
Other implementations are invited to implement the I18N:GETTEXT, I18N:NGETTEXT
functions as well.
Bruno
Bruno Haible <·····@clisp.org> wrote:
> The only Common Lisp implementation so far that provides the run-time
> support (for loading GNU .mo files, in particular) is GNU clisp. Its
> API is described in
> http://clisp.cons.org/impnotes/i18n.html#ggettext
From here the above site:
or ease of reading, it is customary to define an abbreviation for
the I18N:GETTEXT function. An underscore is customary.
Example 29.3. prog.lisp
(setf (textdomaindir "prog") "./")
(defun _ (msgid) (gettext msgid "prog"))
(setq n (parse-integer (first EXT:*ARGS*)))
(format t "~A~%"
(_"'Your command, please?', asked the waiter."))
How about a reader macro? Eg. #I"..." that will automagically create the
entry for the translation catalogue and will replace the call with the
appropriate gettext-like function. (Are msgids always strings, BTW?)
BTW: Is there any further internationalisations support for CL (eg. date
parsing and writing, numbers, currencies)?
-ts
--
,,
\../ / <<< The LISP Effect
|_\\ _==__
__ | |bb| | _________________________________________________
From: Duane Rettig
Subject: Re: Gettext support for Common Lisp
Date:
Message-ID: <4n00c1am9.fsf@franz.com>
Thomas Schilling <······@yahoo.de> writes:
>
> BTW: Is there any further internationalisations support for CL
> (eg. date parsing and writing, numbers, currencies)?
Yup. See
http://www.franz.com/support/documentation/6.2/doc/iacl.htm#localization-1
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
On Tue, 31 Aug 2004 00:55:37 +0200, Thomas Schilling wrote:
> Bruno Haible <·····@clisp.org> wrote:
>> The only Common Lisp implementation so far that provides the run-time
>> support (for loading GNU .mo files, in particular) is GNU clisp. Its
>> API is described in
>> http://clisp.cons.org/impnotes/i18n.html#ggettext
http://users.actrix.co.nz/mycroft/intl.lisp (also reads GNU .mo files)
> From here the above site:
> or ease of reading, it is customary to define an abbreviation for
> the I18N:GETTEXT function. An underscore is customary.
> Example 29.3. prog.lisp
> (setf (textdomaindir "prog") "./")
> (defun _ (msgid) (gettext msgid "prog"))
Making GETTEXT (and by extension, _) a function is wrong, though --
what if several applications coexist in the same Lisp image, but want
to be in different domains?
You have to wrap (let ((*domain* ...)) ...) around everything?
> (setq n (parse-integer (first EXT:*ARGS*)))
> (format t "~A~%"
> (_"'Your command, please?', asked the waiter."))
> How about a reader macro? Eg. #I"..." that will automagically create
> the entry for the translation catalogue and will replace the call with
> the appropriate gettext-like function. (Are msgids always strings,
> BTW?)
Yup; mine defines an _"..." reader macro that does that.
--
The State is the great fiction by which everyone seeks to live at the
expense of everyone else. -- Fr�d�ric Bastiat
(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(··@) "actrix.gen.nz>"))
Paul Foley wrote:
> Making GETTEXT (and by extension, _) a function is wrong, though --
> what if several applications coexist in the same Lisp image, but want
> to be in different domains?
As discussed in email, I think "wrong" is the wrong word
here. Making GETTEXT and '_' a function may or may not
be a good idea for client-side apps, but for server-side
apps, you may want to have several applications which are
using some of the same actual source coexisting in the
same Lisp image, so switching from one domain to another
at runtime is a useful feature.
--
Randall Randall <·······@randallsquared.com>
Property law should use #'EQ , not #'EQUAL .
Paul Foley <···@below.invalid> wrote:
>
> Making GETTEXT (and by extension, _) a function is wrong, though --
> what if several applications coexist in the same Lisp image, but want
> to be in different domains?
Each of the applications will define its own _ function in a different
package. That's what packages are for.
> Yup; mine defines an _"..." reader macro that does that.
It's an interesting idea. But when you have a package whose
implementation is scattered over several source files, you have to
set the textdomain once in each source file. Whereas when _ is a
function, you have to set the textdomain and define the _ function
just once for all.
Bruno