In order to widen the reach of your app, it is necessary to localize it.This increases the desirability of the app with non-native speakers of your language.
Android comes with a resource framework which eases localization of strings in your application. Basically you provide a string resource file for each language with the strings represented by keys. Then in your code, you simply load the string by its key and Android takes care of using the correct string, based on the user’s device locale settings.
When you support only a few locales, it is ok to email the strings file back and forth for translation. However, as the number of supported locales grows, the emailing becomes more of a burden. Here I present some things I’ve learned through managing the 8+ different translations in Gnucash for Android.
Firstly, not all strings.xml files are created equal. Normally in your app, there are not only user interface strings, but also strings for many other non-user facing things like preference keys. These only need to be in the default res/values/strings.xml file since they are not meant to be translated. Android will still find the default strings irrespective of the user locale.
Doing this will also ease the work for your translators since they can simply translate everything in their strings.xml file without having to decide each time if it is a user-interface string or not.
Secondly, if your translators are developers themselves, then it is usually easy for them to send pull requests with translations. However, most of the time, the translators are just normal users of your app who are willing to help.
Asking them to clone/edit/push is a bit too much to ask. If your code is on GitHub, then you can easily have them issue pull requests without having to learn Git. You can do so as follows:
- Create the folder for the resource file and copy the strings.xml to the folder e.g. res/values-de/strings.xml for German (de) translations.
- Ask your translators to create a GitHub account and log in.
- Point your translators to the file which needs to be translated. Each language will have a slightly different link based on the locale code. For example, the German locale: https://github.com/codinguser/gnucash-android/blob/develop/app/res/values-de/strings.xml
- If they are logged in, they should be able to see an “Edit” button at the top of the file. They can click this and then directly translate the strings in the browser.
- When done, they can enter a description of their changes and click “Propose File Change” and the UI for creating a pull request comes up.
Then they click on “Send pull request” and you get the changes as a pull request which you can merge easily.
Your translators have basically accomplished cloning your project, creating a branch, editing and committing their changes, push their changes back upstream and issue a pull request. All without having to learn Git or opening a terminal. Usually there should be no conflicts in the merge since string translation usually comes after feature freeze.
There are some who decry the fact that GitHub basically wraps Git in such a way that it is unidentifiable. But I think there is an argument to be made for those who want to contribute to projects without having to learn technical nitty-gritty details (such as navigating the maze that is Git documentation).