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

[Jan Djärv]

Jean-Christophe Helary skrev:
> On 27 juil. 07, at 17:03, Jan Djärv wrote:
>
>
> 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.

Why?  AFAIK, gettext works with other interpreted languages also.

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

Any?  Are there more than one?


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

No, we are trying to localize Emacs.  Or that is what I am talking about.


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

Elisp is only part of Emacs.  C code must also be handeled.

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

There are many tools out there, I haven't checked them all.  But I know some 
use translation dictionaries.  AFAIK, GNU uses gettext only for localization.

> > > > 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 ?

Why reinvent the wheel when there is a localization framework in use already?
There are not ways to this transparently from elisp.  C code also print out 
lisp expressions.

> > > 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 ?

Zero as make-docfile already can do much of the work.

        Jan D.