Crowdsourcing App-Translation with in-app message

illustrations illustrations illustrations illustrations illustrations illustrations illustrations

Crowdsourcing App-Translation with in-app message

Published on Nov 17, 2017 by Christoph Wiesner

Case Study on engaging users to become app translators

Inspired by a mention in a book of a very simple Timer application I started building an Android Timer App on that principle. The first version was published in two Languages (English and German) which i could provide without external help.

Mainscreen of the app — easy setup by just dragging to desired duration

The main screen of the app — easy setup by just dragging to the desired duration

I was already looking for translation possibilities when I started publishing the first version but couldn’t find any free services that offer human translations. I didn’t want to spend money on it as this was just a side project and free for all users. At first, I created a public translation project on and was hoping that random translators would join the project. Unfortunately without promoting the project nobody was joining. Next, I asked a co-worker to help out with a language and soon added the third one. As there where still no other contributors I started again looking for other possibilities of acquiring voluntary translators. Luckily I found a thread in the board where I could acquire three additional translators.

With that, I could offer my app (+ store listings) in 5 Languages which was quite good for a small hobby project. Still, it lacked some major languages like Spanish, Chinese, or Japanese.
I got the idea to get in touch with already existing users in those areas to contribute to a “native” version of the app. As there is no registration required the only way to contact users is via Notifications or In-App messages.

Utilizing Firebase Remote-Config

With the capabilities of Firebase Remote-Config, I had the plan to add an In-App message to acquire volunteers for the missing languages.

Bottom sheet shown on second app start

Bottom sheet shown on the second app start

The first Idea was to define the missing locales in a remote parameter so that I can show the contribution message on devices with those specific languages. Once a contributor is found for a specific locale I simply can remove it from that list and the In-app message won’t show up for that language. This is done without touching the app’s code and there’s no need to redeploy an update in the app store.

Using a Remote Config parameter to trigger the contribution Screen Using a Remote Config parameter to trigger the contribution Screen

When I got to define the parameter in the Firebase console, I realized that it’s even possible to add conditions for the parameter also on a device language level. This made the attribution implementation even simpler. I just can have a flag whether to show the screen or not and alter the condition right in the console.

Adding a condition to a Remote Config parameter

Adding a condition to a Remote Config parameter

With some additional Tracking in place, I started the rollout. I was happy about the decent setup and looking forward to acquiring new Translators in the coming days/weeks.


Within nearly two months now, around 10 new contributors joined the translation project. Two of those finished the translation work and I could already publish those translations along with some other improvements.

With the basic tracking, I added before we can do further analysis on the funnel of contributors.

Here we can again utilize Firebase to create a funnel for those users.

Funnel view in Firebase Analytics Funnel view in Firebase Analytics

The “opt-in”-sheet had a click-rate of 25,6%, which is quite good actually. So 80 users decided to help with the translation.

So why did this 80 users not end up as translators?
In terms of tracking it’s hard to tell as this “opt-in”-Button is redirecting to the public Page of the translation project in the Browser where I can’t track any longer.

If we take a look at the steps the users have to perform until they end up as a contributor there are some flaws.

Currently, the only way people can join a translation project on is to sign up on the public page of the project. Although this public page is a responsive Webpage on a mobile phone it looks like this:

Public page of translation project shown on a mobile Phone Public page of translation project shown on a mobile Phone

I think the first issue here is that there’s a lot of heading on this screen, which will hide the actual list of languages on smaller phones already.
Next big thing is that users have to search for their language on this list. There’s no way of directly opening the Join-Page with a preselected language. Once they selected the proper language they are prompted with a sign-up form.

Sign-up form of translation project

Sign-up form of the translation project

After the sign-up, they need to confirm their e-mail address first before they can actively contribute.

There were also users how could manage to end up in the project (they even verified their account) but then never started the actual translation work.


Overall I’m happy that I could get new translators for my project and could try new capabilities to reach out to users. 
With that system in place, I can always “turn-on” the opt-in screen if I see that certain languages don’t get updated any longer and I would need a new translation contribution for those.

The next step would be to further investigate how I could improve the actual sign-up process in order to ease the experience for the users who are willing to help.