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 <m...@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.