Ahoy mateys,

As planned, our team went to ArrrrCamp 2014 in Ghent for the opening of Translation.io's public beta.

One thing we did not mention, though, is that we were their main sponsor... unintentionally! Indeed, no one else opted for the same level of sponsorship as we did, and we thus became their biggest sponsor. Some of the participants may have thought that we were largely financing the conference.

The organizers graciously gave us the opportunity to present our product during a 5-minute lightning talk scheduled right before one of the wonderful presentations. As stressful as it may be, we were delighted to be able to pitch Translation.io to all 250 participants at once!

Here are the slides we had prepared:

The organizers had also arranged a place for us to display our flyers, roll-up banners, and all our branded gift mugs. Some people seemed interested by our product and very quickly understood the benefit of using GetText (for those who were still to convince).

Full Disclosure

The conversation rate from our presence at ArrrrCamp was not as successful as we had hoped, with only a few new registrations, but we suppose that few developers actually had an urgent need to translate an application right at that moment. Since the feedback we received was very positive, we hope the participants will remember our product when they'll be in need of an efficient way to translate an application.

Ultimately, we believe we have gained "karma" among the community, so we have that going for us, which is nice. What's more, providing support to a conference as cool and fun as ArrrrCamp is already a success in itself. Now we'll have to get back to work on our web marketing strategy. Though not as fun as meeting people at conferences, it's actually a more effective way to reach future beta testers and clients with a much more satisfying conversion rate.

Since August 12th, the service has been in private beta with the people who had signed up and the collaborators they invited.

It has been two very constructive months! We got a lot of great and valuable feedback from 50+ new users around the world, who created 30+ projects.

Your Feedback

The overall feedback is very positive: people love the interface and how easy it is to integrate the gem in an existing app.

Some of them were already using a GetText-based workflow, while others just discovered it. Most projects still use YAML files, but we are happy to see there is a real interest in an easy GetText solution for Rails.

It was interesting to see that many projects use HAML or SLIM. Thanks to our beta-testers, we significantly improved the support of these two markup languages.

Production Use

Some projects have successfuly switched to our solution already, and we are very happy about it!

We would also be glad to help you with the setup of the translation process in your existing app.

What's Next ?

Every user on the private beta will get free access until July 2015 (6 months free).

Today marks the start of the public beta! And every user on the public beta will get free access until April 2015 (3 months free).

The Live Release is scheduled for January 1st.

During the private beta, we asked our users to give us feedback about our application. And one of the feedback was something like :

Your application sounds great, but there’s no chance I’m going to sign up over an unencrypted connection.

And this user was absolutely right. We had planned to configure HTTPS... someday. But your security is important right now!

So, the right thing has been done, and now Translation.io uses HTTPS by default.

This applies to both web pages and API calls.

The good news, for us, is that Google uses HTTPS as a ranking signal with a small indexation boost. So it's a typical win-win situation!

Translating software with branches often leads to nightmares: conflicts on translation files, lost translations, double translations, etc.

Let's say your production branch is master and you are working in a-feature-branch.

With most existing translation syncing tools, if a translation string/key is removed from master, it will also be removed from the translation server. If a-feature-branch still needs it, it would be lost. And so you will have to re-add it, and re-translate it.

Our Solution

With Translation.io, it is a little bit different : translation strings/keys of all branches are kept on the translation server. Some of them are shared because needed by all branches, some others are specific to a given branch.

What About Really Unused keys?

When at some point, you know all features have been merged into the current branch, and you want to remove all keys that are not used in the current branch. Then use the purge operation that will do exactly that.

To purge your project's translations :

rake translation:sync_and_purge

The former operation will do a regular sync plus a removal on the server of all keys that are not present anymore in the branch from where you are running the rake task.

Sometimes it can be very useful to temporarily change the current locale to perform an action and then directly switch back to the original locale. For example you need to deliver an email to a user in its own preferred locale.

Rails I18n ships with the I18n.with_locale method and Translation.io is of course fully compatible with it.

Here is a basic example of usage :

I18n.locale #=> :en

I18n.with_locale(:fr) do
  I18n.locale #=> :fr
end

I18n.locale #=> :en

And a real world example in a mailer :

class UserMailer < ActionMailer::Base
  default from: 'noreply@translation.io'

  def invitation(user)
    I18n.with_locale(user.locale) do
      mail({
        :subject => _("You have been invited"),
        :to      => user.email
      })
    end
  end
end