Tails

#2 Updated by intrigeri 2020-03-28 07:52:05

Hi!

> The update breaks with: Unknown conversion in stringf: at /usr/local/share/perl/5.28.1/Tails/IUK/Frontend.pm line65.

Ouch!

Assuming the fixed translated string was reviewed in Transifex, it’ll be imported by the RM (kibi) while releasing 4.5.
So for the immediate problem at hand, I believe we’re good.

But IMO we should set up safeguards to avoid such problems in the future. For example:

• lint_po could ensure we don’t import translations that would trigger this problem.
  • To do so, I would need to know what was the problem in the faulty translated string → kibi, emma?
  • This would be ideal IMO, as we would catch the problem earlier, in a way that we can fix its root cause.
• Our Perl code that manipulates these strings could fallback to English when it hits such an error.
  • This seems feasible but I’m concerned this just papers over the problem, and it significantly lowers the chances we ever fix the root cause in Transifex.
  • I would need to reproduce the bug and check where exactly the problem happens (the reported error message is not sufficient, either due to a typo or to my code reporting errors in a unhelpful way).
  • In passing, this probably also affects the Persistence wizard as it shares the same code in this area.

#3 Updated by emmapeel 2020-03-28 09:55:52

intrigeri wrote:
> Hi!
>
> > The update breaks with: Unknown conversion in stringf: at /usr/local/share/perl/5.28.1/Tails/IUK/Frontend.pm line65.
>
> Ouch!
>
> Assuming the fixed translated string was reviewed in Transifex, it’ll be imported by the RM (kibi) while releasing 4.5.
> So for the immediate problem at hand, I believe we’re good.
>
> But IMO we should set up safeguards to avoid such problems in the future. For example:
>
> * lint_po could ensure we don’t import translations that would trigger this problem.
> To do so, I would need to know what was the problem in the faulty translated string → kibi, emma?

yes, the perl brace format was missing the last s:

kibi found it doing $ git grep %.*name.version — po/.po|grep -v ‘}s.*}s’
po/tr.po:msgstr “{name}{version} güncellemesi indiriliyor…”

> This would be ideal IMO, as we would catch the problem earlier, in a way that we can fix its root cause.

yes, that would be lovely. btw, weblate checks this, transifex not.

> * Our Perl code that manipulates these strings could fallback to English when it hits such an error.

Nice idea!

> This seems feasible but I’m concerned this just papers over the problem, and it significantly lowers the chances we ever fix the root cause in Transifex.
> I would need to reproduce the bug and check where exactly the problem happens (the reported error message is not sufficient, either due to a typo or to my code reporting errors in a unhelpful way).

I fixed it in transifex, and now the error should dissapear. The commit is
https://gitweb.torproject.org/translation.git/commit/?h=tails-misc&id=f14405bec5592e1221bbda25559aaf08503fed5e so you could test with a previous commit.

> In passing, this probably also affects the Persistence wizard as it shares the same code in this area.

ha! fixed before been reported!

#5 Updated by emmapeel 2020-03-28 10:14:31

Here the weblate information: https://docs.weblate.org/en/weblate-2.6/user/checks.html#format-strings

#6 Updated by intrigeri 2020-03-28 10:16:36

> btw, weblate checks this

Great! So, I understand that Bug #17205 would have avoided this problem.

>> * Our Perl code that manipulates these strings could fallback to English when it hits such an error.
>
> Nice idea!

>> This seems feasible but I’m concerned this just papers over the problem, and it significantly lowers the chances we ever fix the root cause in Transifex.

Implementation:

• We would need to wrap our calls to errf to catch at least the Unknown conversion in stringf exceptions it raises (__replace_errf, __format_errf).
• Whatever wrapper function we create will need to know what the English string is (so it can fallback to it on error):
  • either it would be responsible for the translation & char decoding
  • or it would need to be passed both the English string and the localized one

This sounds feasible and no rocket science. But:

• As anything that touches the Upgrader, to manage the risk of regressions we’ll need to test lots of cases manually, so it can’t possibly be super cheap.
• This work will become useless once we do Bug #17205.

So my current mood is: I’d rather see us spend time on Bug #17205.

>> I would need to reproduce the bug and check where exactly the problem happens (the reported error message is not sufficient, either due to a typo or to my code reporting errors in a unhelpful way).
>
> I fixed it in transifex, and now the error should dissapear. The commit is
> https://gitweb.torproject.org/translation.git/commit/?h=tails-misc&id=f14405bec5592e1221bbda25559aaf08503fed5e so you could test with a previous commit.

Thanks. I think I can reproduce by starting Tails 4.4, too :)

#7 Updated by intrigeri 2020-03-28 10:39:50

> Here the weblate information: https://docs.weblate.org/en/weblate-2.6/user/checks.html#format-strings

Thanks! Presumably it wouldn’t be too hard to add support for the format string syntax used by our Perl code.

#8 Updated by CyrilBrulebois 2020-03-28 13:37:54

FWIW as you’ve probably guessed, the quick grep quoted by emma above was just part of a quick assessment to determine whether some other languages were affected by this particular issue, rather than a definitive test for the general issue.

Whether that’s done in Weblate or in lint_po, I suppose it wouldn’t be too crazy to mandate the following: msgid marked with perl-brace-format must have either an empty msgstr (not translated yet), or contain the same amount of %{SOMETHING}L (L being a letter) as the original msgid?

I haven’t found any definitive answer regarding the actual format by quickly looking into those:

- https://www.gnu.org/software/gettext/manual/html_node/perl_002dformat.html
- https://metacpan.org/pod/Locale::TextDomain

(The latter doesn’t even have an example of %{foo}s …)

But it seems our current code base is limited to L being either s for string or i for integer (more quick greps in tails.git, leading to results under config/chroot_local-includes/usr/src).

#9 Updated by intrigeri 2020-03-28 14:01:35

> Whether that’s done in Weblate or in lint_po, I suppose it wouldn’t be too crazy to mandate the following: msgid marked with perl-brace-format must have either an empty msgstr (not translated yet), or contain the same amount of %{SOMETHING}L (L being a letter) as the original msgid?

I think that’s correct.

> I haven’t found any definitive answer regarding the actual format by quickly looking into those:

These format strings are interpreted by https://metacpan.org/pod/String::Errf.