From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Internationalize Emacs's messages (swahili) Date: Sat, 26 Dec 2020 09:50:35 +0200 Message-ID: <83sg7tm2es.fsf@gnu.org> References: <87o8ivumn5.fsf@telefonica.net> <87v9d3nkxk.fsf@gnus.org> <83sg7xrgr5.fsf@gnu.org> <83h7odrdwy.fsf@gnu.org> <86sg7w39fh.fsf@163.com> <83pn30pku5.fsf@gnu.org> <86wnx8otoj.fsf@163.com> <834kkbp9vr.fsf@gnu.org> <87czyxuxw6.fsf@db48x.net> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3742"; mail-complaints-to="usenet@ciao.gmane.io" Cc: all_but_last@163.com, bugs@gnu.support, dimech@gmx.com, abrochard@gmx.com, emacs-devel@gnu.org, rms@gnu.org To: Daniel Brooks Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Dec 26 08:51:52 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kt4Mi-0000rf-2C for ged-emacs-devel@m.gmane-mx.org; Sat, 26 Dec 2020 08:51:52 +0100 Original-Received: from localhost ([::1]:50786 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kt4Mg-00079J-Uv for ged-emacs-devel@m.gmane-mx.org; Sat, 26 Dec 2020 02:51:50 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58432) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kt4M6-0006ih-TI for emacs-devel@gnu.org; Sat, 26 Dec 2020 02:51:14 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:55535) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kt4M3-0000Tl-0q; Sat, 26 Dec 2020 02:51:11 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4799 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kt4Lk-00023O-KR; Sat, 26 Dec 2020 02:50:53 -0500 In-Reply-To: <87czyxuxw6.fsf@db48x.net> (message from Daniel Brooks on Fri, 25 Dec 2020 18:03:21 -0800) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:261790 Archived-At: > From: Daniel Brooks > Cc: Zhu Zihao , 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 > .) 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 > . 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).