Déjà Vu 8 - New features
— support for new formats, including SDL 2009 (already done to a certain extent with 7.5.316),
— enhanced QA rules using SQL saved to run in batch,
— parts of interface simplified, including templates to create projects with fewer clicks,
— improved fuzzy match repair and assemble of portions.
—Code being "rewritten and re-structured" to allow multi-core processor multithreading and "do read-ahead operations while having background threads running searches and writing data to the AutoSearch cache" which "will probably have a significant effect on speed".
—AutoSuggest/AutoComplete "far superior to SDL's".
—"DVX 8 beta probably by the "middle of 2010".
The use of normal relational databases as the storage mechanism for our TMs is something that has numerous advantages: scalability, performance and robustness are three things that come to mind right away. I hate to bring this up again, but quite a few years ago certain competitor claimed that their TM engine was better than others precisely because they used their own storage engine (based on a rather poor neural network design for its indexing mechanism) instead of a normal database; needless to say, some years ago they switched to databases, and then cited that change as a great improvement (when we had been doing it all along).
Independently of whether it makes technical sense for a TM to be stored in a database, the other great advantage of using an RDBMS is, as most DV users will probably confirm, the ability to use SQL (Structured Query Language) to manipulate the projects and TMs in ways that DV does not support directly. Using this standard database manipulation language allows users to perform certain operations that would be extremely time consuming to do by hand, and until the day we add scripting/macro support to DV (more on that in a future post), it is the only way to extend the program.
There are currently two main uses of SQL in DV: filtering project views (by specifying complex conditions for the row selector) and mass editing of TMs. Thanks to the feedback from a number of users, in the next version we also want to integrate the use of SQL in the expanded QA features we are going to introduce.
In the same way that DVX can currently mark (or navigate between) segments that have certain QA problems (such as incorrect embedded codes, wrong terms, etc.), we will allow you to define, through the use of SQL WHERE clauses, other cases that DVX should highlight (and attach descriptions to each case, so you can see why DVX has flagged them). The use of SQL, rather than just specifying string patterns for the source and target texts, will allow you to include additional types of constraints, such as length, dates, row status, etc. that are not possible in the customizable QA modules in other tools.
« Last Edit: 30 Jan, 2010, 22:55:33 by spiros »