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