The Comparison and Suggestions on Improvement about SDL Trados Studio 2009 SP1 and Trados 2007 Sp2
In June of 2009, SDL published SDL Trados Studio 2009. To be on the safe side, we made an internal test on the trial version and did not make an update until SDL Trados Studio 2009 Sp1 (hereinafter "Version 2009") was published. For the advantages and new characteristics of Version 2009, please see the official website of SDL and this article does not make deliberation. We desire to share our experience of using the two software through the comparison of Version 2009 and Trados 2007 Sp2 (hereinafter "Version 2007") and hope it may be helpful to the further improvement of Version 2009.
1. Print Preview: This function is similar to the Export Html of SDLX2007 but it is far from better than the old version. Most of users export or print bilingual aligned documents generally for handing them out to translators having no SDL software or publishing them directly. The interface and style of Print Preview of Version 2009 are lacking in beauty and custom functions, which cannot be used for publishing the contents. In terms of Review, the Export Html of SDLX2007 shows translation unit number (TU NO.), Source, Target, Comments or Terminology QA results and etc. with row display in form, which are quite convenient for Review by third party and can be published directly with slim adjustments. However, Comments, Target which are mixed in a column are adverse to view and edit in Print Preview of Version 2009; it is most unfortunate that there’s no translation unit number and the results of QA cannot be displayed, which leads to inconvenience for us to cooperate with third parties. Above all, the Print Preview of Version 2009 compared with Export Html of SDLX2007 is degeneration just like a chicken rib which is hardly worth eating but not bad enough to throw away. We suggest SDL improving the Print Preview function which enables users to custom interface and style, row displays translation unit number or the results of QA and other information users need;
2. Edit-View: The row spacing of TU is too narrow, which is inconvenient for viewing during translation. Widening row spacing or enabling self-defined row spacing are suggested;
3. In the option of TM View, Editor and TM View can only enable self-defined "Number of field values to show". We suggest adding function of self-defined field values to show for the convenience of viewing information needed. For example, if a TM has 7 field values, 3 field values are self-defined to be showed and field values to be showed with priority can be defined (for example: classification, project name, status). If all information needs to be known, it can be viewed by Field Values View function, which can enable the interface to show as much needed information as possible in the limited interface space of Edit View. Moreover, field values of translation unit can be copied through maintenance interface in Workbench, which is used to keep the maintenance log file of TM; but in Version 2009, full field values (including system filed values) of certain translation unit cannot be copied. We suggest in the interface of viewing field values adding Html export function so as to record the maintenance of the TM data.
4. TM Options. Version 2009 is not equipped with "Updating attribute and text fields" compared with Version 2007. When Creating or Updating TU, we cannot control multiple translation in accordance with different field values (for example, when field values are the same, new TU will substitute the present TU and merge or remain the new field values; when field values are different, old and new TUs will be kept simultaneously, etc.);
5. Context Match. Version 2009 didn't adopt the mechanism of Perfect Match of Version 2007 but adopts Context Match, which is not necessarily safe we think. The test showed multiple translations are allowed in TM of Version 2009. We are not sure how Context Match processes the bilingual context match in TM database. When bilingual documents are to be revised, the most safe mechanism is first designating the previous bilingual documents (TTX or XLIFF) without applying the prior TM database and then Context Match the new documents, which can avoid any possible influence on the quality of updating bilingual documents that brought by multiple translation.
6. Translation Memory database present is still unidirectional. We suggest the Translation Memory database becoming bidirectional in the next version. For legal and technical bilingual documents, lawyers shall pursuit the consistent expression as possible as they can. The bilingual characteristic of language in TM database is so important and too frequently creating opposite directional TM is burden to users. Moreover, extra money will be charged for adding 500,000 TUs in the TM Server, i.e., the expenses will be doubled if users need bidirectional TM Database, which is obviously unreasonable.
7. The control of authority of TM Database is better than Version 2007. It cannot be figured out why it doesn't work when we set a code in TM database of Version 2007. The new version solved this problem. We suggest TM database referring to the mechanism of Termbase that users can set the expiry date. In an out-sourced project, such function is very helpful for desktop users.
8. However, in the new version, 2 MT windows cannot be opened simultaneously like MT2007 to analyze terms in different Termbase and also inconvenient view several terms in one MT window to make analysis, which makes some useful functions of Trados07 unable to be realized in Version 2009. It is so inconvenient that we suggest SDL recovering these functions in new version. Adding terms in the Edit view interface: When adding terms by Input Model, we hope Context function like Trados2007 enables us to choose to automatically copy Source and Target of a translation unit, which can remarkably increase the working efficiency; Moreover, MT still cannot process batch quantity of Terms, for example, editing field values of Terms which match the conditions of Filter by batch quantity, or deleting Terms by matching the conditions of Filter by batch quantity. i.e., it consumes more time and energy in maintaining Term database than maintaining TM. We hope SDL consider the batch quantity process mechanism in MT in the new version.
Above all, Version 2009 combines the advantages of Trados and SDLX and without doubt, the whole product is leveled up. For example, the Tag of translation interface is sharply decreased; multiple TM databases can be loaded; aligned bilingual documents and reasonable flow and so on, which bring a lot convenience to the team working of translators and teams. As to the details mentioned above, Version 2009 is less delicate than Version 2007. In addition, we need more application to draw a conclusion on the application of Project. In a word, the recent updating of SDL really brought a great impact on our working flow. To adapting to the new version and optimize out working flow, the time and energy consumed by us are more valuable than the updating expense itself. We hope SDL can be more considerate to users when updating products in a large-scale. If every user needs to "Zhe Teng" for updating, certain users may be exhausted and scared away.
G•IPRs Runhe Group
- Michael Ni's blog
- Login to post comments
- 中文


Problems on Recognizing and Editing Monolingual Terms
Problems on Recognizing and Editing Monolingual Terms Exported from MT Extract in SDL Trados Studio 2009
Monolingual term (untranslated term) is a term which is extracted from the original text by MT Extract and imported to Project Termbase.
Notice should be paid to these terms by translators and corresponding translations shall be added to the Project Termbase. Although “Show recognized terms with no available translation” is set in Termbase, frequent refresh or reset are conducted to recognize monolingual term; Even though the monolingual term is recognized and showed in Studio, Input Models doesn't work when editing such term and the recognized term cannot be deleted in Studio. If we add new term, you will be prompted that "The term already exists" and whether editing is needed; if we don't edit the term, no operation can be conducted to the term, for which we can only create an empty Project Termbase when planning our working flow so as to solve the above problem. Such problem reduces the values of exported terms from MT Extract applied in Studio. We hope SDL is able to solve such problem.
G·IPRs Runhe Group