[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A system for localizing documentation strings

From: Jean-Christophe Helary
Subject: Re: A system for localizing documentation strings
Date: Fri, 27 Jul 2007 00:42:56 +0900

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

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]