Re: A system for localizing documentation strings

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

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

> In article <520B1EA6-0FF5-43E1-BB6D-6AD97A2EFE22@mx6.tiki.ne.jp>,  
> Jean-Christophe Helary <fusion@mx6.tiki.ne.jp> 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