|Subject:||Re: Summary (Re: A system for localizing documentation strings)|
|Date:||Thu, 2 Aug 2007 09:32:51 +0900|
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).
|[Prev in Thread]||Current Thread||[Next in Thread]|