Giters

Jesway / flutter_translate

Flutter Translate is a fully featured localization / internationalization (i18n) library for Flutter.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Add support for flavour override

neokree opened this issue · comments

commented

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?

commented

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

commented

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).

commented

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.