Provide localized Strings

[ichinaski]

As Akvo FLOW runs on many devices in many countries, I suggest to include localized strings, which is easily achieved in Android.

This way, the same application will be displayed in different languages depending on the user's preferences.

Which could be important languages to to displayed?

[joycarpediem]

https://github.com/akvo/akvo-flow/issues/270 I think we should create a new label for localization

[caetie]

Nice work on this. I would suggest in a next/future iteration, you build a way for the device user to set the display language manually as well in preferences.

[ichinaski]

I've managed to include a language selector within the application, under Settings > Preferences.

I would also suggest the usage of a single language to display survey translations as well (using the same preference). This way, the application will try to get the translation for the desired language, otherwise just display the default one (English). I think this is a simpler UX, and easier to configure by the user.

[mtwestra]

from email exchange with @ichinaski: Features:

• Single language for the whole app (UI + survey translations)
• By default (the first boot), the app configures its language matching the device locale. If both are compatible, we use it. Otherwise fall back to English.
• To change it: Settings > Preferences > Language
• If the app UI (buttons, instructions, settings, menus, ...) has been translated into that language, the whole UI is displayed in that language. Otherwise, English will be used.
• If a survey contains translations into the selected language, the questions will be displayed in that language. Otherwise, the default survey language will be used.
• The device and the app can have different languages (i.e. different languages for project managers and enumerators).
• If a mandatory question has to be highlighted, its text is set to red (on top of black), which fixes Issue #25 - https://github.com/akvo/akvo-flow-mobile/issues/25 (you can force this situation by going to the submit tab w/o responding a mandatory question and going back again)

Demo:

• Akvoflowsandbox.
• I have prepared a survey translated into English (default), Spanish, and French. Its name is "Locales Test (en/es/fr) and the survey ID is: 2468006
• Install that survey manually: Settings > Download Survey -> Introduce the authorization code and survey ID.
• The apk contains UI translations into English (default) and Spanish.
• If your device's locale is English or Spanish (this can be customized in your devices settings), the app will automatically configure that as its language. Otherwise, English will be the language.
• Within the app, you can customize the language as indicated above.
• If set to English or Spanish, everything will be translated into that language (because both the UI and the survey contain translations).
• If set to French, the UI will be displayed in English (no UI translation, default used), but the survey will be displayed in French (the survey is translated into French)
• If set to any other language, English will be used for both the default UI language (default) and the survey language (this default language could be changed in the survey configuration).

Next Steps:

• The survey configuration allows Survey Title and Question Group translations, but that is not reflected in the survey definition the device reads. Once included, we could display the translation of these texts as well.
• The UI translations are +200 texts, that's why I have only translated it into Spanish. We could translate the app into any language used for FLOW surveys.

[mtwestra]

@ichinaski, comments: 1) I tested the app but the test survey keeps showing up in English. I completely removed the app from my device and reinstalled it, but that didn't help. 2) The option 'language' in the preferences now shows all the possible languages, which does not make much sense. It is also not very clear what that option does. I think this is the language of the app, right? It should only show the options that are really there. We could change the name to 'app language' perhaps? there probably is a better name. 3) When I choose the locale of my phone, I have lots of options for the same language. For example, American English, British English, etc. Is this handled correctly in the phone, i.e., do they all count as 'EN'?

[mtwestra]

@ichinaski, I think the present implementation is confusion, mainly for the reason that we are trying to treat the UI translations and the survey translations as more or less the same thing. However, there are big differences: we will support far fewer UI translation languages then the languages people will use for surveys. In the preferences, the 'langauge' list now has two problems: 1) it is too long, and gives no indication to which languages are 'available' 2) it is not clear what it does My proposal would be this: 1) the 'language' setting in the preferences refers to the UI language, with only the ones that are available displayed 2) when displaying a survey, we see if there is a translation in the UI language. If there is, we use that. If not, we default to the main language of the survey. 3) the menu that is available when displaying a survey has the 'languages' option (as now), where you can turn on and off languages that are available.

[ichinaski]

IMO, the purpose of having a single language for both the UI and the survey translations is the ability of avoiding technical distinctions from the user point of view. He just introduces his preferred language, and the application does its best to match it in as many scenarios as possible. The majority of the remaining cases will be properly handled by the default survey languages, which precisely will be the ones meant to target those users. Of course this does not cover the 100% of the cases, but it does provide a general purpose solution, I think, simplifying the configuration of the app. Note that the current FLOW release only has survey translations, thus no distinction has to be made when talking about Language.

I agree, though, that the setting in the preferences is not clear enough. At the moment it displays the whole list of languages in order to allow options that might appear in the survey translations but not in the UI.

Anyway, if two different settings have to be configured, I think your suggestion is fine, the only drawback is that in the survey display, the UI language will always have preference over the survey default language.

Note also that technically, the survey does not have translations. Questions do. Hence no language can be selected per survey, because we cannot assume that every question will have translations for every language we encounter in the survey. The current approach to handle that, displaying all the languages one after another, is a bit overwhelming.

TL;TD: We have no silver bullet for this problem.

[henryjewell]

@ichinaski I agree with Mark on his main point - there needs to be differentiation between the UI language and the Survey language.

A user who selects French under settings is going to expect the UI in French and if it is not available then nothing happens. This will confuse a user. Under settings, language should refer to 'App Master Language' and only list available translations

A user might want the UI in one language and the survey in another, i.e. the UI in Spanish and survey in Quechua. This will mainly be an issue when an enumerator is conducting a survey in a language other than his first language. As we support a vastly different amount of languages in the UI (two) and surveys (nearly unlimited), this will lead to support issues.

Keep 'language' button inside survey but I would tend to limit being able to select to just one language (two maximum) and the user can switch back and forth. Too many languages will be confusing

[mtwestra]

@henryjewell, @ichinaski: Listening to this, I would propose this: 1) have a 'app master language' in the preferences, which shows the available UI translations 2) when the app is started for the first time, it tries to match the selected language to the device Locale. If this is not possible, it chooses english by default

On the surveys, I see a few options: 1) by default, a survey displays its master language, and the user can turn on other translations using the context menu 2) by default a survey displays its master language and all other available translations (usually only 1), and the user can turn off translations using the context menu 3) by default, a survey tries to match a translation to the UI language, and if that fails, it uses the master language

I think there is something to be said about showing all translations at first, so the user is aware of their existence. We could even point out the possibility to turn off translations in a popup, one time, with a 'don't show this again' button.

Also, at some point we might want to consider some use of icons on a survey, to show that there are other languages available.

[ichinaski]

I see the benefits of an explicit separation of both settings. I just think the solution of displaying everything at the same time to cover every single case complicates the UI by default. Like using a sledgehammer to crack a nut. Not that I think my approach fixed this issue, though.

Anyway, even though I'm not convinced about it, I'm outnumbered in my opinion, so let's go for it :smirk:

Given that, I think your option 1) - by default, a survey displays its master language, and the user can turn on other translations using the context menu is the most appropriate one. 2) it's definitely overwhelming, and 3) removes the priority of the survey master/default language in favor of the UI one (UI language has fewer options, thus creates a big constraint in this approach).

[mtwestra]

@ichinaski, I think you're right about showing everything being overkill, so it looks like option one should be ok then. Let's wait for @henryjewell's opinion, and then decide.

[henryjewell]

I agree that option one looks the best course of action.

[joycarpediem]

SNV Laos wants to use our app in Lao. They are willing to provide the translations for the app literals. We have sent them the strings.xml files along with instructions about which literals to translate. They are aware that this is a experimental collaborative approach and even though Akvo and SNV Laos is investing effort into this,there are chances that is may not work out. Any potential issues uncovered will not be a priority for Akvo to fix.