bug#61965: Commands like "guix system search KEYWORD" don't work with locale it_IT.utf8

[Julien Lepiller <julien@lepiller.eu>]

Gettext already checks issues with format strings, and for the manual, I always try to build it, so I can catch most issues. Unfortunately, we don't have good tools to check texinfo markup in our strings, so this kind of error can stell slip in, I hadn't realized.

I'll try to contact the translator who did that and see if they have an idea how to make the situation better.

At the very least, I think we should validate strings better before we accept translations, and make warnings more visible.

Le 10 mars 2023 10:42:24 GMT+01:00, Tobias Geerinckx-Rice <me@tobias.gr> a écrit :
>> I believe Tobias (Cc’d) fixed this and related issues
>> a couple of days ago
>
>Yep.  I also fixed a worrying number of @comando, @opzione, etc. on Weblate (both in the 'guix' and 'packages' sets).
>
>Weblate is pretty unfriendly, so this was tedious and I'm positive there are some I missed.  There's a comment warning translators not to do this, but it's sadly useless since it's tied to *one* package—the odds of seeing it are vanishing.
>
>Julien, is there a way to make this warning more prominent/ubiquitous?
>
>(Also, is there a translation workflow that avoids relying on Weblate or other clunky tools?)
>
>Run-time errors appear to be the only QA available for these strings, but this failure mode is extreme.  How about explicitly reporting the error & continuing in English?
>
>From what I remember, the code won't be elegant (we append to the translation, then convert Texi, so falling back must be done by the caller or a new combo procedure) but the result would be better.
>
>Kind regards,
>
>T G-R
>
>Sent on the go.  Excuse or enjoy my brevity.