SFLphone translators and package maintainers needed

I’d like to take a minute to tell you about one of the apps I’ve been passionately using. It is probably one of the lesser-known, fly-under-the-radar stealth ninja killer apps that just deserves some serious kudos and some publicity on Planet GNOME.

SFLphone is an open source SIP and IAX2 (Asterisk) VoIP softphone.
Except that this one works. I shit you not.

Developped by the friendly folks of Savoir-faire Linux, it has replaced Twinkle as my softphone for the past two years or so, for the following reasons:

  • It works with Callcentric, and it works (even better?) with Voip.ms, which I plan on switching to
  • It works perfectly with PulseAudio. Yes, I’m dead serious.
  • It has a clean client/daemon separation. Its main user interface is the GTK+ one, but there is also a Qt interface (which I have never tested to be honest). KDE users can be happy too.
  • It can integrate with your multiple Evolution address books to parse your contact’s numbers. That means I can even get it to pull phone numbers from my GMail account (since Evolution has an addressbook provider for it). How cool is that?
  • They have a proper project infrastructure: they have stable/unstable/daily builds through an Ubuntu PPA, they have .deb and .rpm packages, a bug tracker (though I’d prefer Bugzilla or even Launchpad’s bug tracker), a nice website, standard mailing list, etc.
  • They do care about usability (keep in mind that this softphone’s UI requirements are not as simple as you might imagine; it has to be able to handle multiple calls/lines in a “callcenter” environment)
  • The project team are reactive, attentive to feedback, organized, and care about their app (that, or they were scared I would show up at their office in Montréal). You won’t get your issue fixed “first thing tomorrow morning”, but somebody will look into it eventually.

You can’t exactly take those things for granted: I tried multiple times to contact the developer of Twinkle to offer my help for translations, bug reports and user interface design and never got a reply. Its mailing list is a Yahoo group. Its code seems to have been written in German. Its bug tracker is nonexistent and there isn’t even a public version control repository. Plus, half of the buttons are smileys. Enough said.

Translators needed

So, I’ve been asked yesterday to update SFLphone’s Chinese translation. I can type pinyin, but I don’t speak Mandarin well enough. Mom speaks Cantonese but doesn’t type. I’m in the strange situation where I’d love to contribute to the Chinese translation, but would have to print it, scan it and run it through an OCR! Besides, Chinese needs both the traditional and simplified glyphs.

As you can see, I’m not in the best position to do it myself. But I’m sure there are many talented Chinese translators that could do it in the matter of minutes.

Interested in making SFLphone the best international VoIP softphone available to Linux users? Then hurry up and translate it in your native language today!

Downstream package maintainers needed

The developers have told that they would love to have a maintainer for Fedora and other distros. Considering that they already have rpm packages (and even a Yum repository), it might not be very hard to adapt them to the official packaging process. I’ve got “research how you get this thing in Fedora” on my to-do list, but if someone beats me to it or would like to be a package maintainer, please leave a comment.

Of course, patches for anything else that may itch you are welcome.

8 thoughts on “SFLphone translators and package maintainers needed

  1. Thank you so much! How could I’ve missed this. Finally a working VoIP application with call history & address book. I’m so happy right now. :-)

    I’ll try to help with the translations this weekend.

  2. I’ve been trying regularly Ekiga over the years but it never worked reliably (or at all) for me with providers such as freephonie, callcentric, etc. I gave up when I fell in love with sflphone.

    Note that my use case is only SIP providers that have incoming/outgoing calls to the “plain old telephone system”. SIP to SIP calls, for instance, are not sufficient for me.

  3. Ekiga has worked reliably for years for me and has more features than all those softphones mentionned in the article.

    However, it seems to be more or less unmaintained since a few years.

  4. Thank you! Also thanks for the qt-Interface, I as a KDESC user really appreciate it. :)

    I will test it soon.

Comments are closed.