style: Fix all flake8-gettext (INT) errors (INT001, INT002, INT003) #4052
Conversation
Ruff rules: https://docs.astral.sh/ruff/rules/f-string-in-get-text-func-call/ https://docs.astral.sh/ruff/rules/format-in-get-text-func-call/ https://docs.astral.sh/ruff/rules/printf-in-get-text-func-call/ For stds_export.py, the strings were normalized with placeholders reducing almost-identical strings to identical strings
echoix
force-pushed
the
fix-flake8-gettext-INT
branch
from
20950c5
to
f3e7a4f
Compare
|
@neteler Maybe you have an opinion on this too |
I could imagine that all related existing translations would be changed to "fuzzy". If so, that might be very demotivating for the translators. What does @HuidaeCho think? |
|
If the translation files are up to date before this PR, there should be a way to undo changes to the source strings, recreate the translation files (I expect no changes), apply back the source string changes (possibly in small batches), recreate the translation files, and manually/with a tool combine back the changes to the translations. |
I'm not sure about that. These strings are still the same, so why would they become fuzzy? Because of line number changes? I'll try it when I get a chance. |
That's the problem, some were changed just a little (placeholders), but maybe I could revert them. |
|
Also, if you get emails about the status updates of our weblate, it got relocked this morning after a new PR merged... |
There was a problem hiding this comment.
Looks good to me as it is except what is in the comments.
Just a heads up that keeping the messages same may have a similar frustration effect as suggested in a comment by @neteler just some time later. For example, string "Unable to remove timestamp for raster map" is correctly extracted for translation and if I understand correctly will therefore remain the same even after this PR. Because the string is no finally passed to the translate function (and not its modified version), it will be translated for the user for the first time only after this PR. Later, we may be changing all %-style strings or, much more likely, at least all strings with multiple %s or {} to format-style with keywords ({name}), so this will change the strings for sure. A string translated in the interface (thanks to this PR) will then be removed. So, same additional work for the translators as if we would change the strings now, but with more frustration with the final product where the once translated strings will disappear.
Overall, this PR (both the fixes and the enabled warning) is crucial for making the translation actually work consistently. The exact order of calls is clearly hard to grasp for contributors who don't deal with the translations themselves as demonstrated by the number of corrections needed here. This PR is fixing previous mistakes and avoids future ones.
Co-authored-by: Vaclav Petras <wenzeslaus@gmail.com>
|
Clangformat has some activity on this error today |
|
See DoozyX/clang-format-lint-action#75 (review) for the second PR supposed to fix that |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
|
@wenzeslaus can you re-approve (or anyone)? I had to resolve a conflict in t.rast.what (a line was removed) |
|
So now, we need to regenerate the template files. Last time it was @HuidaeCho that did it. Is it necessary for it to be a manual job? |
…SGeo#4052) * style: Fix all flake8-gettext (INT) errors (INT001, INT002, INT003) Ruff rules: https://docs.astral.sh/ruff/rules/f-string-in-get-text-func-call/ https://docs.astral.sh/ruff/rules/format-in-get-text-func-call/ https://docs.astral.sh/ruff/rules/printf-in-get-text-func-call/ * Revert source string changes when unneeded. * Update univar_statistics.py Co-authored-by: Vaclav Petras <wenzeslaus@gmail.com> * Update panels.py for Python script type string * Update pyedit.py to keep path keyword in changed string * Update univar_statistics.py to make already translated strings match again * Update pyedit.py * Update model.py --------- Co-authored-by: Vaclav Petras <wenzeslaus@gmail.com>
This fixes all instances in python files where translated strings are formatted before being fetched by gettext. (underscore function)
Ruff rules:
https://docs.astral.sh/ruff/rules/f-string-in-get-text-func-call/
https://docs.astral.sh/ruff/rules/format-in-get-text-func-call/
https://docs.astral.sh/ruff/rules/printf-in-get-text-func-call/
Some places I changed from percent formatting to dot format in order to use named parameters, to add more context for translators. Unfortunately, it might cause the source string to be different, and I'm not sure of the consequences on Weblate. From this FAQ https://docs.weblate.org/en/latest/faq.html#how-do-i-translate-several-branches-at-once, I understand that they don't really support translating for different branches, so having a source string changed makes it unavailable for backporting (if ever we are doing this). The translation files should be regenerated after this, as they are even out of date currently (merge conflicts when weblate tries to rebase because we use squash merge).
In a small number of cases, where I had added named format parameters, I also changed the strings around so they match the same string, and can be translated as one.
In
r.in.wms, I'm pretty sure the variable "format" doesn't exist, and this, since the first commit of that file 12 years ago when it was migrated from an addon. I supposed it meantself.gdal_drv_format, from the context and another translated string near, but it is also possible it meant one of the parameters of the module (that wasn't called correctly if it was the case). Please take a look to confirm my guess.These were all manual fixes, as no auto-fix was available.
I was committing in batches (also to help reviewing if it's too long in one go), I was planning on having the squash message clean this up.