Please add checks for Perl String::Errf format

[intrigeri]

Hi!

It would be nice to have some basic checks for perl-brace-format, as implemented by https://metacpan.org/pod/String::Errf.

The equivalent of python-format-string-argument-type-mismatch and python-format-string-missing-argument, even without support for plural forms, would already be a great start, and would have avoided a serious bug in Tails.

Thanks for considering :)

[jwilk]

The bug in question looked like this:

#, perl-brace-format
msgid "Downloading the upgrade to %{name}s %{version}s..."
msgstr "%{name} %{version} güncellemesi indiriliyor..."

The message was flagged as perl-brace-format, which isn't really correct. GNU gettext documentation says:

Perl brace format strings are described in the Locale::TextDomain manual page […]. In brief, Perl format uses placeholders put between braces ({ and }). The placeholder must have the syntax of simple identifiers.

This is different format than String::Errf. In particular, the lack of s after } wouldn't be an error from Locale::TextDomain's point of view, since that's just literal string.

So I have the following questions:

• Is gettext + String::Errf a common combination in the Perl world?

• If yes, could you ask GNU gettext maintainers to add support for this format?

• If no, would it make sense for Tails to switch to Locale::TextDomain?

To be clear, i18nspector doesn't support Locale::TextDomain format strings either, but I could be more easily convinced to add checks for something that's understood by GNU gettext.

[intrigeri]

Thanks a lot for all this detailed info. Sorry I did not do my homework properly before filing this issue!

So I have the following questions: * Is gettext + String::Errf a common combination in the Perl world?

Judging by reverse-dependencies in CPAN, reverse-dependencies in Debian, and Debian popcon, it looks like the answer is a clear "no".

* If no, would it make sense for Tails to switch to Locale::TextDomain?

At first glance, it seems entirely feasible. I'll give it a try!

To be clear, i18nspector doesn't support Locale::TextDomain format strings either, but I could be more easily convinced to add checks for something that's understood by GNU gettext.

This totally makes sense to me. Shall we repurpose this issue to be about supporting `Locale::TextDomain` format strings, or do you prefer rejecting this one and me filing a new issue?

[jwilk]

Shall we repurpose this issue to be about supporting Locale::TextDomain format strings, or do you prefer rejecting this one and me filing a new issue?

I've marked this as wontfix, and opened #6.