Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qlq3F-004Za6-3I for pgsql-translators@arkaria.postgresql.org; Thu, 28 Sep 2023 12:23:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1qlq3C-00Ci1z-OC for pgsql-translators@arkaria.postgresql.org; Thu, 28 Sep 2023 12:23:26 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qlq3C-00Ci1l-H9 for pgsql-translators@lists.postgresql.org; Thu, 28 Sep 2023 12:23:26 +0000 Received: from smtp.outgoing.loopia.se ([93.188.3.37]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qlq39-0085pf-JE for pgsql-translators@lists.postgresql.org; Thu, 28 Sep 2023 12:23:25 +0000 Received: from s807.loopia.se (localhost [127.0.0.1]) by s807.loopia.se (Postfix) with ESMTP id 085B42FB13AA for ; Thu, 28 Sep 2023 14:23:23 +0200 (CEST) Received: from s980.loopia.se (unknown [172.22.191.6]) by s807.loopia.se (Postfix) with ESMTP id EC0152E295F1; Thu, 28 Sep 2023 14:23:22 +0200 (CEST) Received: from s470.loopia.se (unknown [172.22.191.5]) by s980.loopia.se (Postfix) with ESMTP id E9F712201556; Thu, 28 Sep 2023 14:23:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at amavis.loopia.se X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=6.2 tests=[ALL_TRUSTED=-1] autolearn=disabled Received: from s980.loopia.se ([172.22.191.5]) by s470.loopia.se (s470.loopia.se [172.22.190.34]) (amavisd-new, port 10024) with UTF8LMTP id hLAL9YvnIEav; Thu, 28 Sep 2023 14:23:21 +0200 (CEST) X-Loopia-Auth: user X-Loopia-User: daniel@yesql.se X-Loopia-Originating-IP: 89.255.232.193 Received: from smtpclient.apple (customer-89-255-232-193.stosn.net [89.255.232.193]) (Authenticated sender: daniel@yesql.se) by s980.loopia.se (Postfix) with ESMTPSA id 9A0BA220169C; Thu, 28 Sep 2023 14:23:21 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.3\)) Subject: Re: Is translating server messages really worth it? From: Daniel Gustafsson In-Reply-To: <2a439909-017c-6241-e4f6-a78dc1b373af@eisentraut.org> Date: Thu, 28 Sep 2023 14:23:21 +0200 Cc: Peter Geoghegan , Guillaume Lelarge , pgsql-translators@lists.postgresql.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <2a439909-017c-6241-e4f6-a78dc1b373af@eisentraut.org> To: Peter Eisentraut X-Mailer: Apple Mail (2.3696.120.41.1.3) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > On 27 Sep 2023, at 17:28, Peter Eisentraut = wrote: > One specific example of a thing I would like to avoid is that the = --help output has a wild mix of translated and untranslated lines. We clearly want to avoid that. > Of course, this could be avoided by having the whole --help output as = one translation catalog entry, which is exactly what we have not been = doing, because that makes it harder to update between versions. Could we group messages that have all-or-nothing translations required, = like --help output, with separate msgctxt contexts? So "pg_dump --help" = would be "msgctxt pg_dump_help_screen" in the po file, which then could be = analyzed in order to make the call for including translationfiles or not? -- Daniel Gustafsson