Blog

Be warned that this is a technical article but we think it may interest some people here since our users are quite technology-oriented.

When we started Translation.io, we used AngularJS for the most complex parts of the frontend, like the translation interface. AngularJS was great but some things were counterintuitive:

• Why were we forced to use $http.get when we just wanted to keep using $.get?
• Why did we need to execute $apply() or $digest() when some parts of the application were not refreshing automatically?
• Why couldn’t we just use that great jQuery plugin that we loved so much without using that directive someone created to do exactly the same? (and needed to update for each new version of the plugin).

Don’t misunderstand us, using AngularJS was a nice experience and much more enjoyable than a spaghetti code of jQuery bindings and callbacks. But it was also way too big and “enterprise-oriented” for our needs. Our impression was that we needed to be 100% committed to AngularJS to benefit the most from it. We also found it difficult to fragment our code into small logical parts without doing some extra work.

So we gave ReactJS a chance after all the buzz around it. You need to know that ReactJS is not entirely comparable with AngularJS since it has a smaller scope. It’s more a library than a framework. And for us, it’s already a benefit.

Long story short, we loved it so much that we slowly moved all our code from AngularJS to ReactJS. And we have the feeling that our code is much more readable, modular and faster than before. So, starting today, you wouldn’t be able to find any AngularJS code in Translation.io. And our features are exactly the same as before.

We went from “oh no, I need to remember how everything works in this AngularJS god class” to “I know exactly where to put this component to improve this feature”. And that feels great!

Like we said before, YAML is now treated like a first-class citizen, with the same attention to details than GetText. For this reason, we just added a specific filter based on YAML key prefixes.

Using this button, you can open and browse a tree of your YAML key prefixes. You just have to click on a word to filter all the segments starting with this key prefix.

We hope you’ll love this feature!

You know it’s possible to do minimalist copywriting on Translation.io for some time. It means that you can edit the source text of key-value segments.

At that time we chose to empty the translations of a segment when its source text was changed. It was a fair assumption since it is likely that the translation would also change in such a case and we wanted to avoid inconsistencies. This behavior was disappointing for some of our users because sometimes it was just a typo in the source. So we improved the process with the use of tags.

Here is how it works. Every time a source text is changed on a translated segment (on the UI or in your project during a “sync”), translations are kept and are automatically tagged source changed. That tag points out the translation may need adaptation or at least some review.

Just remove the tag once you checked the correctness of the translation.

Our original goal was to make the best translation gem for any Rails application, and one of the biggest requirements was to accept the GetText syntax, and it works quite well!

But we noticed that about half of our customers only use YAML and never even use the GetText syntax. The feedback we got is that we did a good job dealing with YAML keys too. And some people came here just for that feature.

Since we don’t want to annoy YAML users with GetText (the sync is a little bit longer, and some specific files are created in the project), we decided to add a new configuration option.

Starting with the 1.4 version of the gem, you can add config.disable_gettext = true in your translation.rb file to completely disable GetText.

You may be aware that some popular Ruby gems have already been translated in many languages by the community. Their translated YAML files are usually available in a separate public GitHub repository.

We don’t want you to bother translating these gems again, and it’s a real pain to have to add these translations manually into your new projects before initializing them.

That’s why we’ve decided to keep those YAML files up-to-date within our app, and then, whenever you initialize your project, we will pre-translate all the existing keys to your target languages.

We currently support those Ruby gems:

• Rails (locales)
• Devise (locales)
• Spree (locales)
• RailsAdmin (locales)
• will_paginate (locales)
• Kaminari (locales)
• Doorkeeper (locales)
• ActiveAdmin (the locales are stored in the main project so it works out-of-the-box)

If you know any repositories with YAML translations for other gems, please contact us.