Re: Word order in Guix l10n

[Miguel Ángel Arruga Vivas]

Hi Julien,

Julien Lepiller <julien@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

0001-nls-Add-comment-about-format-directives.patch
Description: comment.patch