We are proud to announce that Translation.io is now supporting Laravel the same way as Ruby on Rails.

Syntax is a bit different but it works exactly the same:

• t('source text') for GetText
• trans('some.keys') for PHP key/value

Just select your favorite framework when creating a new project and you will receive the installation instructions:

If you like working with us and you know some fellow Laravel developers, please tell them we're open for business. For each positive or negative feedback, we'll offer them 3 free months on Translation.io.

We'd like to thank @armandsar for helping us bootstrapping this package.

You will find more information about the installation and usage of the Laravel package on the official repository: https://github.com/translation/laravel

A year ago we added a history feature to Translation.io. It allows you to view the history of all your translation projects.

Better History

We have been working on the improvement of that history lately. It was not possible to filter it by language, user or change type, and we thought it was a missing option.

You can now open the history modal from any of your projects:

The history contains all types of changes:

• translation of a segment;
• source text editions;
• comments and tag additions/removals;

and you can filter on them.

Email Digests

As the project owner, being notified when a translator makes some change on the project is a must-have. Also, if you are the responsible translator for a specific language, you want to know when new non-translated segments are added to the project.

That's why we have added email digests for activity on your projects.

All changes performed by others on your projects will be compiled into a nice email. Don't worry we won't SPAM you too much!

You are watching all of your projects by default. You can unwatch activity on a per-project basis directly on their respective translation pages:

We hope you will enjoy the new history and we are as always eager for feeback!

Maybe you've noticed that the URL of the page changes almost everytime you do an action on the translation interface: moving from a segment to another, changing filters, searching a word, etc.

Actually the current state is kept in the URL so you can share URLs from your work with your collaborators/translators. If they follow the link, they will get right where you were: same filters, same selected segment, same target language.

Also, the navigation history is preserved so the back button of the browser will bring you back exactly where you were before. It's not much, but that's unfortunately not always like that on modern one-page applications.

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!