Download Sdl Trados 2007 Suite Professional Property

God, give me grace to accept with serenity the fools who cannot be helped, Courage to charge the things which should be charged, and the Wisdom to distinguish clients from time wasters. Living one page at a time, enjoying one sentence at a time, accepting Trados as a pathway to grief, taking, as Jerome would, this awful text as it is, not as I would have it, to shape as I would have it, trusting that I can make all things right, if I render not with MT, so the client may be happy with this translation, and I supremely happy with payment in net 30 days. I've never dealt with MetaTexis before last night.

I had heard the name mentioned, but I have neither the time nor good reason to concern myself with all the myriad technical environments for translation out there except to hope fervently that some day their makers will all grow up and learn to exchange data with each others' tools properly. But when a colleague mentioned that she was having a few issues trying to migrate her 40,000+ entry termbase from MetaTexis to memoQ, I was intrigued, so I asked her to send me the data in various export formats. I got TBX and some sort of delimited text. Although memoQ currently can't do anything with TBX, I tried reading it into a few other tools (memSource and SDL Trados MultiTerm) to see if I could use them in the migration, but even after tweaking the file a bit I could not get the other tools to digest that alleged standard format, so I gave up and decided to attack the delimited text export. First stop, Microsoft Excel import. The data were semi-colon delimited. So far so good.

Text qualifier is a quote mark. When I looked at the data in Excel, it was quickly apparent that there were a number of corrupted records; I assume the export routine had a few hiccups. I also saw that the identifiers for the languages were badly scrambled in places. I don't know how much of this problem might have been inattention by the 'data owner', but any hope of separating data by sublanguages went out the window. Just 'French' and 'English' then. There were quite a few data columns to deal with, so I had a look at the headers and did some sorts to see which fields were actually used, how they were used and if they were really important to preserve.

Download Sdl Trados 2007 Suite Professional. A common way for Access software developers to distribute solutions and protect their intellectually property, don.

In the end, only six fields really mattered: • Source_Text • Source_Notes • Source_Definition • Translation_Text • Translation_Notes • Translation_Definition I looked a bit more closely and realized that the data owner had used the Notes and Definitions fields interchangeably over the years. Where there was an entry in one, there was none in the other. So using a concatenation formula in Excel, I merged the text from those columns into a single definition field for each language. Then I renamed the headers to make them work for a memoQ terminology import: • French • French_Def • English • English_Def Then I saved as Unicode text and imported into memoQ, right? Maybe in an ideal world or with an ideal data set, but not in this case. There were funky things to deal with.

Non-standard entities. And lots of crap, corrupted record structures that even messed up selection. I got out my electronic scalpel and performed about an hour's worth of 'data surgery', sorting and deleting to clean up most of the messy, useless stuff. Then I replaced the entity code "., which I had figured out should be a single quote mark, with a single quote mark. And the delimiter for synonyms, ;., was replaced by semicolons. In the course of testing, I discovered that some term records had been duplicated in the definition fields. No idea how that happened, but some of these had synonyms, and this really messed up later steps, so I copied those columns to another column and replaced the semicolons with a placeholder character, then copied the modified definitions column back.

This step was only necessary because of problems in about 0.3% of the data. Then it was time to decompose the definitions. I cut and paste the target term column to the last data column and saved a copy of the sheet as Unicode text. Then I opened it again from within Excel and specified two delimiters. Then I sorted the data by the separate target term columns to figure out the maximum number of synonyms in the data. There were 21 English synonyms in one case!

I named each of the target term column headers 'English'. Then I cut and paste the source term (French) column so it was after the last target term column. To keep the data from getting screwed up, I had to put a placeholder in as a substitute for the semicolons to separate synonyms before I saved the data as Unicode text last time. So now I changed those placeholders to semicolons again, saved as Unicode text again and re-opened the file specifying two delimiters as above. Then I repeated the sort procedure to figure out how many French synonyms there might be. One entry had 15 synonyms.

I named all the source term columns 'French' and saved everything as Unicode text. With the four column names all set to memoQ defaults for the languages involved, an import into a new termbase worked flawlessly with the defaults. Over 43,000 term entries came in cleanly with their synonym groupings in the entries preserved. The definitions (which were really just explanatory notes of various kinds) were associated with all the terms of their respective languages. I expect that most cases of data migration from MetaTexis will not require as many tricks as I had to use to clean up the dirty data in this instance.

But even such a 'worst case' scenario worked out rather well, enabling the translator to test and use her old data in the new working environment. Score another one for interoperability. The termbase structure of memoQ is limited with respect to its information fields; users looking for or wanting to add fields for where a term was found or for its sublanguage (as a term property) will be disappointed. The term source has no field of its own and memoQ currently does not allow new fields to be added; the sublanguage is handled at the term level (which makes sense, I suppose, if one does adaptation projects from one sublanguage to another). But a memoQ termbase is quite flexible when it comes to adding language and sublanguages; it can include any number of these.

But this flexibility can have cause some problems in term management for busy translators in some pairs. It's nice that UK English terminology will display in my project with US English set as the target language. But when I want to export a simple list of all English and all German words in a termbase, for example - and there are synonyms in the entry as well, the resultant delimited output is very confusing for many people. And if you decide that you want to move all the terms to 'generic' English, things can get really messy. I faced exactly that problem just last week. I had been maintaining the termbase for an end client for about a year, starting with a rather large in-house terminology I was given in an Excel file. I imported it to memoQ as generic German and started working with the target language set to generic English.

After a while the customer pointed out that UK English was their 'standard'. I swallowed hard and set my template project to UK English, pointing out that they would still be getting English with a rather American character from me no matter what I did with the spellchecker. Then later when I found out about the, I set the source language of that customer's project to German (Germany). After that they opened a subsidiary in the US and suddenly my native language variant was the new 'standard'. I now had a term base with five languages: two flavors of German and three flavors of English.

Consolidation time! But how does one do this?

MemoQ itself is unhelpful in this regard; it barely offers any management features for terminology, much less tricks like merging sublanguages. It's not that hard, really, and the steps depend on what data you actually keep in the termbase. If you never enter definitions for your terms things are pretty easy. To start consolidating your terms by combining the sublanguages, first export a fully specified delimited text file.

That's a 'CSV' file with all the defaults. Let's have a look at how that file is structured. If you open the exported data in a spreadsheet, the first group of columns, 12 (A-L) in my case, were concept level fields.

MemoQ refers to a concept in the termbase structure as an 'entry'. Each entry can have any number of languages, with each sublanguage counting as an 'independent' language. Related sublanguages are grouped. A given language or sublanguage can have any number of terms, which are treated as synonyms.

Why are they synonyms? Because in the term structure they share the same definition. If you have three language variants for English like I did, you can have three definitions. The definition fields are the first problem source. Each entry for a language or sublanguage has three fields: the actual term (word, phrase), an example (which is what you wrote in the 'usage' field), and 'term info' which is a bunch of other meta data for capitalization rules, matching, gender, forbidden status, part of speech, etc.

Advanced Email Extractor Pro Registration Cracked Tooth. If there are no definitions worth keeping in the extra variants of the language you want to combine, just delete all the extra definition fields. Leave the first one.

In my case last week, I left English_Def and deleted English_United_Kingdom_Def and English_United_States_Def. Then I renamed all the English_United_Kingdom and English_United_States columns to English. I made similar changes for the German variants. Then I saved the file and imported it to a new termbase in memoQ.

Problem solved. All three English types were combined as 'English' and the German variants as 'German'.

If I have definitions that I want to keep, there is a little more complication to avoid losing data. My quick and dirty solution was to create a temporary column for each major language in which I combine all the definitions for the language's variants. I do this by using Excel's concatenation function, something like this. =CONCATENATE(N2, IF(U2 = ',', ' / '),U2,IF(Y2 = ',',' / '),Y2) In my case N was the definition column for English, U the definitions for UK English and Y for US English. I renamed my merge columns as English_Def and German_Def and deleted the names of the original definition columns then saved the data as Unicode text (UTF-8, the memoQ default to avoid potential problems with mapping characters on re-import of the data to memoQ). After import, a quick look at my test data confirmed that no data was lost and all the language variants were combined as one major language. After fielding quite a few questions in the past week on segmentation problems with translation files and alignments as well as questions from a few colleagues and clients about ways to get better-looking output of the data stored in memoQ term bases (with SDL Trados MultiTerm), I prepared two longer tutorial scripts and distributed these with a segmentation practice file to registered subscribers to my ebook,.

This is a little thank you and dividend for their early support of my first commercial publication effort for translator education. To celebrate the national holiday in my native country as well as my own thanksgiving for all the ideas for best practice which my colleagues and clients continue to share, I have also set a 'Thanksgiving Weekend Special' with a special rate for the ebook until the end of Sunday, California time. Registered purchasers will receive the book update for memoQ 6.2 in December as well as any further updates for a year. Happy Thanksgiving, everyone!

A recent Twitter exchange reinforced the impression of confusion I had regarding SDL's intentions with the older Trados technology. Many translators, corporate users and language service brokers continue to use the 1990s technology of Trados 2007 (which is the current translation technology of many EU institutions until it is finally phased out starting in the coming year), and recent troubles with the loss of 'bilingual DOC' exports in memoQ 6.0.64 brought the matter of the old technology to a very uncomfortable head. (Earlier builds of memoQ must be used, or one must be patient until after the version 6.2 release, when this feature will be re-developed.) The exchange with the colleague on Twitter as well as the frequent contradictions in ongoing discussions among my friends and clients in the translation world made it clear that definitive answers were needed to abate unnecessary fears and allow people to plan the future of their processes with proper information. So I talked to Paul Filkin, Client Communities Director at SDL,whose blog is my favorite resource for reliable information about the technical arcana of Trados. [PF] It’s worth clarifying that we are talking about SDL Trados 2007 and not SDL Trados 2007 Suite.

The difference is that the Suite contains the latest version of SDL Trados 2007 (as well as various other applications) which is 8.3.0.363. But to answer your question specifically no, Trados Workbench and TagEditor are not going away for good just yet. I imagine there will still be users working with the older version of these tools for some time yet, but over time they will of course become obsolete – we just need to allow for that time. The driving forces for anyone hanging onto these old versions will be development of hardware and new operating systems as well as upgrades to authoring systems that the retired versions will no longer be able to support.

The other alternative, if you don't have a copy of SDL Trados 2007 Suite which you can still purchase with SDL Trados Studio 2011 today, is to use a free application from the SDL OpenExchange called the SDLXLIFF to Legacy Converter. This application can convert your Studio bilingual file to a Bilingual Doc or a TTX. This process caters for two parts in this workflow. First your client can edit these files in SDL Trados 2007 Suite and clean them into their Translation Memory, and second you can use the application to import the changes back into your SDLXLIFF so that you have the updated and approved version in your own Translation Memory. You can get this application here. This also means that the SDLXLIFF has been segmented using the new file types in Studio and not with the old file types in Trados 2007 Suite or earlier so even though your client will be able to clean the file into their Translation Memory they may lose some ability to fully pretranslate the same source file using Trados 2007 Suite or earlier. This is actually the same problem that could occur when converting the file using memoQ or WordFast for example but as those clients only provide the translator with the source file and not a pretranslated bilingual file in the first place this doesn't seem to be an issue for them.

[PF] I think it’s likely that when we release the next version of the software SDL Trados 2007 Suite and SDL Trados Studio 2009 will be retired. However, the important thing to note is that we have the Trados 2007 infrastructure built into Studio and this allows users to upgrade Translation Memories, handle legacy bilingual files and more importantly use the SDL OpenExchange to develop applications that will support workflows using the older tools. We are already seeing developers looking at ways of improving their older solutions with Studio since we were awarded the EU contract last month.

The agency GxP Language Services, which specializes in projects related to the healthcare sector, is planning a webinar on December 12th, 2012 on converting PDF files to formats which are appropriate for translation or other use. The session will be taught by Siegfried Armbruster, the company's managing director and a frequent contributor on various online fora. I have no affiliation with GxP nor do I know the presenter except through his online contributions on technical and/or professional issues, which have generally made an impression of seriousness. I am announcing this particular event, because it is a topic that is relevant to a great number of people involved with translation processes, and too few really understand these issues well enough to work effectively with all types of PDF documents. Educating colleagues and clients on the sort of thing Siegfried will be teaching has been a personal crusade of mine since long before Peter Linton and I presented best practices at a Berlin conference in 2006. There are many different challenges in working with PDF files, and, as my past translation support of a leading PDF advocacy alliance has taught me, new types of PDF make 'best practice' very much a moving target in some cases.

Monster Hunter Freedom 2 Usa Iso Torrent. Thus I welcome learning opportunities such as this and hope to see more in the future from professional organizations and colleagues as well. I'll quote the webinar description here; the graphic at the start of this post will take you to a page for more information and registration.

Translators have to deal with various types of PDF files on a frequent basis. PDF files might be sent by an agency or end client for translation or the translators might want to use PDFs for alignment purposes, among others. In this webinar, I will explain and demonstrate the various tools and workflows we use in-house to convert PDF files into Word files that are usable in translation tools. After registration, you will be sent a zip file with the various types of PDF files we will be discussing during this webinar (standard PDF, complex PDFs with multiple columns, images and tables, scanned PDFs, scanned distorted PDFs, Fax-PDFs etc.). For questions on the webinar, please contact siegfried.armbruster [at] gxp-language-services [dot] com. Armbruster, presenter of the course on PDF conversion The fee for webinar participation is USD 35, quite reasonable given the potential payoff in time saved, frustration reduced and potential added profit. I have no idea if he'll discussion the business aspects of correct PDF handling, but before you can even think of improving your image and bottom line by the way you handle an order with PDF files you have to get the technical aspects right.

With a comprehensive set of sample files provided to course participants, which they can use later to practice what they learn, it looks like this session might be a good first step for many people. This is the 500th blog post published on Translation Tribulations and a minor milestone of sorts.

After some delay, I have released the first electronic edition of memoQ 6 in Quick Steps, a guide compiled from my collection of instructions and tutorials which I use for training and consulting. It contains over 190 pages of tips and insights for beginning and experienced users of the memoQ desktop editions. Online distribution is being handled through Lulu.com initially until I decide a better way. Those who forward proof of purchase of to me will receive updates of the electronic edition for a year. The translation environment tool memoQ has evolved rapidly in the four years I have tested and worked with it, and I'll be adding and updating modules appropriately as the software and methods of working with it improve.

Some of the content in the book is taken from the memoQuickie tutorials on this blog, some of it has been shared only with clients and a few colleagues until now, and other material has not been published previously. A print edition is in the works and will be released in time for early next year after the book is updated to reflect new developments and services. This morning as I downed my first double espresso and prepared to translate an equally stimulating interim financial report, I scanned a few recent blog entries by colleagues. One post by German translator about a conversation with her uncle, a businessman involved with sales in another field, was particularly interesting. When the subject of volumes and rates for translation came up, he was quite clear about the difference between the sort of work we do and commodities which may be subject to some volume discounts and he asked ('Tell me, do you apply a surcharge for small orders?'

An interesting thought. Though she, like many of us, has a minimum order value, apparently this practice, common enough in some sectors, had not occurred to her.

I've occasionally applied a surcharge for large orders because of additional quality measures some of these require. And years ago, before compromises in a partnership led me to change my policy, I avoided taking on jobs that would involve less than half a day's work, because these tended not to be worth the administration and follow-up at the rates I was charging at the time. But a surcharge for smaller volumes?

That is a step beyond the minimum flat rate charge which I will consider, and it certainly answers those silly questions some have about volume rebates for translation. What do you think? Responsible for the content of this weblog in accordance with § 6 MDStV (Germany): Kevin Lossner. Liability disclaimer: Despite careful checking of the content contained therein, no liability is assumed for external links. Sole responsibility for the context and content of linked pages lies with the persons operating the respective sites.

Site visitors are welcome to cringe in terror at the use of Google Analytics to figure out what country my readers are in and which pages get read. Big Brother is watching!