Proposal to support alternate translations.

[PaulRashidi]

This is primarily to start discussions about whether this is the correct structure.

[aaronj1335]

Pros: straightforward logic to falling back to english
Cons: every locale gets all translations

Other tradeoffs? Thoughts?

[aaronj1335]

Also, what's our mechanism for observing the change? Specifically, when you change languages and then go to the checklist, how does that activity know that you've changed?

[PaulRashidi]

This CL is a proposal to change the underlying FirebaseDB schema. Your question about changing languages is more of a client side switch which would then potentially listen and/or select data from this schema differently.

Pros: This initial proposal forces a relationship between the list items and translations by embedding them underneath as overrides. This makes it easier to update the data in the DB because you simply need to insert it underneath the correct element.
Cons: As initially proposed the alternate language data would be embedded underneath the checklist item. This would result in every client loading all of the alternate language translations when querying for a checklist item.

[aaronj1335]

Those tradeoffs make sense, and I think the proposal is the right way to go.

So if we went with this proposal, given that we're just using a ref of all the checklist items in the activity, how would the activity know to use different strings when the user changes the language?

[PaulRashidi]

Client side, the logic needs to look to see whether the user choose a system override in the language screen I'm building. If they did it would load the defaults as well as the override. It would overlay the override values over the default values.

[PaulRashidi]

As discussed, Alt2 allows text overrides at the list level. This prevent clients from having to download all of the languages when using an alternate language.

[aaronj1335]