Open gregorydimitriadis opened 2 years ago
Added to Severe milestone on zoom call with Chuck 2022-09-29
Not sure I understand this. We do not need to label "onset" "offset" etc. Is this currently done ?? I don't recall having seen this.
This is more of a collection validation issue - where we saw inconsistency in when those labels were displayed in the application vs. how they were saved in the file. I need to check back on a specific collection with this issue, but that was my understanding.
Also to clarify, we started this "Severe" milestone for those we still consider severe, and may/may not return to after the next release, but the other milestone - the main Todo one - will still be targeting for that release.
Ok, thanks. At least in SignStream 3.3.5, the labels were displayed when the cursor is over the item, e.g.
We definitely want that to be displayed as in 3.3.5. Seems to work the same in the new version.
How that gets represented in the file is a different question, of course.
Labels (also sometimes referred to in the app and code as Names) inconsistently exist in collection files as values to attributes are as text within an element. This is also across global and local schema files as well as collection files.
It's unclear depending on what data is set in a file as to what value is displayed and reversely when a value is displayed as to what value is set in which file and where. As such unpredictable behaviors may happen.
This issue states to...
Define a consistent expected behavior. Autocorrect existing files (collect, local, global) to this behavior. Correct the application to follow this behavior.
Fix label usage in non-manual fields (and others....onset,offset,etc...sign types maybe...but not gloss, freetext, others). Sometime included, sometime not....not consistent.
autocorrection and in application