Support for non-contact preferred language

[ericnewcomer]

Need a way to request a language preference.

In RP, we look at Contact language, then Org primary language, then Flow default language. In the new world we are only looking at contact. While this seems like a reasonable simplification, we need to be able to bring current behavior forward.

A RP test when run through goflow that exposes this is: temba.flows.FlowsTest.test_cross_language_import

https://github.com/nyaruka/rapidpro/blob/1474af3e12b6e6a6b268b942541934bcede8f31e/temba/flows/tests.py#L5571

[nicpottier]

Oh so this is a flow with multiple languages, but we want to cascade from contact->org->flow default language when looking up a translation?

[ericnewcomer]

Yup, exactly.

[rowanseymour]

How do we feel about this approach instead - we use org.primary_language as the default for unset contact languages: https://github.com/nyaruka/rapidpro/blob/b14a246e0dcf31adbb70124f0bdf041f1ac4f33a/temba/contacts/models.py#L484-L484

The upside is goflow doesn't have to know about another thing which can have a language - the downside is we can't implement a "clear language action" so easily - but I'm not sure how useful that is anyway (just set it to your org primary language instead) and it's not something we currently support.

Whatever we do here, we'll want to do something similar for org.timezone vs contact.timezone.

[ericnewcomer]

The impetus behind the existing behavior is that flows can have various language support and travel about different accounts which may have different primary languages. Since localization of 100% isn’t required we need reasonable fallbacks. The case we are trying to support is which of the flow’s languages to use if the contact’s primary language is not present, not necessarily just not set.

I do appreciate the simplicity of this suggestion but it’s really not at all the same thing. If we went down this path, to me it’s more appropriate to let the flow dictate backdowns and to remove the concept of a primary org language altogether.

[rowanseymour]

That makes sense - so I guess we need pass something like environment to goflow which has a language (and probably a timezone).

Or make Contact.languages a list? RapidPro would populate it as [contact.language, contact.org.primary_language] but goflow would support an arbitrary list of languages to try. SetLanguageAction would add a language to the start of the list. There's nice flexibility to letting contacts have their own backdown languages.

[ericnewcomer]

Ya, since the engine operates on contacts and knows nothing of orgs, I think it makes sense to put whatever is needed there. A list of languages on contact makes the most sense to me.

[rowanseymour]

Closed via #52