From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id EAUiHrQ2419eLwAA0tVLHw (envelope-from ) for ; Wed, 23 Dec 2020 12:23:16 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id KOb/GbQ24184fAAAbx9fmQ (envelope-from ) for ; Wed, 23 Dec 2020 12:23:16 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 83BA39404D5 for ; Wed, 23 Dec 2020 12:23:15 +0000 (UTC) Received: from localhost ([::1]:60808 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ks3Ag-00046G-DP for larch@yhetil.org; Wed, 23 Dec 2020 07:23:14 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:41342) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ks3AU-000464-Gr for guix-devel@gnu.org; Wed, 23 Dec 2020 07:23:04 -0500 Received: from mail-wm1-x32a.google.com ([2a00:1450:4864:20::32a]:40873) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ks3AS-0001Cr-3V; Wed, 23 Dec 2020 07:23:02 -0500 Received: by mail-wm1-x32a.google.com with SMTP id r4so5972883wmh.5; Wed, 23 Dec 2020 04:22:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=hflpMEScAaB+naAwqvJRA1FT+KFtiP4yW+mtiJmcN3A=; b=mpL32W5K1byE19eaQ3+kgsNZK7PE8paLnE0+8DTei8vWdjSAb2KmehkFfUIkaddeBY E6L2UIM4WXKQjXhMJhslP4fYUI/9b9YbeApSCwhUUey3cvAK0c55WKHbZMaE5xz6P8pn z0WfBh9EFy1zBZuPeIF2aAUCI8qIAxczBTXGKu0ODZlLCT3411wCWoq84HEfDJRqYV1A jWOTgmCDzYmuer6Dshe0tGkT48x5AkOwVzvo6ctcHrBn9Vg+/ZWsNguKs03Ieiqa2Esm pFsCBQr0G7GPc2YCBAO7OjCrsC0LJ4edvRrvZpX52mUc3B+O06ciBq9aia0f8vCHbTbo N+OQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=hflpMEScAaB+naAwqvJRA1FT+KFtiP4yW+mtiJmcN3A=; b=pe6hMEaTfVERLnLOSGUXp9/me5xFzA0HZyrUTZSsAPmytIU7Ui0o49sdJC2LBIhgEB fGkQ77Rk+hm4L7E7ObThkQff7y5yCvp2sPDOmExLvwySDOaOoESi4HZa9ZGzmGQ+wezT AVEebnPS+wkf961YsxRHJTdT6Ymq9HbTeJmOxsk/H3n9Hi35Nn5d6ATbI0ADwe0rLjlV w0X9QiEpIM0j3ET5pJhv+cgQoj6S9/dimLpyIQkg+/7a+Sc0IlJzPll4V3TGaTeQaqGj XPPRWGrip6y1I0+LQbQXMCpAkMyk2goYy7wR+RtzZphFcNJlqSGvDuMr1g9q9nPTjBYb YTAA== X-Gm-Message-State: AOAM5336PV6fjDY+OD4t9g5BleuQDQvOnjKhki0QU+PjepUvaR0NbcFh M0BDN5a0k6ioySfJaMTBM10= X-Google-Smtp-Source: ABdhPJz87Fv6O/Y7BuzPAROlm5ecltFp41e333Gwgagk8ugvyKvW+eleeBAiMWv4xlaMzhL8Ll2Reg== X-Received: by 2002:a1c:6a10:: with SMTP id f16mr26326859wmc.106.1608726178014; Wed, 23 Dec 2020 04:22:58 -0800 (PST) Received: from unfall (36.193.158.146.dynamic.jazztel.es. [146.158.193.36]) by smtp.gmail.com with ESMTPSA id y6sm30247490wmg.39.2020.12.23.04.22.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Dec 2020 04:22:56 -0800 (PST) From: =?utf-8?Q?Miguel_=C3=81ngel_Arruga_Vivas?= To: Julien Lepiller Subject: Re: Word order in Guix l10n References: <86mtyf49x7.fsf@163.com> <87ft43b1g6.fsf@gnu.org> <878s9vf0vc.fsf@systemreboot.net> <871rfh28do.fsf@gnu.org> Date: Wed, 23 Dec 2020 13:22:53 +0100 In-Reply-To: (Julien Lepiller's message of "Tue, 22 Dec 2020 10:06:29 -0500") Message-ID: <87czz0yan6.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Received-SPF: pass client-ip=2a00:1450:4864:20::32a; envelope-from=rosen644835@gmail.com; helo=mail-wm1-x32a.google.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: guix-devel@gnu.org, Zhu Zihao Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -1.23 Authentication-Results: aspmx1.migadu.com; dkim=fail (headers rsa verify failed) header.d=gmail.com header.s=20161025 header.b=mpL32W5K; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Queue-Id: 83BA39404D5 X-Spam-Score: -1.23 X-Migadu-Scanner: scn1.migadu.com X-TUID: Sy4ltj39/6qs --=-=-= Content-Type: text/plain Hi Julien, Julien Lepiller writes: > This specific syntax looks ok, but we need to limit ourself to the > common syntax between guile and lisp, because that's what gettext > supports. The issue with Guile's format is explained here[1], as the used implementation follows SRFI-28[2], but there are no difference between the format from Common Lisp and the one from (ice-9 format)[3] on the surface level: both implementations are compatible regarding numeric, iteration, selection and jump directives, to name a few. Other directives might be compatible, such as the plural directive ~P, or not, although most of them shouldn't be used in any case: not because they could have compatibility problems but because they don't fit into internationalized messages correctly. For example, most languages have irregular cases for plural formation, some have more than two grammatical numeric cases, such as singular/dual/plural, and some don't have an equivalent category, such as Japanese. That's exactly use case of ngettext---I've pointed out on the other mail the pending issue on that area, which is related to the omission of the numeric parameter but not its order, and applies both to Common Lisp and (ice-9 format). > We should use this kind of syntax everywhere we have more than one > argument. I don't see the advantage of using everywhere jumps on the msgids. Nonetheless, a TRANSLATORS: comment placed on the first string appearing on the POT file, pointing the section of the manual for (ice-9 format), or even an explicit and detailed explanation of this syntax could be very helpful for translators. The attached patch does this, although any suggestion or even a complete rewrite is welcome, because I don't feel it quite inspired. > Also thinking about rtl languages, it's probably important > for them, though I'm not sure how gettext works for them. gettext-family functions only see byte arrays and provide the corresponding array, the bytes are always placed in increasing memory locations. Right-to-left handling is a responsibility of visualization layer, which sometimes includes the final format, but that is an issue even with left-to-right languages as French. For example, this composition... (string-append translated ": " other-translated) ... produces weird results, or convoluted French translations, because it isn't handled properly. A format string must be used here too, because it must include the white-space expected in French before the colon: (format #f (_ "~a: ~a") translated other-translated) Newlines are the only ones that are omitted sometimes from the internationalized composition because the convention up-to-down is followed, but this is a limitation of the teletype/terminal interface though; graphic interfaces aren't composed with this limitation and "whole widgets" should be the localization frame, which usually is the case. Happy hacking! Miguel [1] https://www.gnu.org/software/guile/manual/html_node/Simple-Output.html [2] https://www.gnu.org/software/guile/manual/html_node/SRFI_002d28.html [3] https://www.gnu.org/software/guile/manual/html_node/Formatted-Output.html --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-nls-Add-comment-about-format-directives.patch Content-Description: comment.patch >From 2615934a2c377858dce2a0410982287faed754a9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Miguel=20=C3=81ngel=20Arruga=20Vivas?= Date: Wed, 23 Dec 2020 13:07:38 +0100 Subject: [PATCH] nls: Add comment about format directives. * gnu.scm (%try-use-modules): Add comment for translations. It should be placed on the first string found by xgettext. --- gnu.scm | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/gnu.scm b/gnu.scm index f139531ef3..0e87b10eb2 100644 --- a/gnu.scm +++ b/gnu.scm @@ -78,6 +78,19 @@ (raise (apply make-compound-condition + ;; TRANSLATORS: The scheme-format tag is used to identify + ;; strings that contain format directives as specified + ;; here: + ;; https://www.gnu.org/software/guile/manual/html_node/Formatted-Output.html + ;; + ;; The goto/jump directive can be used to alter the order + ;; of the arguments, either performing relative jumps with + ;; ~N* and ~N:* (forward and backwards respectively) or + ;; the absolute position of the argument can be used + ;; (starting from 0) with ~N@*. When N isn't provided, + ;; it's understood to be 1 on the relative jumps (next and + ;; previous argument respectively) and 0 on the absolute + ;; jumps (first argument). (formatted-message (G_ "module ~a not found") module) (condition -- 2.29.2 --=-=-=--