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

[Jean-Christophe Helary]

> > If automatic display based on locale information is difficult, do  
> > you think a command that simply overwrites the documentation with  
> > an available translation would be easier to implement ? Instead of  
> > overwriting the strings (which may not be a practical solution),  
> > the command would simply re-generate the code file from the  
> > translation database stored strings.
> > In the end, the user would have a choice between the default  
> > English and any translation available, and even once "overwritten"  
> > the files could be reverted to their original English state.
> > What matters is that the coder has easy access to the translation  
> > database in a way or another _during_ the coding process without  
> > having to refer to a separate file.
>
> I'm not sure how this would work.  Say I have the swedish locale.   
> If I edit an english doc string, how does Emacs know if I'm  
> translating it to swedish or correcting the english one?

Considering the discussions that far, translating a file would be  
done either externally or in a special translation mode.

As long as you are working on the file is this new "language aware"  
lisp major mode, whatever you do there is editing and not translating.

Will this editing affect the translation database ? It should not. As  
far as emacs is concerned, if you overwrite the original file with  
your modifications then the available translated strings are still  
here and the modified ones won't match anything in the DB. If you  
save your file under a new name it loses the connection to the l10n  
database (unless the db is a global one that is made to apply to any  
string but that is a different story).


Jean-Christophe Helary