The overall progress could be inaccurate since po files with 100% translation progress are excluded #7

New issue

Closed

opened 2023-08-29 12:22:48 +02:00 by mattwang44 · 2 comments

mattwang44 commented

2023-08-29 12:22:48 +02:00

Contributor

Hi team,

Thanks for implementing and maintaining this wonderful tool! I use it frequently in our project to keep track of the translation progress. Much appreciated!

One tiny awkward thing I spotted today is that, after I finished the translation of one po file in my project, the overall progress (displayed in the last line of the CLI output) somewhat dropped. I believe the root cause is the po files with 100% translation progress being excluded from being displayed in the output and deriving for the overall progress (source). I wonder if this behavior is expected. If not, I'm willing to send a PR for this, but would like to have a discussion about how to modify it correctly first (e.g. consider 100% po files when calculating the overall progress, but still hide them from the output?).

Thanks again!

Hi team, Thanks for implementing and maintaining this wonderful tool! I use it frequently in our project to keep track of the translation progress. Much appreciated! One tiny awkward thing I spotted today is that, after I finished the translation of one po file in my project, the overall progress (displayed in the last line of the CLI output) somewhat dropped. I believe the root cause is the po files with 100% translation progress being excluded from being displayed in the output and deriving for the overall progress ([source](https://git.afpy.org/AFPy/potodo/src/commit/27f36b6a1bfda9dc5b5388776a1d587b5505799c/potodo/potodo.py#L134-L138)). I wonder if this behavior is expected. If not, I'm willing to send a PR for this, but would like to have a discussion about how to modify it correctly first (e.g. consider 100% po files when calculating the overall progress, but still hide them from the output?). Thanks again!

👍 1

rffontenelle commented

2024-08-19 19:27:44 +02:00

Another thing to consider when retrieving the total number of strings is that not all PO file could be available. Two scenarios I see are:

not all PO files were initialized for some reason (e.g. ran msginit to generate specific PO from POT file, instead of all); or
they were not all downloaded from the translation platform (e.g. team set minimum threshold of translation completion to greater than 0%, so empty PO files are not downloaded).

Besides the PO files, POT are also good source for retrieving the total number of strings. For instance, Python docs can give all POT files by running make -C Doc gettext for root directory, and Doc/build/gettext will have all the POT files.

I haven't checked how much work is it, but maybe adding a command-line option to pass the directory to read the total number of strings is the most flexible alternative, defaulting to the current directory (default of potodo) or the -p/--path's directory.

Another thing to consider when retrieving the total number of strings is that not all PO file could be available. Two scenarios I see are: - not all PO files were initialized for some reason (e.g. ran `msginit` to generate specific PO from POT file, instead of all); or - they were not all downloaded from the translation platform (e.g. team set minimum threshold of translation completion to greater than 0%, so empty PO files are not downloaded). Besides the PO files, POT are also good source for retrieving the total number of strings. For instance, Python docs can give all POT files by running `make -C Doc gettext` for root directory, and Doc/build/gettext will have all the POT files. I haven't checked how much work is it, but maybe adding a command-line option to pass the directory to read the total number of strings is the most flexible alternative, defaulting to the current directory (default of potodo) or the -p/--path's directory.

mdk commented

2024-08-24 10:36:27 +02:00

Owner

@rffontenelle If you're experiencing this, I'd say OK to implement a --pot flag, but maybe in separated PR, that's something else. If you don't experience it I'd say: keep it simple, don't solve problems we don't have.

@mattwang44 yes computing with all the files, and only filtering at display time looks good to me.

@rffontenelle If you're experiencing this, I'd say OK to implement a `--pot` flag, but maybe in separated PR, that's something else. If you don't experience it I'd say: keep it simple, don't solve problems we don't have. @mattwang44 yes computing with all the files, and only filtering at display time looks good to me.

mattwang44 referenced this issue from a pull request that will close it,

2024-11-19 16:42:49 +01:00

fix: consider finished files and hide them from output by default #10