[bug#35394] [PATCH 4/4 v4] Grub i18n

["Miguel Ángel Arruga Vivas" <rosen644835@gmail.com>]

Hi Ludo,

Thanks for your review and your ideas, I'll comment inline.

Ludovic Courtès <ludo@gnu.org> writes:
>> +  (define (translate-label label)
>> +    (match label
>> +      (('hurd name version)
>> +       ;; TRANSLATORS: The first parameter is the capitalized package name
>> +       ;; for the Hurd kernel, which uses the definite article in English.
>> +       ;; The second parameter contains the version string.
>> +       #~(format #f (G_ "GNU with the ~a ~a") package version))
>> +      (('linux name version)
>> +       ;; TRANSLATORS: The first parameter is the capitalized package name
>> +       ;; for Linux kernel, which doesn't use the definite article in
>> +       ;; English.  The second parameter contains the version string.
>> +       #~(format #f (G_ "GNU with ~a ~a") package version))
>> +      (('unknown)
>> +       ;; TRANSLATORS: This is the label for an unknown system to be booted.
>> +       #~(G_ "GNU"))
>> +      ((? string? old-format)
>> +       ;; We cannot translate properly the old format.
>> +       old-format)))
>
> It’s not good that we’re baking assumptions about the label here: the
> user is free to choose the label they want in the ‘label’ field, and we
> don’t want to replicate “GNU with the” etc. in each bootloader.

I guess the main problem here was calling it 'old-format', as this is
the format that would be received for the labels provided by the user
too, I should have called it 'fixed-label' instead.  I didn't though of
this at first so that was the name, but the user provided label works as
always: the installation image was the first example I checked, as it
does exactly that---that startled me a bit until I noticed, by the way.

> It’s also not great that we’re changing the boot parameters again as
> this can make compatibility trickier down the road.

That was an important point of this design, and the reason why I created
the test in the first place: the tests try to cover all the
possibilities, the old format and the new one(s). :-)

> (Brainstorm…)
>
> I would simply translate it on the client side by temporarily setting
> LANGUAGE to the target locale.  The downside is that this will not be
> translated if the target locale is not supported by the host.
>
> Alternately, we could have:
>
>   (define (formatted-i18n-string locale fmt . args)
>     (computed-file "formatted-i18n-string"
>                    #~(begin
>                        (textdomain …)
>                        (setlocale …)
>                        (call-with-output-file #$output
>                          (lambda (port)
>                            (format port …))))))

I'd prefer this option, as it avoids triggering the translation on the
client side, and it could be used in other places too if needed.  It
needs xgettext support and a tag (like F_ or L_) would be very concise,
and useful from my point of view.  There are some other places
(e.g. gnu/machine/ssh.scm:395) which use string-append for user visible
strings[1].  They should be localized with a proper format, and
including the format call into the i18n call itself helps to ensure
that.

> We would then need to adjust all bootloaders to read the label from that
> file.  If the user-supplied ‘label’ is a plain string, we’d wrap it in
> (plain-file …) so that ‘label’ is always a file-like object.

I'll probably raise some questions about the design here and there, and
maybe open another thread for the point before, but as soon as I have
anything tangible, I'll send a patch. :-)

Happy hacking!
Miguel

[1] https://www.gnu.org/software/gettext/manual/gettext.html#No-string-concatenation