Source Changes and Tags
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 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.
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.
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.
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)
- 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.
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:
And, cherry on the cake, you will be able to filter your projects using these tags:
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 Translation.io using the contextual menu of each project:
A window looking like this will show up:
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.