On Monday, March 26th in the afternoon there will be a short workshop held in Berlin covering the basics of terminology extraction with memoQ 5 and the use of selected terminology for quality assurance (checking the compliance of the terms used). Finally, a few standard, adaptable methods for sharing the terminology acquired in memoQ with others using Trados MultiTerm or other tools will be presented.
The workshop is planned for 2 hours with some time for Q&A and follow-up afterward. Participation is limited to 5 persons. If you are interested in joining us next Monday or on another occasion for this workshop, contact me privately for further details.
Mar 11, 2012
memoQuickie: feedback comments
Exporting comments in memoQ in a bilingual table for others to comment further and correct, then re-importing to update translations and the TM is a very useful feature. I use it often to inform clients of uncertain terms or errors in the source text. You can too, as follows:
The exported table shows only commented segments:
- While translating, use Ctrl+M or double-click the speech balloon on the right to open the comment window and comment the segment.
- On the Translations page of the Project home tab, select the document(s) with comments to export and click Create view. Choose the advanced options:
- Then mark the checkbox for Commented on the Status tab:
- To export the new view as an RTF table, select it and click Export bilingual and choose the Two-column RTF option. To refine your options, click Next, or just export the table.
The exported table shows only commented segments:
Mar 10, 2012
Just for fun: 8 MT engines for DE>EN compared
When technology guru Jost Zetzsche (Twitter: @jermobot) recently reminded the world of the relative new memoQ plug-in for itranslate4.eu, I thought I would test and blog it for fun if not profit. Alas! The key validation for the free demo (10,000 characters) I "purchased" isn't working for me, so I decided to have fun another way until that gets sorted out. I plugged two sentences into their engine offering translations from six commercial MT tools, then I put the same two sentences in Google and Microsoft's MT engines. One of these sentences is fairly simple in structure, the other less so. I won't comment the results much; I leave judgment to experts and fools to make as they choose.
The results layouts for Google & Bing were modified for better viewing. I think there are plug-ins for all these engines in a number of tools if anyone is daft enough to really want to use them productively (thus unprofessionally ignoring many confidentiality requirements for clients quite aside from other possible issues).
PROMT actually got it right and idiomatic. Should I be impressed? Repeats with other simple sentences showed that accuracy is a real crapshoot for all six engines, though True Believers in MT can serve the machine by suggesting improvements. I did my part by submitting improvements for sentences related to the ongoing Vatican scandals about abuse by priests.
Go Google! Nice to know there are so many ProZ translators depending on this great engine :-)
Full points to Big Bill & Co. this time. Two out of eight got it right. Hmmmmmmmm.
Now for something a wee bit more, taken from the Wikipedia entry on photovoltaics...
Our friendZ at Google say:
Now Big BillZ BoyZ get their chance:
O what a Brave New World, that has such technology in it :-) I think I'll stick to my specialties and use the Dragon if I feel the need for speed. I can dictate fresh faster than I can analyze and fix even the simplest "close calls" for correctness.
Of course, sentence-by-sentence, results will differ in reliability with every engine. But isn't it simply better to use the most reliable engine of all: BAT* with a good translator?
A recent LinkedIn discussion went on at length about quality metrics and other bla bla for MT. And there are various discussions of "best practice". Given enough beer or other intoxicating substances, I'm not averse to engaging in such discussions, and the ten-year-old in me who still likes to fiddle with things IT does take an academic interest in the subject of MT and productivity, but if I want real work and real quality (and yes, Renato, Kirtee, et alia there is such a thing, though its definition will vary by domain and be ever disputed... try telling a customer trying to understand a user manual that it doesn't exist or watch the faces in an audience as a translated speech is delivered in various versions, or send your marketing brochure for the UK to Bangladesh or Russia because rates are lower) I will find it with methods that stay far away from MT. Let the competition do otherwise. PLEASE.
* "brain-assisted translation", a concept once common in the days before the IT devoloution of the profession and still favored by a few high-earning dinosaurs
The results layouts for Google & Bing were modified for better viewing. I think there are plug-ins for all these engines in a number of tools if anyone is daft enough to really want to use them productively (thus unprofessionally ignoring many confidentiality requirements for clients quite aside from other possible issues).
PROMT actually got it right and idiomatic. Should I be impressed? Repeats with other simple sentences showed that accuracy is a real crapshoot for all six engines, though True Believers in MT can serve the machine by suggesting improvements. I did my part by submitting improvements for sentences related to the ongoing Vatican scandals about abuse by priests.
Go Google! Nice to know there are so many ProZ translators depending on this great engine :-)
Full points to Big Bill & Co. this time. Two out of eight got it right. Hmmmmmmmm.
Now for something a wee bit more, taken from the Wikipedia entry on photovoltaics...
Our friendZ at Google say:
Now Big BillZ BoyZ get their chance:
Of course, sentence-by-sentence, results will differ in reliability with every engine. But isn't it simply better to use the most reliable engine of all: BAT* with a good translator?
A recent LinkedIn discussion went on at length about quality metrics and other bla bla for MT. And there are various discussions of "best practice". Given enough beer or other intoxicating substances, I'm not averse to engaging in such discussions, and the ten-year-old in me who still likes to fiddle with things IT does take an academic interest in the subject of MT and productivity, but if I want real work and real quality (and yes, Renato, Kirtee, et alia there is such a thing, though its definition will vary by domain and be ever disputed... try telling a customer trying to understand a user manual that it doesn't exist or watch the faces in an audience as a translated speech is delivered in various versions, or send your marketing brochure for the UK to Bangladesh or Russia because rates are lower) I will find it with methods that stay far away from MT. Let the competition do otherwise. PLEASE.
* "brain-assisted translation", a concept once common in the days before the IT devoloution of the profession and still favored by a few high-earning dinosaurs
Mar 4, 2012
memoQuickie: locations for data & avoiding name length trouble
Most memoQ users never change the program defaults for where projects, TMs, termbases and corpora are stored. Usually this is not a problem, but some want to put things elsewhere, and if you have crazy clients (like lawyers) who are fond of file names that push the allowed limits for Windows, you may encounter frequent errors because of file path length (in many tools, not just memoQ - OmegaT appears most robust in this sense). To choose custom locations for your data and possibly reduce the chance of trouble with long file names, go to select the menu and dialog option Tools > Options... > Locations
and set the paths you want. At the bottom of the dialog is the possibility to shorten the temporary folder path length and avoid some trouble.
and set the paths you want. At the bottom of the dialog is the possibility to shorten the temporary folder path length and avoid some trouble.
International dates and English
Time and again I encounter problems with texts or translations because of dates. This is something we as translators and quality reviewers for languages products and services must keep in mind.
After a recent patent translation, my agency client was asked to provide translations of my appointment as a translator for the German courts and of my examination certificate for the state exams in Berlin in which I qualified as a specialist for natural science. The agency principal is a decent translator himself, and since translating my own certificates would be a conflict of interest, he undertook the task and sent me the results for approval. As expected, the translations were OK except for one thing... the dates. At the top of one translation, I did a double-take at the revelation that I was born in July, rather than October. The date stood clearly as 07/10/1961, and it took a minute before I remembered that Brits, Australians and some others write their dates differently than Americans do. The German way of writing the same date as numbers (07.10.1961) at least has the virtue of using a different separator than Americans use, and it's a different language, so it's hard to be confused there if you know the German custom. But in English, well... the trap is there.
A day later an English friend fell into the same trap in memoQ. She wanted to export some TMX data from a rather large memory - just the work of the last few days for a particular client. The export was made on the second day of March, and when there were some questions regarding the exported data and I was asked to look at the TMX file, I was surprised to see data going back to the third of February. Fortunately, the TM from which the export was made contained only data for that client, so no breach of confidentiality occurred, but in a general TM this would have occurred. What was the problem? She was thinking in "UK mode" and confused 02/03 and 03/02.
One way to avoid this problem is to use the International date format, as Kilgray does in memoQ's filter for the TM and termbase editors, for example:
I am fond of using the international YYYY-MM-DD format wherever appropriate. I expect technical people anywhere in the world to be able to deal with it. However, this numeric format has its limitations too, because there are quite a number of people who simply aren't familiar with the format or who may be a bit dyslexic with numbers. The best solution in most cases is to use dates which include the month written as a word or a least an abbreviation thereof. For English, I would use a specifically American or British number format only if one is very, very sure that wider distribution will never be required.
After a recent patent translation, my agency client was asked to provide translations of my appointment as a translator for the German courts and of my examination certificate for the state exams in Berlin in which I qualified as a specialist for natural science. The agency principal is a decent translator himself, and since translating my own certificates would be a conflict of interest, he undertook the task and sent me the results for approval. As expected, the translations were OK except for one thing... the dates. At the top of one translation, I did a double-take at the revelation that I was born in July, rather than October. The date stood clearly as 07/10/1961, and it took a minute before I remembered that Brits, Australians and some others write their dates differently than Americans do. The German way of writing the same date as numbers (07.10.1961) at least has the virtue of using a different separator than Americans use, and it's a different language, so it's hard to be confused there if you know the German custom. But in English, well... the trap is there.
A day later an English friend fell into the same trap in memoQ. She wanted to export some TMX data from a rather large memory - just the work of the last few days for a particular client. The export was made on the second day of March, and when there were some questions regarding the exported data and I was asked to look at the TMX file, I was surprised to see data going back to the third of February. Fortunately, the TM from which the export was made contained only data for that client, so no breach of confidentiality occurred, but in a general TM this would have occurred. What was the problem? She was thinking in "UK mode" and confused 02/03 and 03/02.
One way to avoid this problem is to use the International date format, as Kilgray does in memoQ's filter for the TM and termbase editors, for example:
I am fond of using the international YYYY-MM-DD format wherever appropriate. I expect technical people anywhere in the world to be able to deal with it. However, this numeric format has its limitations too, because there are quite a number of people who simply aren't familiar with the format or who may be a bit dyslexic with numbers. The best solution in most cases is to use dates which include the month written as a word or a least an abbreviation thereof. For English, I would use a specifically American or British number format only if one is very, very sure that wider distribution will never be required.
Mar 1, 2012
memoQuickie: "re-registering" AWOL TMs and termbases
Recently a friend bought a new computer and copied her old
translation memories and termbases onto it. But when she started the
application, she was surprised they were no longer available on the new computer. Translation memories and termbases than have been moved must be "registered" on the new computer using the Register local function on the respective page (for TMs or termbases) or on the resource console (Tools > Resource console...). After this, they will appear in the relevant list.
The folder name is the same as the database name. Inside the folder are index files (always named the same) and the MemoQTB.mtb or MemoQTM.mtm file, which must be selected to add the termbase or TM to the active list in memoQ.
 |
| The Register local function on the translation memories page of the resource console |
 |
| The Register local function on the termbases page of the Project home tab |
The folder name is the same as the database name. Inside the folder are index files (always named the same) and the MemoQTB.mtb or MemoQTM.mtm file, which must be selected to add the termbase or TM to the active list in memoQ.