On the 6th of march, we published our first poll to ask users what features they would like to see most in new Service Packs or versions of Transit NXT. The feedback was great and we would like to say a big Thank you to all of our readers who participated. The poll closed yesterday and here are the results.
The most voted option was Segment compare and history, and rightfully so from my point of view, because it is the one feature that would have the biggest impact on the quality of the translational work. Users would be able to see who translated a segment first, what was modified by subsequent revisions, who introduced the changes, etc. Project managers would have more control about the work of revisers and most importantly, this feature would be an excellent learning tool for translators. As they could see what changes were introduced by revisers, they could take these changes into account for future translations. When you think of Transit as a tool for post-editing machine translation, this feature would have even wider implications. Look at our posts on Transit NXT meets machine translation – nº 1 and Transit NXT meets machine translation – nº 2.
Not surprisingly, the Other option was extensively used. Many participants used this opportunity to stress what features they think are missing in Transit NXT.
But allow me to leave the “Other” option for a second post and let me focus on the features the users actually voted for. Again, I can only agree with the high level of priority given by users to Global search & replace variants in the translation memory. The bigger translation memories get, the more they are likely to get cluttered with translation variants, thus ridding the TM of what is one of its biggest advantages: guarantee phraseological and terminological consistence. To be able to identify and eliminate (only to the desired extent, of course) translation variants would contribute to improve the quality of translation memories and would allow us to maintain consistency.
A centralized TM and terminology server, the third most voted option, is of utmost importance to enable translators to work in distributed teams, since it would allow them to share linguistic resources (linguistic assets) and “learn together” while translating. It would speed up the turnover of translation projects and at the same time decrease the amount of project management needed.
Support for additional MT engines will allow to bring closer together the two technologies that have revolutionized translation during the last 25 years and will continue to do so, especially if the two technologies are combined together. Last but not least, Additional import filters would allow Transit NXT to interface with even more applications that are used for content creation and would thus improve its overall interoperability and integratability.
The users choices coincided greatly with my point of view about what direction further development of translation memory technology needs to take. Many things can still be done to adjust TM technology to recent developments in the translation industry and to the users’ needs that arise from these developments. That is the encouraging message that can be derived from our survey, and I would like to incite all readers to keep on sending us their suggestions about how we can improve.
In our next post, we will try to cover all the suggestions that were made by users who chose the “Other” option, one by one. Stay tuned!