Proposal: keep non-native translations external

[edusperoni]

This plugin stores all the translations inside the app binaries, which can be a problem if we're trying to add new locales or fix typos via appsync or trying to get theses translations from the internet.

My proposal is the following:

{
  "native": {
    "app.name": "app name",
    "ios.plist.....": "other stuff"
  },
  "mykey": "my translation"
}

These translations are stored in a json inside the app directory. Optionally, we could register our own json. For example: store your translations on the web. When the user opens the app, lazily download them (this is what Facebook does. When you open the app for the first time it stops on a screen saying "please wait while we configure ").

Native translations are still built into the app and can still be accessed by native.app.name, but they can't be updated by appsync or json download.

[farfromrefug]

@edusperoni i am actually interested by this for another reason.
I actually started to think that using native localize for actual app in {N} was slow and unecessary. It requires a JS/C++ bridge on every local call which seems really unecessary.

So i am really liking your idea. Did you try to implement it?

[edusperoni]

I didn't try to implement it but it should be fairly simple:

Before running the native parts of https://github.com/EddyVerbruggen/nativescript-localize/blob/master/src/localize.d.ts#L1

We just have to check if the key starts with native. (or another keyword we decide to use) and if not, load from a json. We also have to ensure the translation json are copied to the apk. Ideally we'd also change the logic that check for changes so it doesn't recompile the app when you change something not on the native part of the json.

[farfromrefug]

yes seems good. About the json being copied i think a simple doc on how to do it with webpack would be enough. Plus it would allow more control. Like myself i think will not "copy" it but move in the actual vendor file.
Which makes me think we should have an option to load "localization" from JSON (which is what i would have to do)