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... |
![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>
|
@echoix This breaks WMS, specifically the change in |
|
Indeed, I see an unexpected |
|
Do you mind filing in the PR? |
@arohanajit Can you please do it? Thanks! |
|
Maybe a spot check that $s isn't anywhere else in code strings. I know there's some rules for unused arguments, maybe Pylint, but probably not active yet |
Fixes a string causing problems after OSGeo#4052
Did it |
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.