[Top][All Lists]

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

Re: Summary (Re: A system for localizing documentation strings)

From: Jean-Christophe Helary
Subject: Re: Summary (Re: A system for localizing documentation strings)
Date: Fri, 27 Jul 2007 20:15:16 +0900

On 27 juil. 07, at 17:03, Jan Djärv wrote:

Jean-Christophe Helary skrev:
I will try here to make a short summary of the discussions.

I'll start with quoting myself (with a modification in the 3rd

What we need is provide:
1) a way for coders to identify the necessary strings for the translation

Yes, we need something in elisp that identifies strings to be translated. For C gettext mostly uses the macro _(...). But it is something that gettext must be able to recognize, and somethin coders easy can add to strings that shall
be translated.

gettext has nothing to do with emacs. emacs code, as elisp, is data and must be considered as such by specific elisp functions created for localization.

There is absolutely no point in using a non lisp way to extend emacs (because we are talking about extending emacs here so that any elisp system can be localized within emacs).

2) a way for translators to add translated strings "the emacs way"

We don't need that. Translators are organized in teams, and everything uses
gettext.  We do not want a different mechanism here.  Many translators
translates programs they very rarely, if ever, use. It would be a mistake to
not use gettext.

Of course we need that. We are trying to extend emacs so that it provides a localization framework for elisp systems.

I'd say that it would be much more straightforward to use an elisp system to do that than to externalize the tasks to gettext.

Besides, translator teams use different tools for different tasks and there are plenty of software that does not use gettext because translating PO files is a pain in the butt: none of the tools at hand offer modern mechanisms to efficiently leverage translation compendia dynamically.

3) a way for users to have the localized strings displayed

Gettext does that already. I guess we have to modify print or some low level
C function in Emacs to use gettext.

And there are ways to do that from within emacs with elisp. Why externalize things when we have an extendable framework that is yearning to be extended ?

We have also identified another requirement:

4) a way for other coders to read the code without having unrelated
documentation strings coming in the way

Translations does not belong in the code, that is why this requirement is
automatically satisfied if gettext is used.

We need a way to identify elisp strings to be translated, maybe gettext must be modified to do this. We also need to find where in Emacs gettext shall be
called.  And that is it, but probably hard work nonetheless.

What are the odds that such tasks would be easier to handle in elisp ?

Jean-Christophe Helary

reply via email to

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