Easier Translation Memory, Improved Scalability, and More

Easier Translation Memory, Improved Scalability, and More
Table of contents
Dimitris Glezos
June 17, 2010
3 min read

Re-printing on our blog an announcement sent to our developers list with an ambitious plan: Make Transifex work on super-fine-grained translation bits, including workflow and translation memory.

We’ve discussed this in the past in conferences, the IRC channel and it has been briefly mentioned here. I believe now it’s the best time to go ahead and bite the bullet sooner than later.

Transifex started 2.5 years ago as a web-based VCS File Submission tool. It had a perfect match with translator’s needs, so it found its niche application. It was written in TurboGears and things were good.

One year later, we decided to shift gears: We added translation statistics support and re-wrote everything in Django. This marked a big step for us, and the evolution of Transifex to a translation management platform. Since then, some very big open-source projects have switched to Transifex: Moblin (Intel), Maemo (Nokia), XFCE, LXDE, Django, Creative Commons, Mercurial, Bitbucket, Fluendo. Some of these projects worked very close with our team to develop features in an astonishing speed.

It’s time to switch gears again.

At the moment translations are handled on a file-based level. This has served as well in the past, as it’s pretty intuitive and binds well with how developers are doing things. However, it is also very limiting. Simple functions like merging translations, encoding, searching, grouping translations and splitting the work among translators have brought tough puzzles (if not blocker issues) during

We’ve now reached a point where we’re challenged with new kinds of problems, ones with higher complexity. Our core is required to become even more versatile, in a way, and be able to work on smaller units of translation work (ie. strings) and store translations in the database. File manipulation (if needed) will happen with import-export methods.

Here are some of the immediate benefits:

  • Rich usage of API and AJAX
  • Improved platform for translation features (e.g. more file formats)
  • Improved workflow (e.g. better assignment and tracking of work done)
  • Individual string/unit tracking (origin, past translators, versioning)
  • Simpler storage for dynamic apps (e.g. command-line apps/Makefiles,
    online apps, etc)
  • Easier Translation Memory, Terminology management, Suggestions
  • Improved scalability (lighter web servers)

Here is the cost:

  • Re-thinking how things should be stored and how Transifex itself should work
  • Deprecating loved code and notions
  • Migration of features on top of new notions
  • Extra work since we’ll grab this opportunity to improve other
    side-things as well (e.g. API/AJAX)

In the past several weeks we’ve worked on the implementation. No definite release day yet. Do expect a prototype early on though!

Things looking promising. We’re super-psyched. And we’re sure you will be too, once the result is out.

Some Best Practices for Developers

Speaking of feature updates and migrating workflows … if you’re a developer, we know that your role in the localization and translation management process can be a difficult one if you don’t have the right workflows in place. To help, we’ve put together a guide highlighting the practices that the best development teams put into place to streamline the localization process — from integrating localization into build cycles to tricks for avoiding string freezes. Download the free guide to learn more.

New Call-to-action

Dimitris Glezos

Subscribe to
Becoming Global

Get localization news and best practices delivered to your inbox each month.

FacebookgithubGoogle+Fill 88Twitter