From Jane (7 Oct 2026):<\/p>\n
\nThe language question is a bit that way too [see the sex question]. There's one government form that lists more than English, Spanish or other. Do we follow the government form and, for ease of use and display, use Other to open a link which displays the additional languages on the government form? (We provide a list of languages to choose from if they select Other.) If we have to keep languages in the database we need individual data elements for each. In this case they can check all the languages they speak. I can imagine the government is interested in that information and at some point it will be necessary.<\/p>\n<\/blockquote>\n
Charles replied:<\/p>\n
\nGood one. We can shift form data to English and Spanish keys and that leaves it open for adding any other language to all form questions\/answers.<\/p>\n<\/blockquote>\n
What the library has today<\/strong><\/p>\n
\n
- Client Information Sheet: English, Spanish, Other, Unable to Respond (multi-select).<\/li>\n
- STEAR registry (retired from the library): English, Spanish, Vietnamese, Hindi, Korean, Chinese, Other.<\/li>\n<\/ul>\n
Proposed<\/strong><\/p>\n
\n
- Show English and Spanish up front; "Other" opens the full list from the government form.<\/li>\n
- Multiple choice: the client can tick every language they speak.<\/li>\n
- Each language is stored as its own value, so forms that print only English\/Spanish\/Other can still print correctly, and a form with the longer list gets the detail.<\/li>\n<\/ul>\n
To decide<\/strong><\/p>\n
\n
- Which government form is the source of the full list (STEAR, or another)?<\/li>\n
- Do we also need "primary language" separately from "languages spoken"?<\/li>\n<\/ul>\n
Related: sex question issue (same problem of different choice lists across forms).<\/p>\n"}