Re: Mismatch identifying duplicates
- <1. Are there really *no* differences, not even codes, figures, commas, spaces, periods, accents and what have you, and they're still not recognized as duplicates?<
Correct no differences that is what I believe. That is why I belive there are errors in Duplicvate identification via the segment selector.
<2.Been there too. Once others, especially Atril began seeing the same problem(s) I had reported, they started getting fixed.<
That's why I am saying this is not a rational system, too much energy required to get through. Atril receive reports via the online system, and also hopefully from beta testers on this list.
< 3. I think I did get you right. What I meant is that it is better not to give false hope than to act as if all this fine feedback actually works, only to leave it unfulfilled.<
Again I disagree your solution of removing the little info we receive is a clear step backwards. It does not lead to progress. The important thing is they use the information, or at least collect information that allows them to start fixing bugs.
It would be OK if there were only a few bugs, but I have experienced more than a few.
You and others have said the info is used. Convince me please.
But you do seem to be wavering a little in the belief that it "actually works" viz:
<What I meant is that it is better not to give false hope than to act as if all this fine feedback actually works, only to leave it unfulfilled<
In addition, you don't comment on a user log saved locally to help users.
So Gudmund, I have put more than a little energy into this, you too in responding, but what have we actually achieved? How much closer have we got to Atril waking up and doing something about the whole bug reporting system.
Perhaps I have to set up my own web list of bugs which other users might find helpful, and could add to if and when. But at this moment I'm too busy.
--- In firstname.lastname@example.org, Gudmund Areskoug <gudmundpublic@...> wrote:
> On 2012-04-22 15:30, britinswe wrote:
> > 1) My understanding of "exact autopropagate" is that when using this
> > it will propagate to other 100% identical source segments as happened
> > in my project. Good! But these identical source segments were not
> > identified by find duplicates either with or without the various find
> > duplicate options checked. BAD! As they are exact duplicates. And if
> > not should not be propagated. Different algorithims are used.
> Are there really *no* differences, not even codes, figures, commas,
> spaces, periods, accents and what have you, and they're still not
> recognized as duplicates?
> > And the
> > autopropagate algorithim is IMHO superior.
> There appears to be some debate about that, since it indeed does today
> not deal strictly with true 100% matches, but can include ones where
> numbers are different. Bad, in many people's view.
> > 2) The frustrating thing when I go to the trouble of reporting basic
> > bugs as in the S&R bug, is that as it hasn't happened in your
> > experience, maybe it does not exist. I can replicate this in any
> > large project. So how many times does it have to be reported. I think
> > this is one of the reasons why we need to move to a rational system
> > that is transparent and not time consuming for users.
> FWIW, I do believe you. I've been in that situation myself. Problem is
> that the developers need to be able to duplicate it, or they can't see
> where the problem lies and fix it (with some exceptions).
> Been there too. Once others, especially Atril began seeing the same
> problem(s) I had reported, they started getting fixed.
> > 3) Did not understand your reasoning about segments with code
> > errors.
> > <That's right. What it does is to show you the segments where DV
> > *has
> >> already identified* incorrect codes.
> > And surely if new segments with incorrect codes are created they will
> > be identified. Or is there some point in time when the segment
> > identifier stops identifying code errors?
> > 3) I think you drew the wrong conclusions about Point 5, by
> > suggesting the removal of information.
> I think I did get you right. What I meant is that it is better not to
> give false hope than to act as if all this fine feedback actually works,
> only to leave it unfulfilled.
> They should remove it until they can make good on what the system promises.
> *And* then improve it, and open it up as it gets ready.
> This message and any replies to it is scanned by http://www.fra.se
> Please direct any complaints about this to them.