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

[Andreas Schwab <schwab@suse.de>]

Jean-Christophe Helary <fusion@mx6.tiki.ne.jp> writes:

> On 28 juil. 07, at 00:07, Jan Djärv wrote:
>
>> Jean-Christophe Helary skrev:
>>> On 27 juil. 07, at 17:03, Jan Djärv wrote:
>>> 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.
>>
>> Why?  AFAIK, gettext works with other interpreted languages also.
>
> This is besides the point.
>
> gettext offer tools to extract the strings, deliver PO(T) files, merge the
> strings, compile the PO

This is the development part.

> and then the result has to be built  against a
> l10n library to handle the MO live.

This is the runtime part.  You should distinguish these two functions
because they can be handled separately.  Even if the latter part (the
runtime) is handled by the gettext library, there is no requirement that
the first part is done using the tools provided by the gettext bundle.

> Emacs is a highly specialized device that handles strings. Why bother
> externalize the processes when they could be handled in a cleaner way
> from within emacs, in a few elisp functions, including translation of
> course.

The use of the gettext runtime is no externalization of processes.
Emacs would just link against libintl (or use the functions in glibc)
and provide a lisp binding.  This just as lispy as anything Emacs
provides.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."