Hi Julien,
Julien Lepiller <jul...@lepiller.eu> 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
>From 2615934a2c377858dce2a0410982287faed754a9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Miguel=20=C3=81ngel=20Arruga=20Vivas?=
<rosen644...@gmail.com>
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
