User engagement is a key goal for app marketing. The strongest engagement type is user contribution. One master of that is Waze offering different level of contribution opportunities: Everybody contributes with automatic traffic information running the Waze app. But then users can report different traffic incidents for the community, and on the extreme - users can extend/correct the Waze map.
How an app with static content can still stimulate user contribution. The answer is translation.
On almost all markets – even is US there are significant Spanish community – significant number of users do not speak English, so they cannot use the app with comfort. But there are also people who speak English and roughly 5% of them would be ready to translate the app they are using to contribute to their family, friends or their language community. As with Waze, the contribution opportunity better has to be instant, meaning in the app, on the phone.
Our free localization solution built exactly this way. Integrate an SDK to your app, and on language markets users are offered to translate your app on their phone, in the app environment. Bonus functions are:
[ul]
[li]voting to get translation – market survey based real customer demand
[/li][li]language practice – easily swapping between 2 language versions
[/li][li]machine translations - for easing user contribution
[/li][/ul]
Translation opportunity not just helps to get contributing users and as a result better engagement with your existing local language users – who probably did not understand all parts of your app -, but you will gain new users who neglected your app, just because they did not understand a piece of it.
Hi I think the whole idea of this is sweet. It seems to benefit more to end users then developers. Of course above statement from your post indicate happy users will lead to more users using your app. So to the developer it is that intangible benefits.
Now the steps to get our app into the Nativer Ecosystem. I have a few questions.
Qn 1
In your site (How to integrate Nativer SDK · Transround/NativerSDK Wiki · GitHub), we need to register our app. The screen shot indicates we need to have apps in Google Play so your site can download the graphics etc. Does that mean if our app is not published in Google Play we will not be able to use your Nativer Ecosystem ?
Qn 2
I am not sure of
Configure the Nativer Developer Console.
Register your app and upload resources App Registration
Since using AOP, why do we need to upload resources? What resources is it talking about? Thought using AOP means we no need to put any additional code into our app ?
Qn 3
The use of AspectJ plug and then use the Nativer sdk and jar is listed down step by step is clear. I understand why we need all those steps. But what I want to know why we also need to include Android Support Library v7 library ? With all those requirements, our final apk size is going bigger. This is in addition to apps where we already include ad network jar files. So if we add all in, the final apk size is getting bigger.
Qn 4
Suppose my app translation is contributed by all end-users as you describe in your website, from our developer console can I see their contributions?
Qn 5
Free up to 4000 words per app.
Ask our offer above 4000 words here.
So above is the catch ? We developers are only allowed up to 4000 words per app translation ? So how is per word definition defined ?
E.g
Welcome to app test. <- this line will be counted as 4 words ?
Please correct my questions above as I am still trying to understand this whole translation idea brought forth by your company.
Hi sgh
thanks for the questions and that you called our solution ”Ecoystem”. We didn’t dare so far. I answer your question point by point:
A1:
Having published your app on Google Play is NOT mandatory. You can test and use the service with unpublished apps.
(Of course, you should be aware that translating the apps requires users, the more is the better.)
A2:
We could have done it by AOP, but we’d rather ask explicit consent from the developer to upload the text resources those should be translated.
There is no need to put any extra code into your app, all is done by AOP. // There is one exception: if you want to use the language dimension in your analytics, we provide a simple API. But this is optional.
A3:
You’re right. We will publish three versions of the SDK: V4, V7 and without support library and add some intelligence to our Android Studio plugin to automatically select.
A4:
Yes, you can follow the progress per language. (We do not collect user data, so you will not see individuals)
Furthermore, we provide two ways for Google (or other) Analytics integration:
• One is to see the translation, download etc. progress of your apps.
• The second is to add segmentation to your existing reports and understand user behavior by languages and readiness of the translations.
A5:
We hope it is not a catch: we made a research and found (table below) that 87% of the apps have less than 4000 words. The reason for this limit is to avoid apps not suitable for on-device translation.
