@fredhersch could I get access to the mock up linked above so that I can implement the language switcher?

@ndegwamartin Martin, what would be better is if you could add a drawer to the demo app and have the language option in there. Similar to the COVAX demo app that was shared yesterday. Let me know if this doesn't make sense.

Can you make the list of languages a config option too

@ndegwamartin Martin, what would be better is if you could add a drawer to the demo app and have the language option in there. Similar to the COVAX demo app that was shared yesterday. Let me know if this doesn't make sense.

Can you make the list of languages a config option too

@fredhersch yeah I think we can go with the drawer approach.

For the configuration of the list of languages, what did you have in mind?

@ndegwamartin re: configuration - I was just thinking it would be based on an input file (like the strings.xml) with options for the languages being supported

@fredhersch got you. We can have an array with language codes (Case insensitive) e.g.

<string-array name="languages">
   <item>en</item>
   <item>sw</item>
   <item>fr</item>
</string-array>

This will work for any valid language tags that conform to the IETF BCP 47 standard (same as HL7 FHIR) e.g. en-US .
The UI can then automatically display the full name e.g. English (United States)

Discussed with @fredhersch @f-odhiambo and @ndegwamartin. Multiple language translation is a feature the data capture library already supports: if the questionnaire resource has translation information, namely questions and text fields have the FHIR translation extension, they will be displayed if the language matches the system language. For example if a questionnaire is in English and French, if your phone system language is english, we'll display english, if your phone system language is french, we'll display french.

However, language switching functionality within the application (i.e. providing a UI to do it) is a different thing. As @ndegwamartin has demonstrated here, the implementation is not without complexity (also see https://proandroiddev.com/change-language-programmatically-at-runtime-on-android-5e6bc15c758 and other blogposts). What the implementation does is essentially changing the underlying context and setting the locale, so that the data capture library renders the questionnaire in a different language context.

This does not demonstrate any new functionality of the library. It's demonstrating how we can change language in an android app, which is very useful, but not what the data capture library does. As a result, I feel this feature should live in the appication (or fhir core), but not in the demo app for the data capture library.

This PR is still valuable and anyone wishing to implement something like this can use thsi code, but it's not something we'll be maintaining in the data capture gallary app.

I hope this sounds reasonable to all, and as a result I'll close this issue - but please do feel free to reopen the discussion. Thanks!