Add multiple language localizations to compose component

[susanm74]

• compose component needs to support multi-language localization (aka translations cont'd)

• add this as a searchable dropdown directly above the chatbox in the compose component that should allow the user to toggle back and forth between languages

• translations dropdown should be hidden for usage such as the contact chat (when the user is sending a one-time text or attachments to a single recipient), and should be displayed for usage such as for broadcasts (when the user is sending text or attachments to multiple recipients, and needs to send the content in potentially multiple languages)

• dropdown should display a list of languages filtered based on the org's languages

• if the user has text and attachments for arabic, but then the org removes arabic from it's list of languages, don’t display the arabic translations in the component, and upon save, remove from the arabic translation from the translations

• extra credit - show which languages content has been translated into vs. not translated via icons on the left side of the dropdown language option

• todo - how to handle incomplete or partially localized attachments:

  • when a user provides text and attachments in one language - all good
  • when a user provides text and attachments in multiple languages - all good
  • when a user provides text in multiple languages (ex. english and spanish) but only provides attachments in one language (ex. english), when we go to save/send the spanish broadcast, do we send:
    • no attachments?
    • the english ones?
    • disallow the user from saving without specifying "spanish" attachments?
    • allow the user to specify how to handle and whether to send the english ones vs none, for any/all other languages for which attachments have not been provided?

---

potentially relevant broadcast discussions:

• Message broadcast improvements rapidpro#4219
• Send broadcast when unlocalized will style recipients floweditor#1140
• Should indicate what expressions can match against for start_session and send_broadcast floweditor#1120
• Typed variables in start_session and send_broadcast actions floweditor#1110

[susanm74]

@ericnewcomer @rowanseymour

[ericnewcomer]

Hey @rowanseymour, @susanm74 is hitting on the oft discussed localized attachment question. I think I know where we landed on this, but I don't want to add confusion if I have it wrong. I'll let you chime in here first.

[susanm74]

@ericnewcomer @rowanseymour just wanted to resolve how we want to handle partially localized attachments (see above) and let me know what attachments translations we should expect to save in this scenario

[rowanseymour]

We want the behaviour to be consistent between sending a broadcast from the UI and sending a broadcast in a flow. Currently this means we resolve each part of message separately - i.e. resolve the text by checking contact language, default org language, flow base language, then resolve the attachments that way, then quick replies.

So for example if we have a flow base language of eng, then the following translations on a broadcast:

{"eng": {"text": "hi"}, "spa": {"quick_replies": ["si", "no"], "ara": {"attachments": ["http://test.jpg"]}}}

will be resolved for contacts with these languages as follows:

"eng" => {"text": "hi", "attachments": [], "quick_replies": []}, 
"spa" => {"text": "hi", "attachments": [], "quick_replies": ["si", "no"]}}
"ara" => {"text": "hi", "attachments": ["http://test.jpg"], "quick_replies": []}}

That resolving currently happens in goflow/mailroom * and I think that's where it should stay. So the UI saves translations in their "sparse" format, and mailroom resolves what we actually send to a given contact.

• Currently broadcasts created in a flow are resolved by goflow and queued for handling in their resolved form, whereas broadcasts created by the API are saved/queued in their sparse form and resolved at the point of sending... the same applies to when expressions are evaluated and I don't love this being slightly different.