search

jwilk / i18nspector

checking tool for gettext POT, PO and MO files
https://jwilk.net/software/i18nspector
MIT License
2 stars 4 forks source link

Please add checks for Perl String::Errf format #5

Open intrigeri opened 4 years ago

intrigeri commented 4 years ago

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 commented 4 years ago

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:

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 commented 4 years ago

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 commented 4 years ago

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.