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:

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).

GnuCash for Android has been developed with the goals of simplicity, usability and broad compatibility. In order to apply modern Android Design guidelines for the user experience of the app while maintaining broad compatibility, I am using the ActionBarSherlock library. This meant that I had to download the library and include it in my project, as well as distribute it with the source code to allow others to quickly checkout and build the code.

This has become cumbersome in a couple of ways.

In order for Eclipse to properly find references to Android library projects, they need to also be imported into the workspace. The idea of distributing the library with the GnuCash for Android source code bugs me.

Updating the library project becomes a burden. Every time it updates, I need to download the source, replace the old source code, import it into Eclipse and then make a large commit for the library source into version control.

GnuCash for Android also uses Robotium for testing. Admittedly it is just one jar file, but has to also be distributed with the source and updating is also cumbersome.

There are other libraries which I may use in the future like Roboguice and others which will really inflate the size of the source code with dependencies.

The status quo is not sustainable and there has to be a better way. Enter Maven, the build project management tool which also manages dependencies. I had introduced Maven build support to the GnuCash for Android project some while ago, but due to the Eclipse requirement for importing apklibs, I still had to distribute the ABS library with the project.

Well, now I am going all-in with Maven and removing support for IDE-specific project files. You can always import the code into Eclipse as a maven project it should setup everything right. This is also mostly a painless switch for me because I am now using IntelliJ IDEA 12 going forward. It has one feature which I really appreciate, and that is downloading any Android library dependencies, importing and properly referencing them.

If you are using Eclipse, then you would need to download the apklib dependencies (ActionBarSherlock) and import into your workspace and also properly reference the library project. Eclipse maven plugins should be able to handle the other dependencies just fine.

So it has been a while since the last post, and that’s because I have been working on this awesome new release of the GnuCash companion app for Android. Today I am announcing version 1.1.1 which fixes a bunch of bugs and adds support for double entry accounting. (If you’re wondering if you missed version 1.1.0, don’t fret, you didn’t)

Double-entry accounting basically allows you to make every transaction a transfer from one account to another. So for example every time you Expenses account goes up, your Income account goes down by the same amount. See the GnuCash double-entry accounting tutorial for more detail.

However, after implementing the feature, I learned that OFX does not support double-entry accounting. GnuCash for desktop will treat a double-entry transaction as two separate transactions during import. We will have to find a more permanent solution for this. So for now, unfortunately, if you use double-entry accounting there will be no way for you to import the double-entry transactions into GnuCash for desktop.

The other feature of note is that the OFX files are now exported in the SGML format by default. This allows GnuCash for desktop to properly detect the encoding of the files and non-latin characters. If you are importing to some other program than GnuCash for desktop, then you need to go to Settings and set it to export using properly formatted XML headers.

Those are the main features in this release. There are other changes which you can view in the CHANGELOG. There is a lot more features coming down the road, so stay tuned.