Thanks for all the interesting observations!
So below is a slightly fancied-up laundry-list of relevant data types that have come up so far. (I hope it’s okay that I have re-used and in some cases slightly recast your list above, @Andrew_Harvey!) For several of these, I have tacked on an italicized example from the Lusekelo’s video.
1. Word
- Form Hadza
- Glosses/Translations Kiswahili, English…
- Grammar grammatical features singular/plural; male/female…
- Related words
- Special names (E.g., big / little / young / old specimen, etc.)
- Synonyms or near synonyms Alternate in-language names for the same plant
- Source (Lusekelo’s Linguistic status) Native Hadza word or borrowed from Datooga, Isanzu…
2. Etymology/source words
- Source language Isanzu, Datooga…
- Source form
- Source gloss
- Links [E.g., URL for Datooga documentation project, Tsammalex]
3. Botanical documentation
- Botanical (Linnaean) name
- Image(s) of the plant
- Natural history (what is the plant’s behaviour?, were does it grow?, when does it fruit? etc.)
- Links to botantical reference sources GBIF, Wikipedia, Wikispecies…
4. Ethnobotany
- Uses (= Lusekelo’s Utilities)
- Medicinal How is that medicine made?
- Food Is the plant prepared or cooked in some way? Are there particular recipes that involve the plant?
- In-language taxonomy Does the plant fit into a taxonomic system (or systems) in the language? What features are relevant?
- Description How is it identified or understood by members of the speaker community?
- Cultural connections
- Songs which mention or feature this plant
- Stories, myths, etc which feature the plant
- Location where is the plant found? (could be lots of ethical issues here!)
Look at all this great stuff! And note, crucially, that almost any of these fields might generate documentation outside of the botanical documentation project itself. So for instance, when someone says “Oh yes, there is a story about this plant…”, or “You know, there is a complicated process we use to make this into medicine…” then there is the opportunity to record a narrative. Documentation is all about “tasks” like this. We should design interfaces accordingly.
Thinking about interface design
I think I have linked this article before (it now only survives in the Internet Archive
):
https://web.archive.org/web/20220316141154/https://37signals.com/papers/introtopatterns/
I think it’s a great start in thinking about designing a user interface — very simple and approachable for just about anyone.
Our list above is the “list your bits” part of the 37signals article: we’ve approximated a list of all — okay, most of — the kinds of information that might come up in the task of documentating botanical information.
But a laundry list of data types is only the first step in designing an application — the next suggestion in the article is to consider grouping and prioritization. If you don’t, you end up with this:
Oh I know, just make an input for each field, like this!
Or even worse, a spreadsheet with a million columns that will leave you in a hellscape of eternal scrolling and tabbing. 
So much no. That’s horrible! Starting with the idea that we “just” add a field for every possible datum is a recipe for disaster. Especially if you’re trying to use the thing in the field.
I’m gonna stop because this post is getting too long, but I do want to talk more about interface design for this project… hoping someone is interested 