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

[Jean-Christophe Helary]

On 27 juil. 07, at 18:04, Jan Djärv wrote:

> Jason Rumney skrev:
> > Jan Djärv wrote:
> > > 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.
> >
> > I disagree. It is a mistake to use any system that requires code  
> > to be
> > modified to fit with its conventions before translation can occur. We
> > cannot guarantee that maintainers of external lisp packages will  
> > do the
> > work that is required. Since we already have mechanisms in place that
> > extract doc strings, tooltip text and menu text for display, we  
> > should
> > add the necessary hooks at that point to provide translations  
> > transparently.
>
> We can not guarantee that maintainers of external lisp packages  
> will do
> anything, regardless of what mechanism Emacs use.  But the point is  
> that Emacs
> is unlikely to be translated by the translation teams that are  
> already outh
> there if a completely new mechanism that differs much from gettext  
> is adopted.

This is preposterous. There are plenty of localization teams that  
handle many different processes, source files, translation tools.

Gettext is far from being the only way to localization. And here I  
mean localization as menu items + interface messages + documentation,  
where documentation weights much more than all the other strings  
combined.

Besides, gettext may be good for short sentences (specifically menu  
items and short messages) but documentation translation is a totally  
different process.

Obviously the self-documentation feature that is advertised as one of  
emacs's specificity should be handled in a very emacsy way that fits  
with its paradigm.


Jean-Christophe Helary