At this point we have the solution fully working. Nonetheless we can think about some improvements to make the system more powerful and automatise some processes.
Improvements
Continuous Integration
From the developer point of view, strings are generated at compile time, but they have to be included manually by them. It would be nice if the strings were automatically added to the code whenever the .po file is edited (manually or through Weblate).
So, we can take a disruptive point of view in which the .xml and .strings files are just “generated files” as the ones found under the build folder. Hence, we can omit them from the Version Control System. For Git, it means to add them to the git ignore file. This way we have to rely on Continuous Integration, which should build the strings at compile time so that any generated artifact includes the latest strings.
Tests
I strongly encourage you to do tests for the solution. As easy as having a test entry file and different expected outputs (for .xml and .strings) so that any change in the script is validated by running those texts. For instance, we have a pre-push git hook to run the tests just before a developer push the changes in the repository.
Since we deal with multiple clients, this way we prevent the framework to be broken.
Versioning
It is highly convenient to have it versioned. It makes easy to export the framework “as a library” for other teams to work or even debug any possible issue that may arise. My recommendation is to go for Semantic versioning.
Consistency checks
It is easy to forget the other languages at the time you want a new string in your language. That is why we think it is good idea to have a pre-commit hook in the .po repository that looks for inconsistencies and do not let you merge is something is wrong. In that consistency script just make sure that, for any string ID in a given file, it has its equivalent translation in the rest of the files.
Not used strings
As time goes by it is inevitable that unused strings gather in the .po repository so, instead of manually look for unused string, it is quite helpful if you create a script that does this for you.
This script might be run once every few months to tidy up the .po repository and make sure we do not store strings that are not used by any of the platforms.
Conclusions
On the one hand is fair to say that this has been a tough work with a lot of up and downs during the process.
On the other hand I have to say that it totally worth it. We raised the string management to another level. Now we work with them in a more industrialised way, being much more scalable, empowering the Products Manager in the team and spending much less time on it.
Do not be aware to give the step forward, it is a very time consuming task but its benefits totally outweigh its drawbacks.
If you have any doubts do not hesitate to ask me in the comments, I will be pleased to help you. I really hope you enjoyed reading this articles and I have the strong wish to have helped many of you to deal with strings in a multi platform project.
