Translation > Machine translation (tab): Introduce filter, sort, cluster for MT results

[rhofer]

When having multiple projects, multiple components, MT services (beyond weblate) connected and a lot of translation work done, then the machine translation results provided in a translation view is becoming quite overwhelming, literally listing up everything along all services

• Weblate Translation Memory
  • Personal
  • Project
  • Shared
• Weblate (Components)
  • occurrence of same translation within same component listed up several times
  • occurrence of same translation across components listed up several times
• Further MT services
• ...

Giving a translator the option to filter, sort and cluster those results along user specific settings (may some are not adjustable and given by weblate) will improve the overview and increase efficiency.

Criteria for filter, sort and cluster

Collecting the criteria along filtering, sorting and clustering can happen:

Sorting

1. First Order Sorting
   • Quality (Source string match)
   • Translation state (Approved)
2. More Sorting Criteria
   • Service (what service's results to show first, second, third, ...)
   • Component (maybe some components have close relationship, hence it is preferred to show MT results from those components first: itself, second, third, ...)

Clustering

Allow the MT view to collapse / expand, could be a tree type, list type, ...

• default: collapsed

1. Cluster together source string matches of same Quality (e.g. 100%, 77%, etc.) where source string is exactly the same
2. Within same source string match, cluster together same translations (exact match)

Filtering

Allow the user to set individual filters:

• Quality: limit min / max quality (e.g. show only results between 77% and 100%)
• Translation states (if more than approved is shown):
  • Show approved only
  • Show approved and waiting for review
• Services
  • Weblate Translation Memory: Personal (yes/no)
  • Weblate Translation Memory: Project (yes/no)
  • Weblate Translation Memory: Shared (yes/no)
  • Weblate, overall (yes/no)
    • Specific Results Component A (yes/no)
    • Specific Results Component B (yes/no)
    • ...
  • Further machine results, overall (yes/no)
    • Specific machine results google translate (yes/no)
    • Specific machine results DeepL (yes/no)
    • ...

Solution Approach

tbd

[rhofer]

@nijel Just formulated this issue to start discussion. I currently have no final opinion on how much flexibility really needs to be exposed to the user / translator (Criteria). I think, a minimal approach could be Clustering (same stuff collapsed) and Filtering (switch on/off services).

Clustering Example:
Having source "Save" found 100 times, whilst being on de translation, it found 80 times "Save" translated to "Speichern" and 20 times "Save" translated to "Sichern":

• Collapsed view 1: "Save" > "Speichern", nb: 80 times (Copy) (Copy and save)
• Collapsed view 2: "Save" > "Sichern", nb: 20 times (Copy) (Copy and save)

Basic Filter decision:

• Show Weblate Translation Memory results (yes/no)
• Show Weblate results (yes/no)
• ...

[nijel]

I've just implemented clustering in 2a2b7f5.

The scope of filtering needs to be defined - I'm afraid that most user will never touch such setting.

[rhofer]

Many thanks for introducing the clustering!

I totally agree in regards of filtering. This needs a proper definition first, or even better a specification of translator's requirements (upon which I thought, filtering would be needed).

Therefore, I'd try validating first, whether we use the given options (Nearby strings, Neargy keys, Other occurrences, Machine translation, Translation memory, etc.) correctly.

[github-actions]

This issue has been put aside. Currently, it is unclear whether it will ever be implemented as it seems to cover too narrow of a use case or doesn't seem to fit into Weblate. Please try to clarify the use case or consider proposing something more generic to make it useful to more users.