Re: Emacs i18n

[Juri Linkov <juri@linkov.net>]

>> I don't know where to put i18n related code, so since ngettext should
>> have C calls anyway, I moved it to editfns.c near the function ‘message’
>> where it still just returns the correct plurals without doing any translation.
>
> That stub had some problems:
>
> 1. It lacked documentation in the Elisp manual. Important changes like
> this should be documented -- to some extent the documentation is even
> more important than the code. Can you write something?

I'll start writing documentation.  Is it allowed to make
references from the Elisp manual to the Gettext Info manual?
I see in (info "(gettext) elisp-format") a reference back to
the Elisp manual is a web link, not an Info reference.

> 2. While you're thinking about (1) here are some other questions. How
> will ngettext determine the message catalog? Is the catalog visible to
> users as a global variable, or as a hidden part of the global state, or
> is it something explicit? How will catalogs from multiple packages be
> used? How would a multi-lingual application work in Emacs if the message
> catalog is part of global state? This seems to be a crucial issue, I'd
> say. For example, should Emacs export dcngettext to Lisp code, instead
> of just plain ngettext? (Emacs could then define ngettext in terms of
> dcngettext.)

It seems most of these needs could be covered by adding two optional
arguments DOMAIN and CATEGORY to ngettext (where the default domain
"emacs" will be hard-coded).

As a convenience not to require a package to add its domain to every
ngettext call, maybe when something like 'defdomain' is declared at the
beginning of the package, its value should affect the domain within
the package scope.