Thanks for your creative, detailed, and quick response!
This is a good workaround that while not ideal, could work in every case except for needing to have the first question being one that would be affected by the trigger. That is not the case with my form but this does bring me back to the original question regarding specifying a dynamic appearance.
You said that it is currently rendered as a static string, what would be required to design this in a way to make it dynamic? Would this be a good feature request?
The main situation I'm working with is designing multilingual forms to be filled out by people literate in French or English, but also making these forms more accessible for nonliterate monolingual farmers who speak a minority language. I say nonliterate to make a distinction that is often not talked about in detail, but literacy is often regarded by literate people as a binary thing, you either know how to read, or you don't, when there are massive gaps between those at the lower end of the spectrum that literally do not know how to use a book (yes those people still exist! This IT support comedy sketch is an exaggeration of rare interactions I've had), to those who can recognize some numbers or letters, to those who can sound out basic words with diligent effort, etc., etc.
I currently use audio and images a lot since any text displayed in the label is mostly irrelevant to a nonliterate person. My main issue here is for select one/multiple questions with regards to how the responses are displayed. For a literate person, it would be easiest to have the default radio buttons displayed vertically (the default) or autocomplete or minimal in some cases. For the illiterate users, I typically use: no-buttons and have audio play when the response image is selected similar to this screenshot:
While doing separate questions with a relevant expression using the selected language as a variable as you and @danbjoseph described, this essentially makes the form n times bigger where n= the # of languages the form uses if you needed different appearances for each language. It would at least double the size of the form in my case and it would also make analysis much more cumbersome.
I hope I'm not coming across as lazy in not wanting to incorporate these workarounds. I think the main thing that is often frustrating for me is that I'm designing workflows for illiterate people who require things to be displayed very simply, preferably w/o text so as not to be overwhelmed/confused. Since these folks are ignored in much of the broader world of tech design, most tools are completely inaccessible to them, which is why I found ODK in the first place! ODK seems to be the best adapted to cater to such a broad diversity of users, including those who are illiterate. I just want to continue to push the boundaries to make it easier/more accessible to those users, but I'm ignorant as to how much work/effort is required to make those structural changes to the underlying foundation.
]
