Bug 311000 - [poextractor] Lokalize counts fuzzy untranslated po strings as both fuzzy and untranslated
Summary: [poextractor] Lokalize counts fuzzy untranslated po strings as both fuzzy and...
Status: RESOLVED FIXED
Alias: None
Product: lokalize
Classification: Applications
Component: general (other bugs)
Version First Reported In: 1.5
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Simon Depiets
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-12-01 21:17 UTC by Lasse Liehu
Modified: 2019-03-08 09:57 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Lasse Liehu 2012-12-01 21:17:10 UTC
Steps to reproduce:

1. Open a PO file
2. Mark an untranslated string as fuzzy

Actual results:

In the editor, the unfuzzy count increases by one, but the untranslated count stays the same. In the project overview, the translated count decreases by one while the unfuzzy count increases and the untranslated count stays the same.

Expected results:

The translated count shouldn't decrease and the fuzzy untranslated string should be counted as either fuzzy or untranslated.

Additional information:

msgfmt --statistics counts such strings as untranslated while polib (python library for po files) counts them as fuzzy.
Comment 1 Karl Ove Hufthammer 2019-01-05 14:24:37 UTC
I can partly confirm with the latest Git version of Lokalize. If you fuzzy an empty string, the number of ‘Not Ready’ strings (‘fuzzy’ has unfortunately been renamed to ‘not ready’ in recent Lokalize versions, something which IMHO is just confusing) in the editor is increased, which seems like a bug, since the numbers are no longer consistent. In the project overview, there is no change.

In ‘msgfmt --statistics’, there is no change, while in Pology, the number of fuzzy strings is increased by 1 and the number of untranslated strings is decreased by 1. I don’t know which of these ways of counting is best, but they’re at least both consistent (i.e. the number of strings of various types sum to the total number of strings).

I think the simplest solution would be to change the numbers in the editor to be the same as the numbers in the project overview (which are the same as the msgfmt numbers).

Here are some example numbers from a test I just ran:

Before fuzzying empty string:

Project Overview
----------------
Total: 97
Translated: 90
Not ready: 3
Untranslated: 4
Incomplete: 7


Editor
------
Total: 97
Not ready: 3
Untranslated: 4


Pology
------
total: 97
translated: 90
fuzzy: 3
untranslated: 4


msgfmt --statistics
-------------------
translated: 90
fuzzy: 3
untranslated: 4



*After* fuzzying empty string:

Project Overview: no change
msgfmt --statistics: no change

Editor (‘Not ready’ changed)
----------------------------
Total: 97
Not ready: 4 (before: 3)
Untranslated: 4


Pology (‘fuzzy’ and ‘untranslated’ changed)
-------------------------------------------
total: 97
translated: 90
fuzzy: 4 (before: 3)
untranslated: 3 (before: 4)
Comment 2 Karl Ove Hufthammer 2019-01-05 14:26:14 UTC
BTW, for the Pology tests, I used ‘posieve stats’.
Comment 3 Simon Depiets 2019-03-08 09:57:50 UTC
Git commit 617c5313ec5f2652c5bbcb70e8e591305171208e by Simon Depiets.
Committed on 08/03/2019 at 08:03.
Pushed by sdepiets into branch 'master'.

Count empty fuzzy as empty only (not as fuzzy too)

M  +17   -3    src/catalog/catalog.cpp
M  +1    -1    src/catalog/catalog.h
M  +1    -0    src/catalog/catalog_private.h

https://commits.kde.org/lokalize/617c5313ec5f2652c5bbcb70e8e591305171208e