Modify the ASL CSV export to match the fields actually in use

[ocrasborn]

It now contains the exact same list of fields as NGT, many of which are unused in ASL while others (for phonology) are not included

[Woseseltops]

I looked into this, and it turns out that the fields displayed in the CSV are not dynamically taken from the settings, but are hardcoded into the CSV creation code. Let's fix that more general issue, and then the ASL Signbank problem should solve itself (because then the fields taken for the detail view and the fields taken for the CSV export will use the same source, the settings file).

The fieldnames now hardcoded into the CSV creation code does not 100% match with the fields specified for the Global Signbank, though. The CSV does have these fields extra:

• 'lexCatNotes'
• 'domFlex'
• 'isNew'
• 'dataset'
• 'subhndsh_number'
• 'sense'
• 'iconType'
• 'subhndsh_letter'
• 'wordClass'
• 'domhndsh_number'
• 'domhndsh_letter'
• 'weakdrop'
• 'oriChFlex'
• 'oriChAbd'
• 'rmrks'
• 'weakprop'
• 'idgloss'
• 'inWeb'
• 'StemSN'
• 'domSF'

Which of these can be removed from the Global Signbank CSV, @ocrasborn ?

[ocrasborn]

These we don't use for Global SB:

• 'lexCatNotes' (leftover from Auslan)
• 'oriChFlex' (created for ASL)
• 'oriChAbd' (for ASL)
• 'domSF' (for ASL)
• 'domFlex' (for ASL)
• 'StemSN' (from Auslan)

Not sure about these:

• 'sense' (from Auslan? Something we might want to use in the future in that case)
• 'rmrks' (related to Notes somehow?)
• 'idgloss' (isn't this the old Annotation ID Gloss?)
• 'inWeb' (is this perhaps the checkmark under Publication Status "Publish in dictionary"?)
• 'isNew' (possibly created for ASL; or is this the checkmark under Publication status "Proposed new sign"?)
• 'iconType' (is this Iconic Image under Semantics?)

The letter/number fields and the weakdrop/weakprop fields are fairly recent additions (implemented by @susanodd), so should be specified for Global Signbank (not sure what that means though, to be specified for; is it related to the specific settings for Global vs. ASL?)

[Woseseltops]

not sure what that means though, to be specified for; is it related to the specific settings for Global vs. ASL?

Exactly. Both installations have their own settings files, and (among other things) in these files we specify what gloss fields of the total available set we actually use. I want this system to also decide what fields are in the CSV.

These we don't use for Global SB:

Okay, so these fields will no longer appear in the Global SB CSV then. I see the first 5 indeed specified in the ASL settings files, so these WILL appear there.

from Auslan? Something we might want to use in the future in that case

I think so. The label is 'Sense number', the help text is 'If there is more than one sense of a sign enter a number here, all signs with sense>1 will use the same video as sense=1'. I will also make it so this does no longer appear in any CSV, at least for now.

'idgloss' (isn't this the old Annotation ID Gloss?) 'inWeb' (is this perhaps the checkmark under Publication Status "Publish in dictionary"?) 'isNew' (is this the checkmark under Publication status "Proposed new sign"?)

The first one is what we now call 'Lemma ID Glosss', the others are correct. I will make it so that these fields always appear, specified in the settings file or not.

'iconType' (is this Iconic Image under Semantics?)

No, it's 'type of iconicity', just discovered that the Americans use it.

The letter/number fields and the weakdrop/weakprop fields are fairly recent additions

I'm hesitating what to do with this. Can I add them to the list of 'Global SB' phonology fields, so they will also appear under phonology in the detail view, or do they have some special status?

[ocrasborn]

No special status, they can be added to Global SB phonology fields. I've asked Julie whether the Americans actually want them for ASL (I expect not), will remind her to respond to that.

[Woseseltops]

Okay, the fields that should be in the CSV are now dynamic, it seems to be working for both the Global and the ASL Signbank (made the change on the ASL branch as well).

Remarks:

• Turns out the new phonology fields DO have special status in the sense that should not be in the regular list of fields, but function as columns next to 'Handedness', 'Strong hand' and 'Weak hand'. Fortunately Susan set up the code so that the new fields could safely be added to the list of phonology fields in the settings without appearing in the detail view twice.

• The descriptive labels of these fields are things like 'WD', 'WP', 'letter', 'number', 'letter' and 'number'... not so descriptive at all. This is probably because of their status as a column, but this doesn't look as good in the CSV. A solution could be to give these fields longer labels in models.py , and replace these with shorter versions in the template?

• Speaking about descriptions, we made sure field names in the CSV are not influenced by the translation system... but this is of course a problem for the Americans because we use the interface language 'American English' to rename some fields for them. I guess the best would be to make sure the CSV always uses the installation's main language, instead of always English. Not sure what this will mean for the CSV importing system.

[Woseseltops]

(For completeness, this issue was needed to continue with #195 )

[ocrasborn]

The short labels are indeed for a clean interface of the detail view, but here's some longer ones to use elsewhere:

Field name	Short label	Long label
weakdrop	WD	Weak Drop
weakprop	WP	Weak Prop
domhndsh_letter	letter	Strong hand letter
domhndsh_number	number	Strong hand number
subhndsh_letter	letter	Weak hand letter
subhndsh_number	number	Weak hand number

[Woseseltops]

Haaaa nice convenient tables :P

I think I have it now so that we see the full labels in the CSV but the short ones in the detail view... but I want to recheck tomorrow to really see if I didn't break anything.

[Woseseltops]

I just verified that the fields in the CSV are nicely taken from what's specified in the settings, and this feature didn't break anything... so I'd say the goal of this issue has been achieved. In case the American users want more or less fields in the CSV, we only have edit the settings file.

Agreed this can be closed, @ocrasborn ?