From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Brooks Newsgroups: gmane.emacs.devel Subject: Re: Internationalize Emacs's messages (swahili) Date: Fri, 25 Dec 2020 18:03:21 -0800 Message-ID: <87czyxuxw6.fsf@db48x.net> 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26233"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) Cc: Zhu Zihao , bugs@gnu.support, dimech@gmx.com, abrochard@gmx.com, emacs-devel@gnu.org, rms@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Dec 26 03:04:29 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 1ksywX-0006hF-0a for ged-emacs-devel@m.gmane-mx.org; Sat, 26 Dec 2020 03:04:29 +0100 Original-Received: from localhost ([::1]:33080 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ksywV-00082C-Vz for ged-emacs-devel@m.gmane-mx.org; Fri, 25 Dec 2020 21:04:28 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51702) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ksyvd-0007X1-RB for emacs-devel@gnu.org; Fri, 25 Dec 2020 21:03:33 -0500 Original-Received: from smtp-out-4.mxes.net ([2605:d100:2f:10::315]:43710) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ksyvb-0002UJ-S7 for emacs-devel@gnu.org; Fri, 25 Dec 2020 21:03:33 -0500 Original-Received: from Customer-MUA (mua.mxes.net [10.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id ABEDE759BF; Fri, 25 Dec 2020 21:03:22 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mxes.net; s=mta; t=1608948205; bh=Fk7zEeU/qeDIsXYEQqz3E1nxVa8UEFn27xPTyHOrIZc=; h=From:To:Subject:References:Date:In-Reply-To:Message-ID: MIME-Version:Content-Type; b=0/4KTjYnbw3LWrKX5CjfVhJpb7ngosrUnI7tSsVWsdhA3R9bd7tojpruP1HIT8+pH iApUyUO25SvbOW9028T8ILUHjPNGVzwMy86ZVBktwn0Oe8n5m1B+o9x0y2AKXN2IZu u98Vj7ki7iAM2qm90mMI9UhGwYKJeRVrdEAR7Tfo= Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGOfPtRkwAAABJQ TFRFpKfbdou67PD6JjJgAwUWXGSeIcyLHgAAAkZJREFUOI1VU8Fy6yAMxLi+Q13fCZ3cnQL3dqTc 7RD+/1feStDXVnXHDuvVSivZTMba2GPdw3gyCGcMAFxTyrTd9dwGoxHiZX9PmRFUHYAQlGGtXY+F Uk0SJOxgJiUEnH1qkitT9D+pQub7qGAmUbR6bu3CvI96Yv6QqkBBMrsyfZccr1/RDXGDTLf4P7ZY glVxe2V+/ACXWO1gvDO9/gDRpFFVmPluvLcmBjd5H6d8DEte+Pbk4rcY/Fa5tLKLOtCZsuQKYhpa LOkYDT7hESya7/WIET3lfQBqX0pwFtbI832Is0ayMUR9B+12xjgPCQ089cfwkCkX6L5TPmRelJTh zMS0Sz1PyjLAMCUWjcmgQLWQMds+e3aaauZDf9dU9A2/8kPVF2odCUoMKHkfjJR+mbgC+DRiycw5 3XSqGe6HmhN/AWjHypkAXOAFW5EiuA1ge2GiZuMb0s1fSEXcATeLUfbyEY2L8yPOmdSsdghQXx3K pz2eoeXuYvMCINVFDrCdNfVUp4eJ6cSEbjbgFjBEvonGGTrgv9cHjAc8aVgSAPoxaONbzfwhDIhR at7IIS7fAGiDSwIA9alhhTBzfA7YM2FY6eMwayrIGK8FDFmshmUA43WqhFtpvoqG9HHaJ7fqtgTz 8EWVkgZgtsylFliHDgk0MB7KAEC45C/rgnGvanNLXyzOeTzcT2nw/N44gfrtYXRQLoz9Q3TgmJRx 2Mx/Q51qzpm+l3m8z2SWBqC5+PZXAtNYlGFf/gKfHfjFkDT4x7od7R+w3Ls+ZdQBuQAAAABJRU5E rkJggg== In-Reply-To: <834kkbp9vr.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 24 Dec 2020 16:16:24 +0200") X-Sent-To: Received-SPF: none client-ip=2605:d100:2f:10::315; envelope-from=db48x@db48x.net; helo=smtp-out-4.mxes.net X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_PASS=-0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:261781 Archived-At: Eli Zaretskii writes: >> From: Zhu Zihao >> 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 .) 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 . 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