Re: Emacs i18n

[Eli Zaretskii <eliz@gnu.org>]

> Cc: rms@gnu.org, emacs-devel@gnu.org, juri@linkov.net
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Thu, 7 Mar 2019 14:25:30 -0800
> 
> > 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.

No, I didn't mean "each", I meant just some, hopefully a small
minority.  Because most of the use cases are probably easy enough to
change so that strings could be collected by a tool, and 'message' and
its ilk could then translate them automatically.  Having an explicit
translation function would then be that "fire escape" for when
converting code not to compute strings would be too painful.

> > 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 could, but I don't see how that would help.  If a string is not
found in the catalog(s), it will be output untranslated anyway, so why
do we need a separate function?

> this discussion suggests that Emacs is not really that much of a special
> case aside from its size.

I'm not sure I agree.  I think the fact that Emacs is written mostly
in Lisp and not in a procedural compiled language will make another
qualitative difference.

> there is a real advantage to reusing existing GNU technology in this
> area rather than trying to reinvent it.

Where it fits, sure.  Especially we should strive hard to use the PO
files for catalogs, because that affects the translation teams.