This content originally appeared on Level Up Coding - Medium and was authored by Pavel Borzenkov
Localazy is one of the best localization tools for almost any software product. It looks like it will become the next industry standard for localization. Among many other things, it allows developers to outsource translations without giving access to the product’s codebase. The tool itself is very well documented with samples for many use-cases.
This article is not a promotional one — it is just my opinion on the topic after some extensive use.
We used this tool to localize the company’s Web site and both Android and IOS apps. When we started to implement localization all of those were already in production for approx. 2 years and had only one language, which was not English. Some other localization anti-patterns were in use, so we had a very rough starting position.
After a lot of work, our company’s Android and iOS apps use the same Localazy project and we now have good translations for 2 languages and can easily add any other translation if needed. I have to mention that “a lot of work” was required mostly because our Android and iOS apps had many textual differences, and had some localization anti-patterns. If the development was started with Localazy in mind, it could be a lot easier.
One more thing to mention — good support, very professional, very responsive.
I’ve gathered some points that could help future localazy users to avoid lots of mess while localizing a mobile product. All the below is based on my personal experience at the time of writing this — May 2022.
The localazy.json file mentioned in the article is the config file you should create after installing Localazy CLI.
- Read the documentation thoroughly! Sometimes, in case something goes not exactly as you like, your first thought will be “I’ll add a gradle task or bash script to fix that!”. That is not required — Localazy CLI can do anything you need for localization files to be exactly as they should and in the required location too. Just read the docs.
- Test your layouts with “long” languages like German, to ensure that some added translation will not break the app’s layout. Our company’s app was initially made for Hebrew only, and Hebrew is a VERY short language since vowels are generally not written, so many layouts had to be refactored.
- One of the most important — start using Localazy as early as possible in a project lifecycle. That will make your life so much easier!
- Ask all developers to synchronize string keys through both Android and IOS apps, i.e use the same string key for the same texts. This and the next tip will allow you to use the same Localazy project for both Android and IOS apps, which in turn will make translation and testing easier.
- All developers should synchronize the string methods usage. For instance if both Android and IOS developers decide to go for string concatenation everywhere (or string formatting everywhere) — you will be able to use the same Localazy project for both apps. It is quite easy — just add “conversion” section to your localazy.json file. It should be something like this, in case your Localazy project contains IOS strings and you wish to use them as Android strings:
- When using a shared project and for some reason adding an app-specific string always mark its key. E.g. there is an Android app’s text that explains the location usage reason, which is not used in IOS app, add “ao_” in the beginning of the key, like this:
- Localazy uses the “values-he” resource folder for Hebrew in an Android project. Not all Android devices work this way, some devices use “values-iw” for Hebrew translation. As an Android Developer, I tend to use gradle tasks for anything that needs to be copied, erased or modified during the build process, so I’ve added a gradle task to copy “values-he” to “values-iw” to ensure compatibility. Actually that was not needed, since localazy supports writing the same language to more than one folder. I just had to add the following to the “download” section of my project’s localazy.json file.
- When using conversion in order to use the same Localazy project for both Android and IOS apps — note that “conversion” section in your localazy.json file performs downloading too. If you use conversion for Android from an IOS project — your “download” section should be removed, otherwise it will be executed before the conversion. In this case you will end up with both types of files being downloaded into your project, which, in turn, will prevent compilation.
- When creating a new project in the Localazy control panel, it is strongly suggested that the source language should be English. Great idea for any project, but for Android projects the Localazy CLI will put the source English language into the “values_en” folder. This leads to an issue with any untranslated language, since most, if not all, Android devices will look for the “values” folder for default language if no translation is found. “Like a Pro)))” I’ve added a gradle task to copy “values-en” to “values” to ensure compatibility. However, the correct option was to modify the “download” section of my localazy.json file to add a conditional path for the English language. Smth like “conditions”: “equals: ${lang}, en” and then the required path.
- In general, PMs and other management staff prefer using spreadsheets to ask developers to add new texts to the applications. Do not allow them to upload xls files to your working Localazy project directly! Use an empty temporary Localazy project to upload the xls file and then download the file from this project selecting your main project’s file format. Then use the “update file content” option in your main Localazy project to add the content of the file you’ve downloaded from the temporary project.
- Sometimes an Android app consists of several modules and strings.xml files are contained in more than one module. In this case if you try to upload the strings using the Localazy CLI, you will get a ”complex file” entity in Localazy. While still usable, some options will be unavailable. I’ve fixed this issue by merging all my string.xml files by each language and putting them inside one module. You should use the “lowest” module in the project’s “dependency tree” for that, in my case it was the “domain” module. In my case that was the only option, because I’m using the same project for 2 apps. If merging all strings files to a single module is not an option — it’s possible to use the path parameter without changing the file to a complex one and just collect the files including their original location and then restore them to the same location using the pattern in download/conversion. Of course, this becomes a bit complicated when more platforms with different structures are used. However, the path can only contain the module name (it’s possible to filter it using transformations) and output files based on different conditions.
- One feature that I wanted, but had to implement myself was to make any of the unused languages to contain string keys as values. It might be not so obvious why anyone would need this feature, but think of someone who wants to start using the same Localazy project for 2 apps that previously were not synchronized by string keys. Fortunately enough this can be easily done by a bash script.
I’m sure that at the time you are reading this, the Localazy team improved their tool, so read the documentation before implementing paragraphs 7 to 12 in this article.
Localazy localization tool from an Android developer perspective was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Level Up Coding - Medium and was authored by Pavel Borzenkov
Pavel Borzenkov | Sciencx (2022-05-11T11:23:39+00:00) Localazy localization tool from an Android developer perspective. Retrieved from https://www.scien.cx/2022/05/11/localazy-localization-tool-from-an-android-developer-perspective/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.