Source Changes and Tags

You know it's possible to do minimalist copywriting on for some time. It means that you can edit the source text of YAML 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 YAML 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.

Source Changes and Tags - Segment Source changes and Tags - History

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

Disable GetText in your Project

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.

Configuration file to ignore GetText

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.

Pre-Translation of Popular Ruby Gems

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.

Pre-translations of rails_admin

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:

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

Tags - Work Better as a Team

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!

Translation Project Statistics

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.