Re: Internationalize Emacs's messages (swahili)

[Eli Zaretskii]

> From: Daniel Brooks <db48x@db48x.net>
> Cc: Zhu Zihao <all_but_last@163.com>,  dimech@gmx.com,  abrochard@gmx.com,
>   rms@gnu.org,  bugs@gnu.support,  emacs-devel@gnu.org
> Date: Fri, 25 Dec 2020 18:03:21 -0800
> 
> My personal opinion is that gettext is too limited. It works for simple
> things, but provides no help at all for complex things.

That is in no way specific to Emacs, is it?

> I think that the most productive way to think about translation is that
> each coherent message that we present to a user (whether it's via the
> message function or not) should explicitly be the result of calling a
> function written by the translator. gettext only allows the translator
> to supply strings, so it falls down in complex situations.

The advantage of the translation infrastructure based on gettext is
that the translators don't have to be programmers, they only need to
be experts in correct use of technical terminology in their
languages.  Even with that significant advantage, it is hard to find
translators for many languages.  Your suggestion would make that job
much harder, with the net result that more messages for more programs
will remain untranslated: a classic example where the best is a sworn
enemy of the good.

(Disclosure: I'm the team leader for translators to the Hebrew
language, as part of the GNU Translation Project.  I'm talking from
personal experience here.)

> The classical example is the "You have 42 new messages." situation. With
> gettext, it is tempting to ask the translator to translate a string such
> as "You have %d new messages.", but this does not give them any
> flexibility to correctly handle languages with more plural categories
> than English. Russian, for example, has a plural category for all
> numbers that are one more than a multiple of ten except 11, which is a
> special case. It also has another category for all numbers ending in 2,
> 3, or 4 except for 12, 13, and 14. (I don't actually know Russian, but
> the rules are summarized in a page or two at
> <http://www.russianlessons.net/lessons/lesson11_main.php>.) There are
> over 7,700 distinct languages in the world, and we should assume that
> they are all at least that crazy. An ideal situation does not allow the
> craziness to leave the translation and make the implementation more
> complex. Nor should the craziness of Russian make writing a Spanish
> translation more difficult.

This problem was solved in gettext long ago, and is being widely used
in existing translations.  See the node "Plural Forms" in the GNU
gettext manual.  Emacs has the ngettext function in preparation for
the day when we will be able to have translatable message strings.

> I recommend taking a look at Project Fluent
> <https://www.projectfluent.org/>. It's a free-software implementation of
> exactly the system that I've described. Translators write functions in a
> syntax that is similar in some ways to both Javascript and an ini file,
> which could be easily compiled into Elisp. (It's the successor to the
> l20n project, which you might also have heard of.)

How many translated languages for how many programs does this project
have?

Anyway, the hard problems in translating some of the Emacs UI are
elsewhere, as can be seen from the discussions to which I pointed.  We
need to solve those first, and only after that worry about the issues
you mention (if they are real).