emacs-devel
[Top][All Lists]
Advanced

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

Re: Fwd: A system for localizing documentation strings


From: Eli Zaretskii
Subject: Re: Fwd: A system for localizing documentation strings
Date: Fri, 27 Jul 2007 14:12:42 +0300

> From: "Stephen J. Turnbull" <address@hidden>
> Cc: Andreas Schwab <address@hidden>,
>     address@hidden,
>     address@hidden
> Date: Fri, 27 Jul 2007 11:33:51 +0900
> 
>  > If it does, how does the problem of marking the strings with _() in
>  > C/C++ (or rather lack thereof), to get their translations looked up,
>  > get solved?
> 
> You mark them as dummies so that the extraction tool (typically
> xgettext but Emacs may need a special tool) will put them in the pot
> file.  Then you arrange that they get gettextized at the point of use,
> as usual:
> 
>     /* This work is fiction; any resemblance to real Emacs identifiers
>        is a pure coincidence.  Except `gettext' plays itself. */
>     docstring = gettext (fetch_docstring_from_DOC (index, docfile))
> 
> or
> 
>     (let ((docstring (gettext (documentation-property symbol))))
>       ;; format for display
>       )

Sorry, I'm probably too dumb this morning, because I don't think I
follow.  Or maybe I just don't know enough about the latest
developments in gettext.

Here's how the declaration of an Emacs primitive looks in current Emacs
sources:

   DEFUN ("face-attribute-relative-p", Fface_attribute_relative_p,
          Sface_attribute_relative_p,
          2, 2, 0,
          doc: /* Check whether a face attribute value is relative.
   Specifically, this function returns t if the attribute ATTRIBUTE
   with the value VALUE is relative.

   A relative value is one that doesn't entirely override whatever is
   inherited from another face.  For most possible attributes,
   the only relative value that users see is `unspecified'.
   However, for :height, floating point values are also relative.  */)
        (attribute, value)
        Lisp_Object attribute, value;
   {

As you see, the doc string is just a C comment; after preprocessing,
it is completely gone.  The make-docfile command gathers these
comments and puts them into etc/DOC, but there's no trace of them in
the binary, as you point out.

I would imagine that we can tweak make-docfile to generate a POT file,
as Andreas suggests, but the other part of gettext is to call some
function to replace the original string with its translation, when
that string needs to be presented to the user.  How does one do that,
if the original string is not there to begin with?

What am I missing here?




reply via email to

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