|
From: | Jean-Christophe Helary |
Subject: | Re: A system for localizing documentation strings |
Date: | Sat, 28 Jul 2007 12:13:18 +0900 |
On 28 juil. 07, at 01:09, Jason Rumney wrote:
Jan Djärv wrote:End users don't care. As a translator, I do care. There are existing translations in gettext format I'd like to reuse if I was to translateEmacs. Not sure I can take on such a huge job though :-)The .PO file format - This is what I think you mean when you say thattranslators do care. We can support this independently of whether we usegettext or not.
PO files are made necessary because the applications that are localized are not specialized in string export/edition/import. The target files in our emacsy process could be generated by emacs transparently as the translation occurs. and they could be evaluated immediately so that the translator sees the context and corrects accordingly.
One of the main issue with localization is that intermediate files like PO or XLIFF do not contain enough contextual information. So once the (sometimes faulty) translation is loaded it take a lot of efforts to correct it. With a localization process within emacs, the localized elisp files could be evaluated right away and corrected on the spot. That would contribute to greatly improving the quality of the translations.
All the non elisp parts of the code should be handled with the proper gettext processes. But such parts seem to evolve at a much lower pace than the elisp extension parts and would certainly require less efforts for localizing them
Jean-Christophe Helary
[Prev in Thread] | Current Thread | [Next in Thread] |