>> [: Juri Linkov :]
>> Indeed, a complete implementation of all Russian morphological rules
>> takes ~1600 lines of dense Perl code:
>>
>> http://www.linkov.net/files/nlp/Lingua-RU-Inflect.pm
>>
>> I can't imagine how to include all these rules to gettext.
>
> [: Richard Stallman :]
> I agree with you about that. What I propose is something else.
>
> 1. I do not propose implementing them all. Only some -- whichever ones
> we think are worth while.
>
> 2. I do not propose putting any of this in gettext. What I propose
> would be Emacs code that operates on the strings that come from
> gettext.

I'd like to mention that a system of this kind, the Ki18n, is in
operation within the KDE ecosystem for more than a decade now. The
system is in fact invisible to programmers (for the most part), and it
is also invisible for translators, unless they know about it and want to
use it. At the last count, 10 language teams do make use of it.
Translators have at their disposal a generic scripting system, so that
any kind of algorithmic adaptation of translation is possible; and some
interesting uses have come up.

Programmer's perspective is given here:
http://api.kde.org/frameworks/ki18n/html/prg_guide.html . There is in
fact almost no mention of the system, which is as intended; only the
subsections "Dynamic Contexts" and "Placing and Installing Scripting
Modules" provide a clue that it exists.

Translator's perspective is given here:
http://techbase.kde.org/Localization/Concepts/Transcript . It includes
some real-life example at the end. The variety of basic functions
defined by translators can be seen in the system's source tarball
http://download.kde.org/stable/frameworks/5.56/ki18n-5.56.0.tar.xz in
po/*/scripts directories.

Regarding specifically plural handling, this is in normal use left to
Gettext standard functionality, since it was already there for a long
time. However, there are two cases where the system does get used for
plurals. One is the typical failure case where a programmer knows that
the substituted number will always be greater than and therefore thinks
a ngettext call is not needed; when this error is seen during a pre-
release message freeze, a scripted translation can be used to work
around until fix for next release. The other case is when a language
needs also plural handling for float-type arguments (e.g. gd in the
tarball above).

Each programming environment (programming language plus foundation
libraries) can implement its own version of a similar system, as
proposed here for Emacs. However, I think a unified Gettext solution
would be preferable. Based on the experience with Ki18n, some years ago
I made such a clean design for Gettext, but never got time to work on
it. It is described at http://nedohodnik.net/gettextbis/ . Section 6
describes the scripting system itself, with sections 2 and 3 detailing
the necessary support for it.

-- 
Chusslove Illich (Часлав Илић)