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

[Jean-Christophe Helary <fusion@mx6.tiki.ne.jp>]

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