Re: A system for localizing documentation strings

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

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  
>> translate
>> Emacs.  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 that
> translators do care. We can support this independently of whether  
> we use
> gettext 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