We’re proud to announce that, starting today, you’ll be able to tag segments directly in the translation interface.

We did our best to make tagging painless without cluttering the screen with lots of irrelevant visual information. The only difference is the small “+” on the bottom-left corner of the selected segment.

To add or remove a tag, it’s really easy:

Translation tags 1

And, cherry on the cake, you will be able to filter your projects using these tags:

Translation tags 1

This feature will allow you to work seamlessly as a team on your translation projects. We hope you’ll like it!

If you work with external translators, they probably ask you for details about the amount of work. They need this information in order to give you a quote.

On the projects list there already are counts of segments/keys left per target language. But, in reality, most professional translators base their pricing on the number of words to translate.

You can now get this information directly on using the contextual menu of each project:

Context menu

A window looking like this will show up:

Project statistics: word count

Here you have the total number of words at the top and, for each target language, a computation of the number of words left to be translated.

We’ve added a feature that we find very useful: you can now view and access the history of all your translation projects.

The history is displayed as an activity feed; it shows which changes have been made by which collaborator and, of course, when they were made. Any comments on segments and any source editions are also included in the feed.

For each change made to the translation, you get a colored diff to easily compare the segments “before” and “after” the change.

Translation history of direct-invoice

You can now access the history in two ways:

  • In the list of projects, via the dropdown link named “History”.
  • At the top of the translation page (next to the list of collaborators).

We will improve this history in the future, for instance with a notification zone where you will be able to see the work of your team in real-time.

At, we believe that simplicity and user-friendliness are essential criteria when designing interfaces and we always make a point of keeping the amount of information and features on screen as low as possible.

Along these lines, we had initially opted to give all collaborators on a project the same role and accesses (except for the owner, of course): any collaborator had access to any language and was allowed to edit anything, including the source YAML segments.

This strategy works well for small teams but quickly becomes problematic for larger teams dealing with over 20 languages and subcontracting translations to “strangers”, as is often the case in practice.

That’s why we have now decided to define specific roles for each task. By default, the roles and accesses will remain the same as before, but you will now be able to easily change the role of any collaborator in just a few clicks.

Collaborators Management

The specific roles are the following:

  • Manager:
    • Access to team management.
    • Access to all languages.
    • Access to copywriting.
  • Translator:
    • Access to all languages.
  • Translator for 1 language:
    • Access to a given language.

We have adapted the interface so that you can now change the different roles without making it more complex for those who don’t need to change anything.

You are probably used to having a before_action somewhere in your controller hierarchy to set the current locale (I18n.locale) based on a value from the URL, the session, a cookie, etc.

The translation gem ships with a generic implementation that can be called directly in your ApplicationController:

before_action :set_locale

But, if you need a custom behaviour, you can of course continue to use your own method by redefining it. For instance:

before_action :set_locale

def set_locale
  I18n.locale = # custom logic to get the locale code

Another common use case is to let registered users set their preferred locale in their profile (saved in the database).

Here is what it might look like in such a case:

before_action :set_locale

def set_locale
  if current_user
    I18n.locale = current_user.locale || I18n.default_locale