The Localazy translation platform supports modules, libraries, build types and product flavors including the correct strings prioritizations and overriding.
A module is used for independent app modules; like dynamic feature modules in Android.
A module works like a namespace, and can contain the same paths, files and keys but still keep the translations completely separated from the common strings and other modules.
Also, it has a specific behavior for SDK integrations like our Android library. The module’s strings have precedence over common ones, but only in the given module.
Feel free to use modules whenever you need to translate app that consists of more independent parts.
A library doesn’t work as a namespace. When a string from library has the same path, file name and key as already exist in common strings, it’s not imported.
Simply put: common strings have higher priority than those from libraries.
This is useful when strings from libraries are overriden by app’s strings. It works this way on Android for example.
The great thing about libraries is that strings that would be overriden anyway are not sent for translating (and so you save time and money).
If more libraries share the same keys that don’t exist in the app, the last processed library takes precedence over the previous ones.
For specific situations, you can set allowDuplicateKeys in upload. The path and file name become irrelevant and only the key is used as a string differentiator. It simplifies using libraries. Please note that it’s a global option and you should NOT set it to false under normal circumstances!
Product flavors #️⃣
Product flavors are well-known to Android developers as a way how to generate different app versions from a single codebase.
Typically, product flavors are used for building eg. free and full versions or specific versions for different stores.
You can define more product flavors separated with a space. The supported formats are:
free playstore- A list of product flavors related to the file.
0:free 1:playstore- A prioritized list of product flavors. This format is useful when some product flavor is missing, and the priority still should be correctly handled.
Product flavors work like a namespace, and can contain the same paths, files and keys but still keep the translations completely separated from the common strings and other product flavors.
Build type #️⃣
A build type is generally used to differentiate strings from release, debug, alpha, beta, etc. versions. You can define any string that is meaningful for you.
A build type works like a namespace, and can contain the same paths, files and keys but still keep the translations completely separated from the common strings and other build types.
There are no limits on how you can combine modules, libraries, product flavors and build types.
A combination of those that work as a namespace creates a new separated namespace. So you can have different product flavors in different modules, etc.