Re: Internationalize Emacs's messages (swahili)

[Daniel Brooks]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Zhu Zihao <all_but_last@163.com>
>> Cc: dimech@gmx.com, abrochard@gmx.com, rms@gnu.org, bugs@gnu.support,
>>  emacs-devel@gnu.org
>> Date: Thu, 24 Dec 2020 09:54:04 +0800
>> 
>> > There were serious discussions of this stuff in the past, which
>> > revealed the parts of this (large) job, and in particular that just
>> > having a Lisp binding for gettext is not enough.  We are "ready" in
>> > the sense that someone needs to implement at least some of those
>> > parts.
>> 
>> Can you give me a link to the dicussion?
>
> They are easy enough to find: search the list archives for "gettext"
> or "l10n", and you will find them.  The last one starts here:
>
>   https://lists.gnu.org/archive/html/emacs-devel/2019-03/msg00081.html
>
> A previous one starts here:
>
>   https://lists.gnu.org/archive/html/emacs-devel/2017-04/msg00750.html

My personal opinion is that gettext is too limited. It works for simple
things, but provides no help at all for complex things.

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

Thus, each translation should provide a package full of functions rather
than a file full of strings. It could literally be that simple, though I
think that there are benefits to not making translators actually write
an elisp package. For one thing, putting the wrong kind of function in a
translation package could actually break Emacs (because there's no
namespacing). I think that we could compile these functions from a
different source representation, and that we could benefit from sharing
code and tools with an existing translation project.

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

The Project Fluent webpage has an set of interactive examples which are
worth checking out.

I'd be willing to spend some free time to help implement this.

db48x