Hey,
I was playing a bit with Modules, Flavors, and library stuff as the documentation about it is rather inexistent ^^
I was surprised that on UI side there is no mention that the translation is needed for which Modules, Flavors, and library.
Let’s say I have a key welcome, and 1 other flavors. I’ll end up on Localazy having two keys welcome.
Can’t hurt to mention it somewhere.
Also what can be handy is to be able to affect translators only translations for flavors and stuff…
Hello,
I will need to write better documentation about it :-). This topic is a bit complex.
First, modules, libraries, product flavors & build types are extremely important for our Android Gradle plugin & Android library. With them, we can support any project, including those with dynamic modules and several libraries combined with different product flavors and build types, etc. As we decided to introduce the fully compatible solution, we also need the architecture to support it.
Basically, modules and libraries behave in a very similar way to files. They are mostly used to distinguish between the same paths/files placed inside different modules/libraries. Technically, you don’t need them at all if you provide the information in the path, but they are contained to allow high-level project organization.
Build types are also very similar to files and they may be useful for processing different sets of strings.
Product flavors allow for even more structured project organization as it’s a set of “tags” rather than just a name. This is particularly important for being able to pick the correct string based on the priority.
It’s important to understand that each combination means unique keys, so you can end up having a lot of strings with the same key but placed inside different modules, libraries, etc. It’s up to your code to use your strings correctly. We don’t recommend any particular way how it should work. E.q., our Android library is responsible for using the correct string based on the current flavor, module, etc. And your code needs to do the same. The logic is yours :-).
Anyway, you are right, it’s worth checking how we show this information in UI (@janbilek). We will have a look at it.
Thanks for the explanation! So I guess my only concern is to make it clear enough on UI side that this is for another flavor/library/build/whatever ^^ so translators can have a bit of context and for example put the wrong company name where they should not (in case of white mark app manage by flavors).
Example of “weird” UI for contributors:
Also when editing the key, a different color should be applied to different “files” or “flavor”
