Re: Emacs i18n

[Paul Eggert <eggert@cs.ucla.edu>]

On 3/7/19 12:22 PM, Eli Zaretskii wrote:
>
> '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.

Yes, of course. And even for 'message', all I searched for was the
string '(message (concat', which is just a fraction of the calls to
'message' that will need to be reworked. That search was not an attempt
to count all the problems we'd run into; it merely was a sample of the
problems. If the sample is representative then each individual problem
should be relatively easy to solve.


> whether we indeed
> want to give up marking translatable strings and instead rely on some
> functions always translating their argument strings.

We could mark each translatable string by hand. But this would make for
more churn to the source code and would be more work. It's hard to see
why that would be a win, compared to the reasonably-common practice of
marking some well-known functions as doing translations automatically.


> 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?

One can easily work around any such restrictions by having a variant of
'message' that does not translate its format argument. We're already
doing this for translation of '`', by having two functions 'format' and
'format-message': the former does not translate '`', the latter does. A
similar approach can work for natural-language translation and 'message'.


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

Of course we should not accept techniques blindly. We should use
techniques with our eyes open, based on experience. That being said,
this discussion suggests that Emacs is not really that much of a special
case aside from its size. If so, there is little need to reinvent the
i18n wheel just for Emacs, and there is a real advantage to reusing
existing GNU technology in this area rather than trying to reinvent it.