Re: Summary (Re: A system for localizing documentation strings)

[Jean-Christophe Helary]

On 27 juil. 07, at 17:03, Jan Djärv wrote:

> Jean-Christophe Helary skrev:
> > I will try here to make a short summary of the discussions.
> >
> > I'll start with quoting myself (with a modification in the 3rd
> > requirement):
> >
> > > What we need is provide:
> > > 1) a way for coders to identify the necessary strings for the  
> > > translation
>
> Yes, we need something in elisp that identifies strings to be  
> translated.  For
> C gettext mostly uses the macro _(...).  But it is something that  
> gettext must
> be able to recognize, and somethin coders easy can add to strings  
> that shall
> be translated.

gettext has nothing to do with emacs. emacs code, as elisp, is data  
and must be considered as such by specific elisp functions created  
for localization.

There is absolutely no point in using a non lisp way to extend emacs  
(because we are talking about extending emacs here so that any elisp  
system can be localized within emacs).

> > > 2) a way for translators to add translated strings "the emacs way"
>
> We don't need that.  Translators are organized in teams, and  
> everything uses
> gettext.  We do not want a different mechanism here.  Many translators
> translates programs they very rarely, if ever, use.  It would be a  
> mistake to
> not use gettext.

Of course we need that. We are trying to extend emacs so that it  
provides a localization framework for elisp systems.

I'd say that it would be much more straightforward to use an elisp  
system to do that than to externalize the tasks to gettext.

Besides, translator teams use different tools for different tasks and  
there are plenty of software that does not use gettext because  
translating PO files is a pain in the butt: none of the tools at hand  
offer modern mechanisms to efficiently leverage translation compendia  
dynamically.

> > > 3) a way for users to have the localized strings displayed
>
> Gettext does that already.  I guess we have to modify print or some  
> low level
> C function in Emacs to use gettext.

And there are ways to do that from within emacs with elisp. Why  
externalize things when we have an extendable framework that is  
yearning to be extended ?

> > We have also identified another requirement:
> >
> > 4) a way for other coders to read the code without having unrelated
> > documentation strings coming in the way
>
> Translations does not belong in the code, that is why this  
> requirement is
> automatically satisfied if gettext is used.
>
> We need a way to identify elisp strings to be translated, maybe  
> gettext must
> be modified to do this.  We also need to find where in Emacs  
> gettext shall be
> called.  And that is it, but probably hard work nonetheless.

What are the odds that such tasks would be easier to handle in elisp ?


Jean-Christophe Helary