Re: A system for localizing documentation strings

[Jean-Christophe Helary]

On 27 juil. 07, at 00:10, Eli Zaretskii wrote:

> It's not that simple, because in practice many .el files that come
> with Emacs are maintained by people who also offer the last version
> from some Web site.  So in practice, I think we do need to have the
> translations on separate files even for bundled packages.  And since
> you agree that this should be supported anyway, for the benefit of
> unbundled packages, there's no reason not to use this infrastructure
> for bundled ones as well.  There are only advantages to this, I don't
> see any disadvantages.

The fact that the code (.el) will only contain the English string  
defeats one of the purposes of the localization.

If I read code and I need to check a separate file all the time to  
see what the French says then I loose a huge amount of time.

I think (but I may be wrong) that you consider anything that is not  
English as "translations" and English as a gold standard.

It is important to _not_ think that way to be able to offer the most  
flexible framework possible.

The "literate programming" style that elisp/emacs has adopted  
_requires_ to be language agnostic as much as possible.

> > > Why do we need the source language?
> >
> > Because as soon as we have a system that allows for localization we
> > can expect to have "native" code written and so we'll have to
> > reference the source language that _will_ be different from English.
> > We don't want people who don't master English to produce weird
> > English in their descriptions because the system implies
> > source=English.
>
> I don't see a problem.  Programmers who don't master English can
> supply the documentation in their native language, and someone else
> will provide the English equivalent to be installed in the .el file
> before it is installed; after, all most maintainers who have write
> access to the repository have good command of English.  The original
> (non-English) documentation gets installed as one of the translated
> messages.

Here again, you see the process as an English based process.

If we are to provide a localization+translation framework we need to  
identify all the languages (including English and its different  
dialects if necessary, that is ISO 639) to provide the most  
flexibility possible. In fact, the biggest mistake of gettext and  
similar l10n processes was to imply that English was to be the gold  
standard of documentation from which everything should be translated.  
Massive l10n activities around the free world have proved that this  
paradigm was overly limiting and recent developments of gettext seem  
to include the possibility to have other languages in source.

The fact that the "main" emacs is centered on English _currently_  
does not say anything about the state of the code in 10 years from now.

> > > Also, we should keep in mind that Lisp primitives (those
> > > implemented in
> > > C) have their doc strings as C comments, not as C strings.  The
> > > infrastructure developed for Emacs l10n should provide solution for
> > > the primitives as well, and the solution will have to be different
> > > both from your suggestion above and from the traditional gettext- 
> > > style
> > > message catalog.
> >
> > Could that part be concieved separatly ?
>
> It will be a separate solution, but it needs to be designed and
> implemented together with the one for *.el files, since it doesn't
> make sense to have a localized Emacs where all the primitives are
> still documented only in English.

I see. Thank you for your comments.


Jean-Christophe Helary