Better. Faster. Stringier.
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.