[Top][All Lists]

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

Re: Emacs i18n

From: Eli Zaretskii
Subject: Re: Emacs i18n
Date: Thu, 07 Mar 2019 22:22:29 +0200

> Cc: address@hidden, address@hidden
> From: Paul Eggert <address@hidden>
> Date: Thu, 7 Mar 2019 09:19:35 -0800
> This limitation will cause problems with Elisp code that does extensive
> parsing or processing of English syntax (doctor.el, say), and that sort
> of Elisp code will remain English-only (unless someone takes the time to
> i18nize them specially). However most Elisp code does not parse English
> or generate idiomatic English on the fly: instead, it uses a fixed,
> stilted style that can routinely be converted to calls like (message
> FORMAT ARG1 ARG2 ...) where FORMAT is translated and the ARG values are not.
> To get a quick feel for this issue, I did a simple grep for the string
> '(message (concat' in the Emacs source code. I found 41 instances of
> this string.

But 'message' is just a representative of a class of such functions.
There are others: 'signal', 'error', 'user-error', 'princ', 'format',
and probably some more I'm missing.  So the actual number of
occurrences is larger than the 40 you found.

I guess I'm saying that we should think some more whether we indeed
want to give up marking translatable strings and instead rely on some
functions always translating their argument strings.  Perhaps doing so
will impose restrictions on what a Lisp program can do, and we don't
want to live with such restrictions without some fire escape, in the
form of explicitly translated strings?

In general, I think we should not blindly accept any technique used
for localization, because Emacs is so much different from a typical
console program written in C.

reply via email to

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