Cleaning up unchecked choices


#1

In a number of our libraries the choices file does not remove a choice after the user as unchecked it or selected a choice that toggles the availability of that choice. For example a user unchecks “Add finite/non-finite FORM feature distinction.” on the Other Features page, but FORM finite/non-finite still shows up in the choices file and therefore is still available in “add a feature” drop downs. Or on the Clausal Modifiers page the user adds a free subordinator morpheme orth and pred and then selects “this strategy does not use a free subordinator morpheme”, which toggles the view of the free subordinator morpheme choices but does not remove theme from the choices file.

What can we do to remove these choices in the file? I’m looking in deffile.py for now, per Olga’s suggestion. If anyone has additional insight into this problem it is appreciated!


Toggling visibility based on radio button
#2

save_choices in deffile.py adds choices to lexicon and morphology, based on choices in lexicon and sentential_negation (if I’m reading that correctly). It might be appropriate to create a method to be called by save_choices that removes choices that are incompatible with others- in my case if the user has selected “this strategy does not use a free subordinator” the method would remove any choices associated with a free subordinator for that strategy.

That wouldn’t resolve the FORM issue though- it’s still not clear to me why that’s being removed, and I suspect my suggestion above is just a band-aid and doesn’t get to the root of the issue.


#3

What I noticed is, if I create a feature on Other Features page, then use this feature on another subpage, then delete it on Other Features but forget to delete it on the other subpage, then it is not guaranteed that the choices file will be correct. This should be caught in validation, and it is on e.g. the Morphotactics subpage. If you use a feature that you deleted there, it will not let you save the choices.

Perhaps this is the problem that we are seeing?

I am not sure, but it does not seem right to me to clean up choices, since this will not be transparent. Suppose the user entered some choices on purpose and then they disappeared without an explanation…


#4

When I looked into intra-page toggling of options for my library I ran into this question as well. Though I don’t have the issue like with FORM, I came down on the interim* strategy of a) it’s ok if the choices file has entries that aren’t used anymore, and b) use validation to make sure the customized grammar will at least load. In the current model cleaning up the choices file also could be confusing to the user, since it’s supposed to(?) be a record of what they entered, whether or not those values have an effect.

*To be clear, I don’t think this is ideal, but digging further into fixing it was too far outside my scope. Ultimately the Right Solution™ will probably be in conjunction with and/or piggybacking on TJ’s work (and the potential migration to a format like YAML/JSON/EDN/whatever) – as part of that evolution the interaction model between the questionnaire and the choices file could probably use a revisit. Not necessarily that it should be different, but we ought to look at it given what we know now, and make sure it’s documented appropriately.


#5

I don’t have a solution to cleaning up the defunct choices, but I might have an opinion on the interaction model between the questionnaire and the choices file. I don’t think it is has to be a literal record of what was entered. Rather, it’s a statement of the specifications that the user has provided for the grammar that they want. If, in the course of providing those specifications, they take an action in the questionnaire that nullifies previously entered info, then I think it makes sense for that nullified info to be removed.