Loading ...
Sorry, an error occurred while loading the content.

Mismatch identifying duplicates

Expand Messages
  • britinswe
    As I m coming towards the end of some large projects, I m probably using quite a lot of DVX2 functionality and thus exposed to a whole crosssection of bugs .
    Message 1 of 7 , Apr 20 2:04 PM
    View Source
    • 0 Attachment
      As I'm coming towards the end of some large projects, I'm probably using quite a lot of DVX2 functionality and thus exposed to a whole crosssection of "bugs". I would not call them features.

      What I have discovered in the last few weeks is the following:
      1) Mismatch in the function identifying duplicates from the selection bar with the function used in autopropagate.
      What makes me think this?
      One of my procedures is to identify duplicates from the selection bar (find sets of duplicate source segments, checking ignore case, numerals and embedded codes), I then process these to get maximum, leverage.
      When no duplicates are left, I might start working in alphabetial sorting, as often the beginnings of sentences are similar.

      In this stage I have had many segments autopropagated which were never identified under the selection bar process.
      QED a mismatch between the duplicate algorithims for the two functions is my conclusion so far.

      It would be good if the alogrithim for duplicate identification from the row selector identified the same segments as autopropagate exact matches identifies.(and not aligning autopropagate algorithim with the row selector)

      Is this a bug? Beta testers comments?

      2) Search and replace in target segments produces various kinds of crashes on long files, especially replacing double spaces with single spaces. Perhaps also other types of serach/replace in target segments e.g. spce comma etc.

      3) Row selector for segments with incorrect codes does not identify all incorrect codes. I had a 70,000 word document where export was completed, and at the end a message the file could not be exported.
      That filled me with a cold sweat, the idea of having to srutinise every single segment for completeness and correct sequences. Fortunately Rob Laumens came to my rescue with ctrl+shift+F8 which proved to be much better at identifying incorrect codes. So what might have taken 5 days could be done in half an hour. (Thanks again Rob and Victor for saving me).

      4) I have also had errors when working in duplicate mode where again I have identified duplicates with different target translations. And here changes made have not stuck. They have had to be redone in a kind of iterative process.(Reported earlier, Thomas L is aware of this).

      5) At the risk of boring everyone to death, I still maintain that the bug reporting system is archaic and not encouraging. "Many" of the bugs according to the online reporting system had already been reported, and I would be notifed when a fix is achieved. I have never received any such report, but apparently others have.

      My suggestion is there could be better incentives for Atril to fix bugs. A radical one would be how may times a bug has been reported, when was it first reported. And as classytranslator suggested, it would be good to have an online system where users could check whether the bug they have encountered has been reported by others. And better still would be to give a unique number to the bug reported. And another step in the right direction would be the ability to save the details of bugs locally in a customer log.

      I reported that I couldn't access the details sent off, Gudmund pointed out it was saved to the clipboard. I tried that and it didn't work, but later it was working so I looked at the bug report about 25 pages long!!

      I sincerely hope that Atril starts to get its act together on this front (and some others) and provides a rational system for the benefit of its loyal customers. In my opinion it is almost completely irrational at the moment.

      Having written all the above (big apologies, if you ever get this far), I am still of the view that DVX2 is my best option as Gudmund also wrote about hidden costs, but the gap is narrowing for me at least. So I do hope they make some necessary changes which recognise that most of us don't want to have to spend too much time on handling bug issues.

      So Atril and Beta testers, I think it's time for an open discussion and developing a better way of handling bug reporting, bug fixing before it's too late.

      Nice weekend!
      Brian
    • Peter Eustace
      Hi, Item 3) Selecting Wrong Codes rows has problems when there is only one pair with a wrong code - nothing is displayed Wrong Codes ... it is extremely easy
      Message 2 of 7 , Apr 21 1:22 AM
      View Source
      • 0 Attachment
        Hi,

        Item 3) Selecting Wrong Codes rows has problems when there is only one pair
        with a wrong code - nothing is displayed
        Wrong Codes ... it is extremely easy to cancel the leading or trailing curly
        brackets when cancelling a whole word when there is no space - this causes
        export problems.

        Peter


        -----Messaggio originale-----
        Da: dejavu-l@yahoogroups.com [mailto:dejavu-l@yahoogroups.com] Per conto di
        britinswe
        Inviato: venerdì 20 aprile 2012 23:05
        A: dejavu-l@yahoogroups.com
        Oggetto: [dejavu-l] Mismatch identifying duplicates

        As I'm coming towards the end of some large projects, I'm probably using
        quite a lot of DVX2 functionality and thus exposed to a whole crosssection
        of "bugs". I would not call them features.

        What I have discovered in the last few weeks is the following:
        1) Mismatch in the function identifying duplicates from the selection bar
        with the function used in autopropagate.
        What makes me think this?
        One of my procedures is to identify duplicates from the selection bar (find
        sets of duplicate source segments, checking ignore case, numerals and
        embedded codes), I then process these to get maximum, leverage.
        When no duplicates are left, I might start working in alphabetial sorting,
        as often the beginnings of sentences are similar.

        In this stage I have had many segments autopropagated which were never
        identified under the selection bar process.
        QED a mismatch between the duplicate algorithims for the two functions is my
        conclusion so far.

        It would be good if the alogrithim for duplicate identification from the row
        selector identified the same segments as autopropagate exact matches
        identifies.(and not aligning autopropagate algorithim with the row selector)

        Is this a bug? Beta testers comments?

        2) Search and replace in target segments produces various kinds of crashes
        on long files, especially replacing double spaces with single spaces.
        Perhaps also other types of serach/replace in target segments e.g. spce
        comma etc.

        3) Row selector for segments with incorrect codes does not identify all
        incorrect codes. I had a 70,000 word document where export was completed,
        and at the end a message the file could not be exported.
        That filled me with a cold sweat, the idea of having to srutinise every
        single segment for completeness and correct sequences. Fortunately Rob
        Laumens came to my rescue with ctrl+shift+F8 which proved to be much better
        at identifying incorrect codes. So what might have taken 5 days could be
        done in half an hour. (Thanks again Rob and Victor for saving me).

        4) I have also had errors when working in duplicate mode where again I have
        identified duplicates with different target translations. And here changes
        made have not stuck. They have had to be redone in a kind of iterative
        process.(Reported earlier, Thomas L is aware of this).

        5) At the risk of boring everyone to death, I still maintain that the bug
        reporting system is archaic and not encouraging. "Many" of the bugs
        according to the online reporting system had already been reported, and I
        would be notifed when a fix is achieved. I have never received any such
        report, but apparently others have.

        My suggestion is there could be better incentives for Atril to fix bugs. A
        radical one would be how may times a bug has been reported, when was it
        first reported. And as classytranslator suggested, it would be good to have
        an online system where users could check whether the bug they have
        encountered has been reported by others. And better still would be to give a
        unique number to the bug reported. And another step in the right direction
        would be the ability to save the details of bugs locally in a customer log.

        I reported that I couldn't access the details sent off, Gudmund pointed out
        it was saved to the clipboard. I tried that and it didn't work, but later it
        was working so I looked at the bug report about 25 pages long!!

        I sincerely hope that Atril starts to get its act together on this front
        (and some others) and provides a rational system for the benefit of its
        loyal customers. In my opinion it is almost completely irrational at the
        moment.

        Having written all the above (big apologies, if you ever get this far), I am
        still of the view that DVX2 is my best option as Gudmund also wrote about
        hidden costs, but the gap is narrowing for me at least. So I do hope they
        make some necessary changes which recognise that most of us don't want to
        have to spend too much time on handling bug issues.

        So Atril and Beta testers, I think it's time for an open discussion and
        developing a better way of handling bug reporting, bug fixing before it's
        too late.

        Nice weekend!
        Brian





        ------------------------------------

        --

        Yahoo! Groups Links




        __________ Informazioni da ESET NOD32 Antivirus, versione del database delle
        firme digitali 7073 (20120420) __________

        Il messaggio è stato controllato da ESET NOD32 Antivirus.

        www.nod32.it




        __________ Informazioni da ESET NOD32 Antivirus, versione del database delle
        firme digitali 7073 (20120420) __________

        Il messaggio è stato controllato da ESET NOD32 Antivirus.

        www.nod32.it
      • Gudmund Areskoug
        ... For starters, this is not unknown, it is being discussed, albeit with a different perspective. Don t mix up autopropagation with duplicates. Autopropagate
        Message 3 of 7 , Apr 21 1:52 AM
        View Source
        • 0 Attachment
          On 2012-04-20 23:04, britinswe wrote:
          > What I have discovered in the last few weeks is the following: 1)
          > Mismatch in the function identifying duplicates from the selection
          > bar with the function used in autopropagate. What makes me think
          > this? One of my procedures is to identify duplicates from the
          > selection bar (find sets of duplicate source segments, checking
          > ignore case, numerals and embedded codes), I then process these to
          > get maximum, leverage. When no duplicates are left, I might start
          > working in alphabetial sorting, as often the beginnings of sentences
          > are similar.
          >
          > In this stage I have had many segments autopropagated which were
          > never identified under the selection bar process. QED a mismatch
          > between the duplicate algorithims for the two functions is my
          > conclusion so far.
          >
          > It would be good if the alogrithim for duplicate identification from
          > the row selector identified the same segments as autopropagate exact
          > matches identifies.(and not aligning autopropagate algorithim with
          > the row selector)
          >
          > Is this a bug? Beta testers comments?

          For starters, this is not unknown, it is being discussed, albeit with a
          different perspective.

          Don't mix up autopropagation with duplicates. Autopropagate has some
          smart features that are most of the time beneficial, increasing the
          leverage you get by trying to adapt to small differences of a well
          specified kind.

          Where to draw the line for what should constitute an exact propagation
          and what should end up below that line as fuzzy propagated segments is
          where the discussion is going on.

          In some cases, you know you can trust DV to get it right, and you don't
          want to wade through endless reams of fuzzy marked segments that are all
          perfect, until your mind goes so numb that you actually go on to confirm
          and mark segments finished that are faulty.

          In other cases, for instance when numbers (or numerus for that matter)
          are treated differently between source and target language, or when the
          source text contains numbers in a format actually alien to that language
          (I get a lot of anglicized numbers from tables etc.that have
          indiscriminately just been pasted in, in German for instance), you
          really don't want to risk missing them because they're marked "perfect".

          So: duplicates and autopropagation - different features with different
          purposes. They're just cousins, not twins.

          > 2) Search and replace in target segments produces various kinds of
          > crashes on long files, especially replacing double spaces with single
          > spaces. Perhaps also other types of serach/replace in target segments
          > e.g. spce comma etc.

          Never had that happen to me, sorry. But then it's been a while since I
          had a really large project.

          Running tests that take DV to its extreme limits should be something for
          Daniel to think about, obviously. It is also obvious by now that such
          large projects occur too seldom for the beta tester community to catch
          such errors well.

          > 3) Row selector for segments with incorrect codes does not identify
          > all incorrect codes.

          That's right. What it does is to show you the segments where DV *has
          already identified* incorrect codes.

          It is not for *identifying* segments with incorrect codes, it does *not*
          run a code check. That is what QA > Check Embedded Codes (Ctrl+Shift+F8)
          is for, as it always has been (it existed even back in DV3).

          > 4) I have also had errors when working in duplicate mode where again
          > I have identified duplicates with different target translations. And
          > here changes made have not stuck. They have had to be redone in a
          > kind of iterative process.(Reported earlier, Thomas L is aware of
          > this).

          This sounds bad, but I've never seen this behaviour. Will keep an eye
          open for such mischief henceforth.

          > 5) At the risk of boring everyone to death, I still maintain that the
          > bug reporting system is archaic and not encouraging. "Many" of the
          > bugs according to the online reporting system had already been
          > reported, and I would be notifed when a fix is achieved. I have never
          > received any such report, but apparently others have.

          I haven't either, which I think is bad. It should much rather say
          "thanks for reporting this bug!" and not make false promises, if it is
          indeed so difficult to really make good on the promise.

          > My suggestion is there could be better incentives for Atril to fix
          > bugs. A radical one would be how may times a bug has been reported,
          > when was it first reported. And as classytranslator suggested, it
          > would be good to have an online system where users could check
          > whether the bug they have encountered has been reported by others.
          > And better still would be to give a unique number to the bug
          > reported. And another step in the right direction would be the
          > ability to save the details of bugs locally in a customer log.

          I agree, although the only other instance I know of that has that kind
          of openness in software is the open source movement. I have never seen
          or heard about it in the proprietary sector, AFAIR.

          > I reported that I couldn't access the details sent off, Gudmund
          > pointed out it was saved to the clipboard. I tried that and it didn't
          > work, but later it was working so I looked at the bug report about 25
          > pages long!!

          Yay! ;)

          > I sincerely hope that Atril starts to get its act together on this
          > front (and some others) and provides a rational system for the
          > benefit of its loyal customers. In my opinion it is almost completely
          > irrational at the moment.

          I agree it has to be changed. Removing the message and option that
          raises false expectations would be a lot better than what we have now.

          At any rate, please keep sending the reports. We've been told time and
          again that they really do make a difference.

          > Having written all the above (big apologies, if you ever get this
          > far), I am still of the view that DVX2 is my best option as Gudmund
          > also wrote about hidden costs, but the gap is narrowing for me at
          > least. So I do hope they make some necessary changes which recognise
          > that most of us don't want to have to spend too much time on handling
          > bug issues.
          >
          > So Atril and Beta testers, I think it's time for an open discussion
          > and developing a better way of handling bug reporting, bug fixing
          > before it's too late.

          Yup.

          > Nice weekend! Brian

          Weekend? Oh, that's when work is suddenly so quiet, because the rest of
          society is off doing whatever they do, not working ;)

          BR,
          Gudmund
          --
          This message and any replies to it is scanned by http://www.fra.se
          Please direct any complaints about this to them.
        • britinswe
          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!
          Message 4 of 7 , Apr 22 6:30 AM
          View Source
          • 0 Attachment
            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. And the autopropagate algorithim is IMHO superior.

            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.

            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. What we need is the opposite and with relevant information, viz:
            a) saving info locally
            b) error identification number
            c) when first reported
            d) possibility of checking online as also suggested by classy translator whether the bug has been reported earlier. A step in the right direction when we have a new build which we have not had for some time now, is specific rather than vague details of what has been fixed.

            The cost of the present system is very heavy on user resources, and I have no evidence that it is useful for Atril. Maybe they could comment, and let us know how they use this info to fix bugs etc.

            Brian

            Still in my busy weekend!


            --- In dejavu-l@yahoogroups.com, Gudmund Areskoug <gudmundpublic@...> wrote:
            >
            > On 2012-04-20 23:04, britinswe wrote:
            > > What I have discovered in the last few weeks is the following: 1)
            > > Mismatch in the function identifying duplicates from the selection
            > > bar with the function used in autopropagate. What makes me think
            > > this? One of my procedures is to identify duplicates from the
            > > selection bar (find sets of duplicate source segments, checking
            > > ignore case, numerals and embedded codes), I then process these to
            > > get maximum, leverage. When no duplicates are left, I might start
            > > working in alphabetial sorting, as often the beginnings of sentences
            > > are similar.
            > >
            > > In this stage I have had many segments autopropagated which were
            > > never identified under the selection bar process. QED a mismatch
            > > between the duplicate algorithims for the two functions is my
            > > conclusion so far.
            > >
            > > It would be good if the alogrithim for duplicate identification from
            > > the row selector identified the same segments as autopropagate exact
            > > matches identifies.(and not aligning autopropagate algorithim with
            > > the row selector)
            > >
            > > Is this a bug? Beta testers comments?
            >
            > For starters, this is not unknown, it is being discussed, albeit with a
            > different perspective.
            >
            > Don't mix up autopropagation with duplicates. Autopropagate has some
            > smart features that are most of the time beneficial, increasing the
            > leverage you get by trying to adapt to small differences of a well
            > specified kind.
            >
            > Where to draw the line for what should constitute an exact propagation
            > and what should end up below that line as fuzzy propagated segments is
            > where the discussion is going on.
            >
            > In some cases, you know you can trust DV to get it right, and you don't
            > want to wade through endless reams of fuzzy marked segments that are all
            > perfect, until your mind goes so numb that you actually go on to confirm
            > and mark segments finished that are faulty.
            >
            > In other cases, for instance when numbers (or numerus for that matter)
            > are treated differently between source and target language, or when the
            > source text contains numbers in a format actually alien to that language
            > (I get a lot of anglicized numbers from tables etc.that have
            > indiscriminately just been pasted in, in German for instance), you
            > really don't want to risk missing them because they're marked "perfect".
            >
            > So: duplicates and autopropagation - different features with different
            > purposes. They're just cousins, not twins.
            >
            > > 2) Search and replace in target segments produces various kinds of
            > > crashes on long files, especially replacing double spaces with single
            > > spaces. Perhaps also other types of serach/replace in target segments
            > > e.g. spce comma etc.
            >
            > Never had that happen to me, sorry. But then it's been a while since I
            > had a really large project.
            >
            > Running tests that take DV to its extreme limits should be something for
            > Daniel to think about, obviously. It is also obvious by now that such
            > large projects occur too seldom for the beta tester community to catch
            > such errors well.
            >
            > > 3) Row selector for segments with incorrect codes does not identify
            > > all incorrect codes.
            >
            > That's right. What it does is to show you the segments where DV *has
            > already identified* incorrect codes.
            >
            > It is not for *identifying* segments with incorrect codes, it does *not*
            > run a code check. That is what QA > Check Embedded Codes (Ctrl+Shift+F8)
            > is for, as it always has been (it existed even back in DV3).
            >
            > > 4) I have also had errors when working in duplicate mode where again
            > > I have identified duplicates with different target translations. And
            > > here changes made have not stuck. They have had to be redone in a
            > > kind of iterative process.(Reported earlier, Thomas L is aware of
            > > this).
            >
            > This sounds bad, but I've never seen this behaviour. Will keep an eye
            > open for such mischief henceforth.
            >
            > > 5) At the risk of boring everyone to death, I still maintain that the
            > > bug reporting system is archaic and not encouraging. "Many" of the
            > > bugs according to the online reporting system had already been
            > > reported, and I would be notifed when a fix is achieved. I have never
            > > received any such report, but apparently others have.
            >
            > I haven't either, which I think is bad. It should much rather say
            > "thanks for reporting this bug!" and not make false promises, if it is
            > indeed so difficult to really make good on the promise.
            >
            > > My suggestion is there could be better incentives for Atril to fix
            > > bugs. A radical one would be how may times a bug has been reported,
            > > when was it first reported. And as classytranslator suggested, it
            > > would be good to have an online system where users could check
            > > whether the bug they have encountered has been reported by others.
            > > And better still would be to give a unique number to the bug
            > > reported. And another step in the right direction would be the
            > > ability to save the details of bugs locally in a customer log.
            >
            > I agree, although the only other instance I know of that has that kind
            > of openness in software is the open source movement. I have never seen
            > or heard about it in the proprietary sector, AFAIR.
            >
            > > I reported that I couldn't access the details sent off, Gudmund
            > > pointed out it was saved to the clipboard. I tried that and it didn't
            > > work, but later it was working so I looked at the bug report about 25
            > > pages long!!
            >
            > Yay! ;)
            >
            > > I sincerely hope that Atril starts to get its act together on this
            > > front (and some others) and provides a rational system for the
            > > benefit of its loyal customers. In my opinion it is almost completely
            > > irrational at the moment.
            >
            > I agree it has to be changed. Removing the message and option that
            > raises false expectations would be a lot better than what we have now.
            >
            > At any rate, please keep sending the reports. We've been told time and
            > again that they really do make a difference.
            >
            > > Having written all the above (big apologies, if you ever get this
            > > far), I am still of the view that DVX2 is my best option as Gudmund
            > > also wrote about hidden costs, but the gap is narrowing for me at
            > > least. So I do hope they make some necessary changes which recognise
            > > that most of us don't want to have to spend too much time on handling
            > > bug issues.
            > >
            > > So Atril and Beta testers, I think it's time for an open discussion
            > > and developing a better way of handling bug reporting, bug fixing
            > > before it's too late.
            >
            > Yup.
            >
            > > Nice weekend! Brian
            >
            > Weekend? Oh, that's when work is suddenly so quiet, because the rest of
            > society is off doing whatever they do, not working ;)
            >
            > BR,
            > Gudmund
            > --
            > This message and any replies to it is scanned by http://www.fra.se
            > Please direct any complaints about this to them.
            >
          • Karin Montin
            ... I never really understood this distinction either. If codes have to be identified first, before they can be selected for view, doesn t that mean you have
            Message 5 of 7 , Apr 22 8:02 AM
            View Source
            • 0 Attachment
              On 22/04/2012 9:30 AM, Brian/britinswe wrote:
              > 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?
              I never really understood this distinction either. If codes have to be
              identified first, before they can be selected for view, doesn't that
              mean you have to Ctrl-Shft-F8? And if you do that, why not fix them as
              you go?

              Does anyone go through just marking mismatched-code segments, only to
              select them for view and fix them later?

              Karin
            • Gudmund Areskoug
              ... Are there really *no* differences, not even codes, figures, commas, spaces, periods, accents and what have you, and they re still not recognized as
              Message 6 of 7 , Apr 22 9:20 AM
              View Source
              • 0 Attachment
                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.

                BR,
                Gudmund
                --
                This message and any replies to it is scanned by http://www.fra.se
                Please direct any complaints about this to them.
              • britinswe
                Message 7 of 7 , Apr 22 11:49 AM
                View Source
                • 0 Attachment
                  <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.

                  Brian


                  --- In dejavu-l@yahoogroups.com, 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.
                  >
                  > BR,
                  > Gudmund
                  > --
                  > This message and any replies to it is scanned by http://www.fra.se
                  > Please direct any complaints about this to them.
                  >
                Your message has been successfully submitted and would be delivered to recipients shortly.