Sometimes you have long texts to translate. Two, three paragraphs or so. Working on such texts in a small textarea might be quite frustrating for the translator.

For that reason we recently added a fullscreen mode that you can toggle with the ESC key.

This mode also has the advantage to let the translator focus on his work and not be distracted by the other features of the translation interface.

Of course in this mode you can still navigate through the segments using the arrows or the usual keyboard shorcuts.

Let's hope this new mode will enhance your translation workflow!

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.