Re: Emacs i18n

[Eli Zaretskii <eliz@gnu.org>]

> Cc: emacs-devel@gnu.org, juri@linkov.net
> From: Paul Eggert <eggert@cs.ucla.edu>
> 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.