[Lazarus] Pochecker (was Fuzzy traslations ignored)

Giuliano Colla giuliano.colla at fastwebnet.it
Mon Sep 29 23:19:26 CEST 2014

Il 29/09/2014 21:35, Bart ha scritto:
> On 9/29/14, Giuliano Colla <giuliano.colla at fastwebnet.it> wrote:
>> Please find here enclosed my proposed patch for Pochecker.
> I took a quick look at the patch:
>> 2) In order to be able to open the file, I needed its full name, so I've
>> been forced to add a new property to Tstat, and then pass its value to
>> TStat.Create.
> I would rather call th eproperty FullName instead of Name...
> Also it we could just use the fullname only (and extract shortname
> when needed, or declare a function PoShortName).
I fully agree on FullName. For the rest, I think that one more property 
is less expensive in terms of code, and on speed.
>> 6) At startup the last choices are remembered, but not by the OpenFile
>> dialog. Therefore I've set the InitialDir of the dialog to the one of
>> the last file, which is usually a much better starting point than the
>> defaults.
> I intend to have that in the PoChecker.xml settings.
>> 7) Trying to use the tool I realized that another feature was missing:
>> GraphStat provided only information about the
>> Translated/Untranslated/Fuzzy, but didn't tell a thing about errors.
>> Therefore I've added another property to TStat, and filled it properly
>> (TStat.Create, etc). Then I've added a red question mark to the pie
>> image when the errors are > 0, and I've added the number of errors to
>> the hint.
> This is wrong, I think.
> ErrCount depends on the previous tests that have run (and on the
> "Ignore Fuzzy" option.
> The CheckStatistics runs independantly from all other tests.
> As a result the new property for TStat can be rather misleading.

Why should it be misleading? It just tells if there are any errors for 
the tests required. If you set "Ignore Fuzzy" it means that you don't 
care and the format errors of Fuzzy translations are not counted.

> When I have more time I will test the patch and adapt it (see notes above).
> One further remark.
> For the sake of svn history it is encouraged to split commits per
> "issue fixed", so in this case:
> - antialiasing
> - better hints
> - IDE integration
> Makes for better bug-hunting in the future.
I'll remember for next time.


Giuliano Colla

Project planning question: when it's 90% done, are we halfway or not yet?

More information about the Lazarus mailing list