Add support for flavour override

[neokree]

Hi,

In Android, when a project have multiple flavours, the system will bundle toghether all strings, based on the current build.
So with this configuration:

• dev/res/values/strings.xml
• main/res/values/strings.xml
• prod/res/values/strings.xml

If I compile the dev flavour, the strings usable are the ones from main + dev.
If there is a string called app_name in main, and it is also present in dev, then the dev one overrides the main one.

I would like to have a similar feature for flutter_translate. Even if there is not the concept of flavours for dart code, the same thing can be recreated using environment variables or something similar.

I think that something like: delegate.loadFlavour('dev') could do the trick.
maybe with something like this in the asset folder:

• /assets/i18n/en.json
• /assets/i18n/dev/en.json

What do you think?

[bratan]

Hi @neokree, can you give me an example on why you would use different localized strings for the same language?

[neokree]

Sure. My current use case is a "whitelabel" app, that must be compiled for different clients.
The problem is that a section for a client must be called "A", while the other one wants to call it "B".

This is a very specific case, but I can also see other use cases for this feature:

• FREE/PRO app. The same text in a page can change based on the flavour on which is compiled (like the splash screen, or an intro text)
• Development environments (DEV/QA/PROD). The text that declares the environment itself, for example

Obviously in all these situation you can handle it in code using if/else and adding all versions of the same translation in the same file, using either a prefix/suffix or an object group.
However, these solutions increase the number of translations in the localization file, which can become a problem for medium/large apps, and also needs to use additional code in the usage part (the if/else checks for each type of build config).

[bratan]

Thanks for the example and explanation.

It seems this feature might be helpful in some very specific cases.

I will not be implementing it at the moment though, but feel free to submit a pull request if you wish.