search

huridocs / uwazi

Uwazi is a web-based, open-source solution for building and sharing document collections
http://www.uwazi.io
MIT License
235 stars 79 forks source link

[IX] What is the expected IX behavior on different languages? #7136

Open RafaPolit opened 1 month ago

RafaPolit commented 1 month ago

What is the expected IX behavior on different languages?

For selects and multiselects, IX is clear as to what it should do, as the translations lie within the actual Thesaurus. On text fields like Title or Text, what is the expected behavior of accepting a suggestion? Apparently, current behavior is assigning the same value to ALL languages, potentially destroying the suggestions.

Furthermore, the aggregations are not Language aware. The aggregations are ONE for all languages of the collection.

txau commented 1 month ago

potentially destroying the suggestions

I guess this is actually potentially destroying user values?

The expected behavior is as it working with the regular metadata edition:

current behavior is assigning the same value to ALL languages

This is wrong, and it may be also a product of iteration design. I remember the IX having a confirmation dialog for "Set this value for all languages", but we decided to remove it because it was making the process cumbersome.

There is a flaw tough, title are the same as a "required text property" in the sense entities cannot have an empty title. Since entities are created BEFORE you can have any suggestions, it is going to fall short when it comes to the task of assigning titles or required text field values for new entities. I think this is a more complex scenario that we don't need to account for now. The alternative for this is, as it is working today, you are going to receive suggestions for this type of properties (titles, required text) IF you have a document for that particular language.

Furthermore, the aggregations are not Language aware. The aggregations are ONE for all languages of the collection.

This is not correct. In the table we should have one row per document (not per entity), so the aggregations should reflect these rows and segregate by language. Meaning, if an entity has 3 suggestions (3 rows, 3 documents), the filters need to reflect 3 numbers in whatever categories they belong (match, mismatch, etc).

RafaPolit commented 1 month ago

I guess this is actually potentially destroying user values?

Yes. Values set by user.

This is not correct. In the table we should have one row per document (not per entity), so the aggregations should reflect these rows and segregate by language. Meaning, if an entity has 3 suggestions (3 rows, 3 documents), the filters need to reflect 3 numbers in whatever categories they belong (match, mismatch, etc).

We do have one row per document. But that doesn't mean we have one per language. Documents are not directly a 1-to-1 match with interface languages. So, if I have a collection with EN and SP, and I have three documents, one in EN, one in SP and one in PT... what is the expected behavior of accepting a suggestion in each of the languages? What language should I update if the person accepts the PT suggestion?

txau commented 1 month ago

We do have one row per document. But that doesn't mean we have one per language. Documents are not directly a 1-to-1 match with interface languages. So, if I have a collection with EN and SP, and I have three documents, one in EN, one in SP and one in PT... what is the expected behavior of accepting a suggestion in each of the languages? What language should I update if the person accepts the PT suggestion?

In that case, we shouldn't have suggestions for documents in a language that does not exist in the interface language.

There is another tricky case, if we have more than one document in the same language. This scenario shouldn't happen as per Uwazi design, but as of today, it is doable. I think it is ok to allow IX to have more than one row per language in this case until we fix this on the Uwazi end.