Did this ever get resolved?
Today I was trying to use an Enketo form on ODK Central that had both English (en) and Portuguese (pt) and which defaulted to Portuguese (pt) using default_language on settings page.
Form defaults to English.
Enketo no longer respects default_language if language names include valid IANA language tag and instead matches the browser language. You can learn more about the new behavior from the Enketo mailing list.
I believe that if you want to guarantee a default language regardless of browser language you can use language names without IANA language tags (e.g. just "Portuguese"). That way, Enketo won't be able to match the browser language and will fall back to the form's default_language.
1 Like
Thanks @LN
I feel like this is cool and annoying in equal measure.
I just checked the new functions (though I don't have a browser in another language) and I think that the behaviour is
language::portuguese (pt), language::english (en) and default language portuguese (pt)
Defaults to browser's language
language::portuguese , language::english and default language portuguese
Defaults to browser's language
language::_portuguese_ , **language::_english_ ** and default language _portuguese_
Defaults to Portuguese on an English browser
Both of the last two get a warning when uploading to ODK central
This XLSForm file can be used, but it has the following possible problems (conversion warnings):
The following language declarations do not contain valid machine-readable codes: english, portuguese. Learn more: http://xlsform.org#multiple-language-support
Please correct the problems and try again. If you are sure these problems can be ignored, click the button to update the Draft anyway:`
but only the last one actually doesn't default to English.
So I think that if you include either portuguese or portuguese (pt) you'll get browser language matching, but if you make it something like _portuguese_ or port etc it defaults to what you tell it.
Hah, yes, I see what you mean. I feel it makes perfect sense in a mass-survey context but doesn't really make sense for enumerator-mediated data collection where it would be much easier to set a form-level default language than to make sure every browser has the correct default language for every enumerator.
It's clear from the behavior table that ignoring a form-defined default was deliberate but I'm not sure why. One idea might be to avoid a case where there's a mismatch between the UI language (button text, tooltips, etc) and the form language. As far as I know the Enketo UI will always use the browser language and there's no way to override that. @martijnr, some background on the reasoning would be appreciated since I've heard others be confused about the behavior and I don't have a great answer.
In Collect, by default, all of the text defined by the app itself is displayed in the language of the device. This can be overridden by settings. There's no attempt to match the form language to the app language, currently. If there's a default language, it's respected and otherwise the first language defined gets used by default. We've talked about possibly using the IANA subtag of the device language if there's no default specified but not about overriding a form design default. What we've heard from data collectors and project leaders is that it's common to have devices in an "official" language such as English and for data collectors to be used to "device text" in that language but to have a need for question text in a local language for conversation with interview subjects. In those kinds of cases, a mismatch between the Collect UI and the form text may feel more like a feature than a problem.
Yes, I believe the arguments were that (1) browser locale should always beat form default, and (2) that displaying a different UI and form language should be avoided as it was assumed to never be desirable.
There is an undocumented way to add a query parameter lang with the IANA tag to override this. I don't have a sample form handy but will add some URLs here later.
Here is the design document. The rules and definitions are at the top.
I wonder whether we could adjust the definition of a default form language. I'm not sure why I defined it like that.... Maybe because of the way it was implemented in Enketo before the language sync feature. Or maybe I thought that pyxform always output a default language even if not defined (but I just checked that's not the case). Anyway, thanks for bringing this up. 
I'm thinking we could perhaps change that definition and treat an explicitly defined default language in XLSForm differently than a multi-language form without a default_language setting. An explicitly defined form default language could beat the browser language. The UI language would be the same language, if available, and otherwise use the current browser language, if available, and otherwise the fallback language (English).
We'll just have to find some time to figure out if I missed something, and then it will have to be implemented.
Do you perhaps see any issues with such a change @Tino_Kreutzer?
1 Like
I love this! This is what I would expect.
If pyxform did always output a default language I'd do exactly what you ended with so your hypothesis that you made that assumption makes a lot of sense.
1 Like
Thanks, yes that's probably it. Sorry about that...
The problem is that there may be (important) ongoing multi-language surveys out there with a default language defined that will change their behavior, so we'll have to be careful. I already updated the scenarios in the spreadsheet above in a new Proposed tab. The actual implementation will be very easy I believe, apart from all the tedious testing.
1 Like
That makes complete sense to me as well. I can't imagine a scenario of ongoing data collection where this would present issues either since it would result in the UI matching the current form language (whereas they would be different in some cases at the moment). It could be a little confusing but (I hope) not disrupting to anyone.
2 Likes
Thanks @martijnr for clarifying this.
I agree that it makes sense that browser language should be matched when default language is not specified, but should be overridden by form specified default language. In my experience, the model of devices being in one language, but forms in another is very common.
2 Likes
lang query param => default language => ui language => first form language?
Makes sense to me.
It feels like if someone wanted to use the browser language they wouldn't have set a default? But you're right that there's a risk without knowing for sure. The only bad case would be someone who wanted to let the browser dictate things and set an explicit default in their form, right? They'd need to update their form to remove the default to get the behavior they want. They could make that change today because it would currently make no difference.
1 Like
Thanks for all your feedback!
I've created an issue here: https://github.com/enketo/enketo-express/issues/246