feat(checks): detect extra curly braces in Python brace format

[nijel]

Proposed changes

Fixes #12197

Checklist

• Lint and unit tests pass locally with my changes.
• I have added tests that prove my fix is effective or that my feature works.
• I have added documentation to describe my feature.
• I have squashed my commits into logic units.
• I have described the changes in the commit messages.

Other information

[codecov]

Codecov Report

Attention: Patch coverage is 96.15385% with 1 line in your changes missing coverage. Please review.

Project coverage is 90.34%. Comparing base (6aee586) to head (941373b).
Report is 2988 commits behind head on main.

Files	Patch %	Lines
weblate/checks/format.py	94.44%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #12198      +/-   ##
==========================================
- Coverage   90.82%   90.34%   -0.48%     
==========================================
  Files         554      583      +29     
  Lines       57306    59966    +2660     
  Branches     9122     9604     +482     
==========================================
+ Hits        52046    54176    +2130     
- Misses       3640     3993     +353     
- Partials     1620     1797     +177     

Files	Coverage Δ
weblate/checks/tests/test_format_checks.py	100.00% <100.00%> (ø)
weblate/checks/format.py	93.13% <94.44%> (-0.70%)	⬇️

... and 394 files with indirect coverage changes

[buhtz]

Thank you for this quick response.
I am not sure but the code looks like that it wouldn't catch all situations. And I don't understand the unit tests. The test code is not self explaining and has no comments. It is not clear for me which one of the cases should be an error and which not.

Other cases:

• "foo }bar{" (seems not to fail in your code)

Maybe my own solution (related to PR bit-dev/backintime#1829) using a combination of regex can give you some inspiration.

I also encountered strings like this: "{{foobar}}". I am aware that this is a valid Python string to escape curly brackets. But in real world in most cases this is a typo from the translator. So if you see a possibility it would be nice if Weblate could warn about that, too. Or maybe compare it to the original string and look if there are escaped brackets, too.

EDIT: And just a learning question for me as a maintainer. Don't you have a review policy for code changes in your project? Aren't there other reviews in the team?

[buhtz]

The doc strings has potential to be improved. Not clear what it does. Arguments and return values are unclear.

Because of that I am unable to value the new unit tests using this method.

[nijel]

Indeed, the documentation always has potential to get improved. Currently, I'm at least focusing on adding type annotations when touching the code.

[nijel]

#12199 should improve this.

There is currently nobody to do a review, but I hope this to change soon as some new team members will get fully onboarded.

[buhtz]

Are you and the planed reviewers employed by Weblate company?
You might contact the Codeberg.org community and people. The might have capacity and they depend on Weblate.