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.
Nov 30, 2012
The Translator's Serenity Prayer
Nov 26, 2012
Coming to terms with MetaTexis and memoQ
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. Fine. 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. In the end, only six fields really mattered:
- Source_Text
- Source_Notes
- Source_Definition
- Translation_Text
- Translation_Notes
- Translation_Definition
- French
- French_Def
- English
- English_Def
There were funky things to deal with. Synonyms. 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. Sort of.
Nov 24, 2012
Combining sublanguages in memoQ terminology
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 bug in SDL Trados where XLIFF files are difficult to import if the sublanguages are not specified, 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". Ha, ha. 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:
.png)
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.
.png)
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". Done.
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:
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:
Obviously a little editing is still desirable - entry #3 shows some duplication because two English variants contained the same term; my sloppy conditional statement also left a few leading slashes for cases where the first definition column was empty and a later one for another variant of the same language was not. But that's not a big deal; one should always have a careful look at data after doing something like this.
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 bug in SDL Trados where XLIFF files are difficult to import if the sublanguages are not specified, 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". Ha, ha. 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:
.png)
.png){kind=link}
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.
.png){kind=small}
.png){kind=link}
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:
Obviously a little editing is still desirable - entry #3 shows some duplication because two English variants contained the same term; my sloppy conditional statement also left a few leading slashes for cases where the first definition column was empty and a later one for another variant of the same language was not. But that's not a big deal; one should always have a careful look at data after doing something like this.
Nov 23, 2012
Happy Thanksgiving memoQ tutorials & book special
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, memoQ 6 in Quick Steps. 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!
Nov 16, 2012
Trados 2007 goes to the guillotine - or not?
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 Multifarious blog is my favorite resource for reliable information about the technical arcana of Trados.
[KSL]: Judging from a recent Twitter traffic, there seems to be some confusion regarding SDL’s plans to discontinue support for SDL Trados 2007. So tell me – are Trados Workbench and TagEditor going away for good at last?[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.[KSL]: What exactly ARE the difference between those two versions?[PF] The best place to look for all the technical differences is the SDL knowledgebase where you can find a nice article called “What is new in SDL Trados 2007 Suite”:[KSL]: If I am using SDL Trados Studio 2011 and my client expects T2007-style “uncleaned” files, what can I do?[PF] The safest approach, because of differences between the old Trados versions is to ask your client to provide you with a fully segmented bilingual file, whether they are after TTX or Bilingual Doc. SDL Trados Studio 2011 supports TTX and Bilingual Doc as a file type without the need for SDL Trados 2007 at all. Your client should be able to provide these files for you because they have the appropriate software already.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:[KSL]: What are the “dangers” in this approach? Where might it go wrong for my client?[PF] You still have to provide your client with the “cleaned” file from Studio however because the Bilingual Doc or TTX created will not “clean up” into the fully formatted document you started with. This is because the Bilingual Doc or TTX is created from the SDLXLIFF and not from the original source file.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.So all in all both approaches seem to work… the important thing is to understand what your client wants to do with the file when they get it.[KSL]: Can these formats be edited and “cleaned” by the client to create a properly formatted target (translated) file?[PF] Only if they were prepared using SDL Trados 2007 in the first place. There is no substitute for SDL Trados 2007 if the client wants a properly formatted target file and future leverage from their Translation Memory.[KSL]: At what point can we expect support for TWB and TagEditor formats to be discontinued?[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.[KSL]: Does SDL Trados Studio 2011 still include a version of TWB and TagEditor?[PF] It’s not included automatically but you can still purchase it when you buy SDL Trados 2011. It’s not sold as a separate piece of software anymore.[KSL]: That's good to know. Will this continue to be the case with the next release (Studio 2013???)?[PF] The honest answer is we haven’t made a decision on this yet. SDL Trados 2007 Suite is really only needed by people who have create, rather than use, these legacy files. So in reality these people probably already have it… all they have to do is make sure they always prepare files for those who are translating them. This may be better for them and for the translator.
Practical webinar on handling PDF files - December 12th
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.
 |
| Mr. Armbruster, presenter of the course on PDF conversion |
Nov 15, 2012
Are we aMused by memoQ 6.2?
I'm not in the habit of reposting messages off online discussion lists, but this contribution on the Yahoogroups memoQ forum was just too tempting. It was the Muse that got me. I hate predictive typing, but I love the laugh I got out of considering the possibilities of that feature.
One question in inquiring minds right now should be what the heck freelance translators can expect for improvements in terminology handling and when.Two of the three points mentioned for qTerm are things I have been pushing for ages, and I often got the impression that Kilgray is afraid to give freelance translators what they need because of some daft notion that might hurt qTerm sales. Really, guys... that last feature is basically what I have been doing with Trados MultiTerm since the year 2000. I know that MultiTerm sucks boulders in the eyes of even most Trados users, but it excels in its flexible options for formatting output, and for many years I have exported data from memoQ to format nicely in SDL Trados MultiTerm and share with clients and colleagues. In fact I did a big dictionary for an industrial customer this morning - a beautiful two-column format with my own custom touches and marketing cover. It was only when friends using memoQ wanted to make good looking extras like that for their clients that I started messing with XSL transforms again after a ten year break and dragging others into the game. So please, play with us Gábor!
Ah yes, that repost.. good stuff....
One question in inquiring minds right now should be what the heck freelance translators can expect for improvements in terminology handling and when.Two of the three points mentioned for qTerm are things I have been pushing for ages, and I often got the impression that Kilgray is afraid to give freelance translators what they need because of some daft notion that might hurt qTerm sales. Really, guys... that last feature is basically what I have been doing with Trados MultiTerm since the year 2000. I know that MultiTerm sucks boulders in the eyes of even most Trados users, but it excels in its flexible options for formatting output, and for many years I have exported data from memoQ to format nicely in SDL Trados MultiTerm and share with clients and colleagues. In fact I did a big dictionary for an industrial customer this morning - a beautiful two-column format with my own custom touches and marketing cover. It was only when friends using memoQ wanted to make good looking extras like that for their clients that I started messing with XSL transforms again after a ten year break and dragging others into the game. So please, play with us Gábor!
Ah yes, that repost.. good stuff....
memoQ 6.2.1 [beta] released
Thu Nov 15, 2012 6:56 am (PST) . Posted by:
""Gábor L. Ugray"" gabor.ugray
Hi All,
For the kamikaze and the Zen lovers: I am happy to announce that
6.2's first beta build is now ready for download at the following
link:
http://kilgray.com/memoq/ 62/memoQSetup. 6.2.1.exe
Some technical information.
-- The 6.2 client installs "next to" previous versions, i.e.,
you'll get a new desktop icon and you can continue using 5.0 or
6.0.
-- The beta version accepts 6.0 licenses; no upgrade license
needed yet. This will change when the beta flag is stripped and
it becomes a normal release.
-- The Help, localized UI, and graphic elements are not final
yet.
-- LiveDocs corpora need to be migrated again. You can also do
this one by one, so unmigrated corpora remain available in 6.0.
-- If you're running a server or memoQWeb, mail us at support for
instructions about getting a beta for the server-side components.
The Zen. This is what I consider to be the most important
innovation in the client, a feature that I expect will no less
than revolutionize computer-aided translation.
A concise list of the functionality this release adds in the
client.
-- The Muse. Wouldn't it be nice if memoQ automatically, er,
suggested expressions extracted from TMs as you type your
translation? Now it does. Create a Muse and train it from your
existing TMs or LiveDocs corpora, and memoQ's predictive typing
will get inspired.
-- How about importing SDL Studio packages directly - including
the TMs? Also, SDLXLIFF is now a filter in its own right, not
part of the generic XLIFF filter.
-- 101% matches from LiveDocs. Cross-links are also
retrieved as matches now! (Works only with fresh content
in your corpus. You can export to XLIFF and reimport to
get this working with existing content.)
-- Numbers, tags, terms, upper-case words? Take them over from
the source with a single shortcut. A really, really short
cut. Just press "Ctrl". This is AutoPick.
-- Get results from multiple MT plugins.
-- Open translated documents automatically after export.
-- "Reject" changes, or revert to an earlier version of the
entire document.
-- Filter for X-translated rows; rows with tracked changes; rows
modified by a user, or after a given date; sort by segment
status.
-- Prefix matching in term recognition for Hebrew.
-- A new QA check for tag order changes, and other neat QA
tweaks. Missing term? The warning's text now contains the
possible target terms.
-- A simpler X-translate for mid-project updates. It also takes
over previous comments; retains the previous match rate recorded
in the document; and retains ignored warnings.
In the server and memoQWeb.
-- Document history recorded for actions related to 6.0's new
workflows: FirstAccept, GroupSourcing, slicing, and subvendor
groups.
-- Option to disable MT and terminology plugins in specific
online projects, for confidentiality.
-- Statistics and pre-translation for all target languages at
once.
-- Attaching analysis to e-mails sent out for FirstAccept.
-- FirstAccept and sliced documents available in webTrans.
-- qTerm: MultiTerm XML import
-- qTerm: CSV import, including updating existing TBs
-- qTerm: CSV export; fully formatted "dictionary-like" lookup
result and export; glossary PDF export.
Download and enjoy! BR,
Gábor
--
Gábor L. Ugray
Head of Development
Kilgray Translation Technologies
1255 Budapest, P.O. Box 7., Hungary
5700 Gyula, Béke sugárút 72. II/8., Hungary
All the myriad MT in memoQ 6.2
A few days ago, Kilgray CEO István Lengyel announced details of the version 6.2 release of memoQ expected at the end of this month and followed up with more details of the technodelights of that particular banquet. One morsel, I'm afraid, might not be so good for our health.
It's not enough to have one lump of crap generated by a computer algorithm as a restful alternative to the strain of thinking of a reasonable linguistic solution to the challenge of translation by an untrained mind. Because leading lingolemmings and their suppliers at SDL and other members in the localization cartels are fond of piling their MT higher and deeper, marketing logic at Kilgray dictated once again that mo be betta. But is it?
There's a little tactic I learned about many years ago in sales training. I try not to use it, because I consider it to be unethical in ordinary daily life. But car salesmen and some of the carnies I've seen operate in translation technology sales apply it quite effectively.
After you choose your new car, you are ushered into the sales office to discuss the details of the contract. What color do you want? Green, I'm a hunter. The 2.4 liter engine, right? No, 2.0 liters is plenty of power for me. Would you like that with a roof rack? No. What about a towing hitch? Well.... Here we have 20 models of car stereo to choose from, take your pick! Oh yes, and what kind of underbody anti-weathering treatment would you like? We have three options to choose from. What rim style would you like for the wheels? Would you like the three year extended warranty or the ten-year option with the alien abduction protection plan?
Question after question. Decision after decision. Decision fatigue.
At the end of a long day of applying his wisdom to the ordering of his kingdom, Solomon might have had some difficulties. Today's courtroom judges certainly do. Over the past year I've read interesting studies of how workload and diet affect the quality of sentencing decisions in the course of a day. I used to avoid 7 am classes in college, but if I ever go on trial for murder, I want to be the first case heard that day.
What's that got to do with memoQ and multiple MT suggestions displayed, or for that matter SDL and all the others who offer this particular path over the translation quality decision cliff?
If you're the guy who got that cool technical marketing job translating the newsletter for my favorite equipment manufacturer, I'll tell you what it means: mo be betta. Praise the Lord for this feature, which will help you do the job I deserve! If you further enhance your skills by adding a big portion of MT post-editing to your plate, reading and believing the content generated by TAUS, the Common (Non)sense Advisory and other advocates of the 7-Up Concept of Quality (extra points to the first one who groks that), then all will be well in my world of translation.
I had a problem with rats stealing my chicken food a few weeks ago. Finally, I made a reluctant visit to the local feed store and bought a box of tasty blue pellets, which were eagerly carried to the nest and consumed. For a whole week. I had to get an extra box, but just before it was finished, things went quiet. As the Germans say, gut Ding braucht Weil.
Thank you, Kilgray, for adding a feature in memoQ 6.2 which will make good translators stand out even more.
Multiple MT engines used at the same time. In older versions of memoQ you have to choose one single machine translation engine to be used during translation. With the new framework you can get matches from all of them at the same time, so if one is bad, you still can pick the good one.This was done, of course, in response to popular demand, and in this age of crowded schedules and crowdsourcing, the wise wannawanks know that crowds rule, especially in the Cloud, which in the Once and Future Middle Kingdom and nearby islands of past glory is usually known as the Crowd.
It's not enough to have one lump of crap generated by a computer algorithm as a restful alternative to the strain of thinking of a reasonable linguistic solution to the challenge of translation by an untrained mind. Because leading lingolemmings and their suppliers at SDL and other members in the localization cartels are fond of piling their MT higher and deeper, marketing logic at Kilgray dictated once again that mo be betta. But is it?
There's a little tactic I learned about many years ago in sales training. I try not to use it, because I consider it to be unethical in ordinary daily life. But car salesmen and some of the carnies I've seen operate in translation technology sales apply it quite effectively.
After you choose your new car, you are ushered into the sales office to discuss the details of the contract. What color do you want? Green, I'm a hunter. The 2.4 liter engine, right? No, 2.0 liters is plenty of power for me. Would you like that with a roof rack? No. What about a towing hitch? Well.... Here we have 20 models of car stereo to choose from, take your pick! Oh yes, and what kind of underbody anti-weathering treatment would you like? We have three options to choose from. What rim style would you like for the wheels? Would you like the three year extended warranty or the ten-year option with the alien abduction protection plan?
Question after question. Decision after decision. Decision fatigue.
At the end of a long day of applying his wisdom to the ordering of his kingdom, Solomon might have had some difficulties. Today's courtroom judges certainly do. Over the past year I've read interesting studies of how workload and diet affect the quality of sentencing decisions in the course of a day. I used to avoid 7 am classes in college, but if I ever go on trial for murder, I want to be the first case heard that day.
What's that got to do with memoQ and multiple MT suggestions displayed, or for that matter SDL and all the others who offer this particular path over the translation quality decision cliff?
If you're the guy who got that cool technical marketing job translating the newsletter for my favorite equipment manufacturer, I'll tell you what it means: mo be betta. Praise the Lord for this feature, which will help you do the job I deserve! If you further enhance your skills by adding a big portion of MT post-editing to your plate, reading and believing the content generated by TAUS, the Common (Non)sense Advisory and other advocates of the 7-Up Concept of Quality (extra points to the first one who groks that), then all will be well in my world of translation.
I had a problem with rats stealing my chicken food a few weeks ago. Finally, I made a reluctant visit to the local feed store and bought a box of tasty blue pellets, which were eagerly carried to the nest and consumed. For a whole week. I had to get an extra box, but just before it was finished, things went quiet. As the Germans say, gut Ding braucht Weil.
Thank you, Kilgray, for adding a feature in memoQ 6.2 which will make good translators stand out even more.
Nov 14, 2012
Where are they NOW with interoperability?
Inquiring minds want to know. Will we see real, practical and lossless data sharing between the major translation environment tools in our lifetimes, or will users continue to submit to the tyranny of incompatibilities driven by market greed and developer whims? My observations this year are not encouraging.
Nov 11, 2012
E-book release: memoQ 6 in Quick Steps
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 this release 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 memoQfest USA early next year after the book is updated to reflect new developments and services.
Nov 6, 2012
Low quantity surcharges in translation
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 Susanne Schmidt-Wussow 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 „Sag mal, nimmst du eigentlich einen Kleinmengenzuschlag für so ganz kleine Aufträge?“ ("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?
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 „Sag mal, nimmst du eigentlich einen Kleinmengenzuschlag für so ganz kleine Aufträge?“ ("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?