Add binary fields specifying handshape etymology

[ocrasborn]

• This is separate from the detailed phonological features of the handshapes: we want to have two checkmarks labeled 'number' and 'letter' to specify whether the handshape in this gloss/sign etymologically stems from the number system or the fingerspelling system of the language.
• Create two sets of fields, for both strong hand and weak hand. Proposal for field names: domhndsh_number, domhndsh_letter, subhndsh_number, subhndsh_letter
• Display the checkmarks only in the detail view, not the list view. Please put them both to the right of the handshape choice (create columns?); if that works out, the simple labels 'number' and 'letter' can be used twice.
• (We currently use # before a letter handshape and = before a number handshape as a workaround for these features, but now that we can specify detailed phonological features for handshape, it's time to get rid of this workaround and create something more sensible.)
• See #367
• See #373 , #372 for follow-ups

[susanodd]

Is the etymology belonging to the Handshape or does the etymology vary per Gloss in which the handshape appears? It seems like it is part of the Handshape itself? But it needs to be displayed for both the strong and weak handshapes for the Gloss so the etymology is explicit rather than encoded. I found examples of number handshapes with a = before rather than a %. Should these be figured out by pattern matching? Or just let the new fields be gradually filled in by users?

[ocrasborn]

@susanodd : It's related to the use of handshape X in gloss Y, but not either a constant property of a given handshape nor a property of the gloss as a whole. (The goal is to say that the T handshape stems from the hand alphabet from / represents the T in THEORY, but not in other signs with T; or in other signs, that the handshape 1 represents the number one in FIRST, but not in other signs.) Thanks for noting that the % should be =, I replaced it above, forgot to check before.

[susanodd]

[ocrasborn]

@susanodd , I like the way you solved the alignment of the values with handshape! I made one mistake in planning this though: we'd actually need a tripartite distinction between yes/no/neutral for both. Would it be possible to obtain that with the same binary field, but instead of using checkboxes make a pull-down menu with –/yes/no? Awfully sorry to bring this up only now... my colleagues reminded me.

[susanodd]

Will you need to distinguish between No and Neutral? At the moment, in the database, because Booleans can be Null, there is a difference between False and None. (Like Repeat and Altern are "not shown" if it's not "True". "Not True" is either "Null" or "False".) Do you need to know if it's False or Neutral? Is Neutral like Don't Care? Or is it "Not Filled In"? Can these be the same?

[ocrasborn]

Yes, we need to distinguish No from Neutral. In fact the fields indicate possibility of the phenomenon, so 'yes it's possible', 'no it's not possible', and 'we don't know whether it's possible or not'. The default state is that last one, of course.

[vanlummelhuizen]

@ocrasborn, @susanodd's changes are live now.

[susanodd]

Okay, Version 2 with pull-down menu's has been pushed to the master branch.

[vanlummelhuizen]

@ocrasborn @susanodd this is live now.

[ocrasborn]

oh oh oh, I see now that I was not clear at all and put my comment on the need for more than two options in the wrong issue: the pull-down menus with three "values" were supposed to go with the WD/WP fields; for the letter and number we need the checkboxes. So sorry @susanodd to make this more difficult than need be! Could you please alter it again?