emacs-devel
[Top][All Lists]
Advanced

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

Re: Key bindings proposal


From: Stephen J. Turnbull
Subject: Re: Key bindings proposal
Date: Thu, 05 Aug 2010 20:55:57 +0900

Andreas Schwab writes:
 > "Stephen J. Turnbull" <address@hidden> writes:

 > > The real problems are in getting LISP to be internationalized, ie,
 > > integrating string-handling with gettext.  Should concat look up
 > > strings?  Should the LISP interpreter do it when passing args?  etc.
 > 
 > Of course not.  Strings are to be translated when they are presented to
 > the user, which is a high level concept.  Translatable strings must be
 > explicitly marked.

Marked, yes.  That's the way gettext works from the programmer's
standpoint.  In C, that translates to a function call.  Cheap.
Function calls are not so cheap in LISP, though, nor is allocating
strings.  And while you perhaps might be happy with code like

(defun parental-warning (dependents)
  (format (gettext "It's %s %s; do you know where your %s are?")
          (format-time-string "%I")  ; URK URK URK! is this right?
                                     ; not everybody uses Arabic numerals!
          (gettext (format-time-string "%p")) ; or is this f-t-s's job?
          (gettext dependents)))

I sure hope Emacs can do better.  Eg, it might make sense to have
either the interpreter or certain subrs call gettext on marked strings
(where the marking is done by the LISP reader on literals).  Or it
might make sense to have *un*marked strings automatically translated
in those contexts.

And "high-level"?  Maybe, maybe not.  In some important cases it may
make sense to assemble a large variable string from many pieces.  It
is not at all obvious to me that passing all strings to top level,
where they are translated then concatenated, is always possible, let
alone always a sane way to organize a program.

P.S. (defsubst _ (s) (gettext s)) doesn't cut it, except as a last
resort.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]