docs: update manual description of matches pane

[miurahr]

Pull request type

• Documentation

Which ticket is resolved?

• FindMatcher always search separate segment match without penalty
• https://sourceforge.net/p/omegat/bugs/1251/

What does this PR change?

• split [BUGS#1251] FindMatches always search separate segment match without penalty: add regression test, fix it, make configurable, show where comes from in FuzzyMatch pane, and refactor #963
• Update manuals for segmented matches feature and its preference

Other information

[miurahr]

When clear approval received, I will merge it.

[Kazephil]

I am proposing some rephrasing of the entries in the manual. Let me know if they are inaccurate, or if I inadvertently left some typos.

[miurahr]

https://omegat.sourceforge.io/manual-snapshot/en/chapter.panes.html#panes.fuzzy.matches

The current manual has the edit screen image. It may be better to improve there.

[brandelune]

https://omegat.sourceforge.io/manual-snapshot/en/chapter.panes.html#panes.fuzzy.matches

The current manual has the edit screen image. It may be better to improve there.

What improvement do you have in mind ?

[miurahr]

https://omegat.sourceforge.io/manual-snapshot/en/chapter.panes.html#panes.fuzzy.matches
The current manual has the edit screen image. It may be better to improve there.

What improvement do you have in mind ?

@t-cordonnier propose UI change in PR #1224 . He can explain what is difference in the UI improvement.

[miurahr]

https://omegat.sourceforge.io/manual-snapshot/en/chapter.panes.html#panes.fuzzy.matches
The current manual has the edit screen image. It may be better to improve there.

What improvement do you have in mind ?

When you conclude the preference dialog label message in PR #1217 , you can update the corresponding manual section.

[brandelune]

https://omegat.sourceforge.io/manual-snapshot/en/chapter.panes.html#panes.fuzzy.matches
The current manual has the edit screen image. It may be better to improve there.

What improvement do you have in mind ?

@t-cordonnier propose UI change in PR #1224 . He can explain what is difference in the UI improvement.

Ok. I see that we have here a circular reference to @t-cordonnier’s work. :-)

[miurahr]

https://omegat.sourceforge.io/manual-snapshot/en/chapter.panes.html#panes.fuzzy.matches
The current manual has the edit screen image. It may be better to improve there.

What improvement do you have in mind ?

@t-cordonnier propose UI change in PR #1224 . He can explain what is difference in the UI improvement.

Ok. I see that we have here a circular reference to @t-cordonnier’s work. :-)

For your convenience here is a capture of the manual where should be updated.

You can see an example of "<50/50/60% >" part. There will be changed in the serieas of PRs.
It may be impossible to review the #1218 documentation properly without understanding of the proposals for the UI changes.

[miurahr]

Here is also an explanation of the change #1220 (comment)

[brandelune]

Here is also an explanation of the change #1220 (comment)

I replied there. Thank you.

[t-cordonnier]

It may be impossible to review the #1218 documentation properly without understanding of the proposals for the UI changes.

I fully agree with that, that is one reason why I generally encourage you to do a functional test (i.e. not an unit test) to understand what the change does, especially when it is about an UI change which cannot support unit tests...

I also suggest that we do documentation changes and port to older branches only once all the job about the code in master branch is complete. That avoids to do the port/documentation twice in case we change our mind about one topic during the functional tests...

[miurahr]

It may be impossible to review the #1218 documentation properly without understanding of the proposals for the UI changes.

I fully agree with that, that is one reason why I generally encourage you to do a functional test (i.e. not an unit test) to understand what the change does, especially when it is about an UI change which cannot support unit tests...

I also suggest that we do documentation changes and port to older branches only once all the job about the code in master branch is complete. That avoids to do the port/documentation twice in case we change our mind about one topic during the functional tests...

That is why PR #1220 also has updates of acceptance test expectation which check actual UI component contents.

See. https://github.com/omegat-org/omegat/pull/1220/files#diff-7372ede97de3491b9f3d0402b5e3d800b9d9afb7b0fc7fe621dde3b1ebda6a0cR56-R57

[t-cordonnier]

That is why PR #1220 also has updates of acceptance test expectation which check actual UI component contents.

See. https://github.com/omegat-org/omegat/pull/1220/files#diff-7372ede97de3491b9f3d0402b5e3d800b9d9afb7b0fc7fe621dde3b1ebda6a0cR56-R57

Here again you speak about a unit test. This only checks whenever the code behaves as the developer expected.

PR #1224 is more than a piece of code: it is proposal for a new way to present some values to the user. So, I would like to check whenever it behaves as a user would expect. There is no piece of code which you or me can write to check that.

PS. Sorry for the "edit" action, this was not intentional (I clicked on wrong menu) but I did not see how to rollback...

[miurahr]

Here again you speak about a unit test. This only checks whenever the code behaves as the developer expected.

PR #1224 is more than a piece of code: it is proposal for a new way to present some values to the user. So, I would like to check whenever it behaves as a user would expect. There is no piece of code which you or me can write to check that.

Actually, there is no product owner or product manager who write acceptance test cases as the users point of view, the test-acceptance is not acceptance but functional test.
I think there is no good requirement description for the feature enhancement, and a little feedback against the proposal, and many claims after a release in the cycle. Feedback for the UI test case expectation is welcome, but I did not get yet.

@t-cordonnier can you show a role model to produce user expectation and feedback to the UI and functional test case?