Approach to languages

[robertocarroll]

Distributed approach might be the best one.

• Allow anyone to fork repo
• Have a single file with all translated strings
• If ever need updates to code, sync fork with original repo, https://www.sitepoint.com/quick-tip-sync-your-fork-with-the-original-without-the-cli/

[paulwaitehomeoffice]

Query: do we want dynamic language changes? i.e. will the app have a UI widget letting the user pick their language? Or do we always render it on one language?

[robertocarroll]

It would always be a single language app and there would be multiple instances of it. See email for more details!

[paulwaitehomeoffice]

Oh yes of course, I see.

The forking approach sounds fine, as long as the Amnesty sections are Git/Github-savvy enough to deal with any merge conflicts. An alternative would be to:

1. Name the language file something obviously language-specific, like translations-english.json.
2. Instruct the Amnesty sections to fork it as suggested, but also to copy the translations file for their own language, e.g. translations-brazilian.json.
3. Have a config setting somewhere in the app that points to the language file, and instruct the Amnesty sections to edit that config setting to point to their language file.

That would avoid merge conflicts, but is more complicated than getting the Amnesty sections to edit one file, and so may not be worth it.

[robertocarroll]

I've realised I don't think this approach will work:

• Each app needs approval from Facebook which we only want to do once.
• Suggest back to a centralised, dictionary based approach (as with the map)

[pauldwaite]

Ah yes I see. Wouldn’t each Amnesty section essentially be creating their own Facebook app from their fork of the repo? So wouldn’t they be going through the Facebook app approval process themselves?

(Or does Amnesty central not want to make them do that?)

[robertocarroll]

They've decided to go with a centralised approach with a dictionary file to avoid having to get the app approved for each instance.