We have a similar use case. We are wanting to re-implement a SurveyCTO plugin as an external app, and it would be great if the external app could parse the form definition to get the choice list, question prompt, etc. - all metadata required to mimic the question information that SurveyCTO sends its plugins. We're hitting dead ends with XPath queries "within" ODK and even if we succeed, relaying that app to app is gnarly.
For getting choice lists to your external app, would using a string join meet your needs?
Here is a sample form demonstrating the idea. You can see first joining all the available choice values and corresponding labels and then dynamically filtering down the list. If you try the form, keep in mind that string comparison is string-sensitive and that all labels are lower-case!
This will only work with single-language forms. If you need the same concept with a multi-language form, I would recommend introducing an explicit column to use as the label sent to the app if you can.
1 Like
Here is a quick proof of concept of an approach for multi-language form.
It's not great! It involves using a select with labels that represent the different available languages to detect the current language. A better way to know the current language has been requested here. An additional thing to add that would make this easier is a way to pass in a language to the existing jr:itext function which currently can only look up a label in the current language.
You'll notice that as the form is written, you need to swipe before you can see the language correctly detected. This is related to some issues with recomputation that @TobiasMcNulty described here. That thread provides some ideas on how to work around that for now.
The approach bypasses the built-in translation mechanism and instead involves introducing known column names to the choice list representing the different languages' labels.
Side note, @eyelidlessness here are some user-facing issues with the itext spec.