We dedicated this month’s content to Android users, creators, and fans and we did it so the impressive number of 88% of world audience could go global.
Because we are also passionate about data, we always want to go a step further. That’s why we reached out to an impressive number of 150 Android agencies around the world to ask them one, fundamental important question. Thanks to their answers, we were able to create Android localization reports that you see below. The question was…
How Do You Handle Android Localization?
We got answers from diverse crowds developing Android apps here, all of them coming from different backgrounds, different industries – Android gaming, marketing guys, travel apps… And this is what we found out!
The ICU4J library makes it possible to perform a wide variety of text conversions from one format to another as transliterator objects are used to perform these conversions.
Some of many advantages of using ICU4J include:
- handling text in any language or combination of languages
- the code can be written so that the program can work for many locales
- flexible text/script transformation
- ICU4J and Java both use caches to limit impact, making Collation performance many times faster.
According to our survey, less than 20% of fresh out-of-devs-hands Android apps use ICU4J Android Framework APIs.
Even though this solution allows for potentially lighter and faster apps as they call for resources when needed instead of pre-compiling all of them in one go. WHY?
Customized Android Workflows
The leading Android SDKs, like Android Studio and Eclipse, already have powerful l10n and i18n support out of the box. Eclipse can even externalize component strings, create and manage resource bundles for multiple languages, switch locales on the fly, and edit translated strings in context, which suites most of the developers need for a localized app.
Guess what? Less than 5% of Android devs are customizing workflows of Android l10n to suit their specific needs. This basically means that the out-of-the-box configuration Android SDK provides should be sufficient to use.
Other Important Android localization reports
The numbers have shown that also up to 33% of Android agencies rely on GitHub for code versioning and the dominating system is BitBucket.
Most importantly there is not even a single, standardized method of accessing and editing resource strings! The majority agreed that they load them into an IDE or use 3rd party l10n plugin, but there are still folks, who edit them by hand in text editors. This, on the other hand, shows that over half of Android agencies are not benefiting from TMS, TM, and Continuous Translation which could greatly impact their efficiency.
It also turns out, that putting extreme cases aside, a great majority of Android Agencies automatically load the translated language version based on the geolocation of their users.
When we asked ‘What would make your International development stack better?’ the answers were all about consistent terminology, a better quality of translation, and continuous language version monitoring.