- Message identification. Each translated message is associated with the name (or id) of its translator. That’s work together with the following point, which is

- Translator rating. Each translator has to have its quality of translation rated by the team leader> This point combined with the previous point allows the team leader (or the coordinator or the proof-editor) to categorize the translated messages. For example, messages that belong to user of a high rating don’t need to be heavily reviewed, in contrary of those coming from a low-rated translator.

- Smart Auto-completion. When the translation tool finds a message in the translation database closely similar to an untranslated message, instead of putting right away what was found in the database and marking the message is fuzzy, it can start guessing the complete correct translation by applying certain rules and with the assistance of a dictionary. Furthermore, more intelligent translations can be made by splitting long messages stored in the database (sentences) into small phrases (splitting whenever a punctuation is met). That way if these small phrases (or sub-phrases) are found in another message, a part of this message will be automatically translated.

- Categorizing messages also by types of software. For example, for a new untranslated message in a web-browser software, the search in the translation database will take place first in other web-browsers messages, then in Internet software’s messages, and finally in the general area’s messages. That should be applied especially for short messages (terms) because some of them are related to the category of the software.

That’s what crosses my mind now.

http://svn.gnome.org/viewvc/damned-lies/trunk/vertimus/

PS: I’ve also tried to work with the Transifex project but finally I think it’s too difficult to embrace all translation projects (GNOME, Mozilla, etc) with only one tool.

My dream is to see some sort of DVCS for translation. Thus putting translation and translators in the driving seat, allowing them to translate rather then navigate the quagmire that is the many different ways that programmers expect localisers to work with them. Fine if you do one project but as your observe many are doing multiple projects: try Firefox, OpenOffice.org, GNOME and a few others and no matter what people have done to help you it still requires differences on each system.

My dream then is to see something where I can choose some place of residence: My teams Pootle server, my OpenOffice.org Pootle account and then translate whatever I need to and want to across those. Pushing and pulling translations as needed and sharing them back upstream. I have always wanted people to see Pootle as an aid and not a forced process. Thus you use it to augment current and existing processes.

A heads up on some features that I think you might not be aware of in Pootle and which I think align quite strongly with your vision:
* Pootle does version control - its done it for a long time now and covers all the major VCS and DVCS. So you can commit just like transifex using a common account.
* Quality assurance - this for me is missing in your list. Pootle has 45+ QA checks that can be adapted for various languages
* Stats - they’re pretty good and comprehensive - looking nicer thanks to the Mozilla work
* Assignment and Goals - Pootle can setup goals and assign people to those goals. So elementary work assignment
* Suggestions - Joe Random can make suggestions that translators can review thus preventing unadulterated damage to content

Where we’re headed with Pootle
* Verbatim - you mention Mozilla’s Verbatim, this is built on Pootle
* Translate Toolkit - the core of Pootle is the Translate Toolkit and that’s simply going to get more and more powerful
* Django migration - we’re busy completing a port of Pootle to Django, interestingly Pootle, Damned Lies and Transifex all now use Django so their might be some opportunities to integrate and share.

For me a dream system would also include these features:
* The ability to push projects to a server and get completed work back
* The ability for a translation co-ordinator to set goals and objectives and monitor progress so that including new languages is simple and autoamtic
* Information underload. There is overload of info on l10n. Lets reduce that by allowing for good communication of good information. E.g. a break in string freeze only really needs to be communicated with people at 100% since otherwise they might be surprised to see they’re not 100% on release. Only people who look like they can make the deadline really need to be told that the deadline is looming. etc.

I could write more.

But in summary I think we’re seeing the infrastructure coming together nicely and the speed is increasing, 2009 is going to be a great year for localisation infrastructure.

http://translate.org.za/blogs/friedel/en/content/re-bringing-all-translation-management-tools-together