Re: A system for localizing documentation strings

[Jean-Christophe Helary]

On 27 juil. 07, at 09:30, Kenichi Handa wrote:

> In article <address@hidden>,  
> Jean-Christophe Helary <address@hidden> writes:
>
> > On 26 juil. 07, at 20:54, Kenichi Handa wrote:
>
> > > > To offer a practical possibility for interactive localization we'd
> > >
> > > Could you please explain what is "interactive localization",
> > > and why gettext doesn't work for it.
>
> > gettext delivers an intermediate file (PO etc) that needs to be
> > translated and then put back into the code to reach localization.
>
> > What I mean by "interactive localization" is that the translator
> > could translate, evaluate the function in which the translation
> > occured and the translation would be right there.
>
> Thank you for the explanation.  In the case of translating
> labels, menus, etc, I see some merit in getting translation
> instantly, but, for function/variable docstrings, I don't
> understand why it's that important to get the translation
> instantly by evaluating a funciton.

I don't know the emacs code. So my idea was that pretty much  
everything was a function.

If we manage to have a process that smoothly handles the functions  
that define labels and menus etc then, as a "side effect" the same  
process will smoothly handle the rest.

Also, getting the translation immediately allows for easier delivery:  
the translation can be checked right away in context, modified if  
necessary and the result is better than if the translation has to be  
later re-imported in the code (or wherever) for checks and  
modifications.


Jean-Christophe Helary