The European Union provides tons of information online that can be a real treasure. Sometimes there is so much that is difficult to know where to start.
An excellent resource is the “Summary of legislation” site, where you can find useful information on the EU in eleven different languages. The site include detailed EU glossaries with clear explanation of 233 key EU terms.
But probably the best place to start is the “Eurojargon” glossary (this in 20 languages); a “plain language guide” aimed at untangling for the general public many confusing terms often used by EU insiders.
These are not real translation glossaries: they don’t include an easy key to the translation of each term. But since all this material is in at least eleven different languages, it should prove useful to many translators.
The links provided here get you to the English version of these pages. In each page you can then select your language.
Tuesday, February 10, 2009
EU - multilingual summaries of legislation
Labels:
Glossaries
Saturday, January 31, 2009
Why this love affair with Notepad?
I'm doing an on-site linguistic QA of some complex software. This is often frustrating: programs that don't work, crash, get disconnected. These annoyances come with the job: you wouldn't QA software already in perfect shape (during linguistic testing, we often discover many functional bugs).
One thing that particularly exasperates me, however, is the program supplied for accessing some of the reference material. The references are a set of tab-delimited files. We search in these files when we find a problem in the localized interface: inconsistent translation, mistranslation, etc. Unfortunately, the tool used by this (major) translation company is Notepad: with it, we are supposed to search within the files, identify all the relevant strings, and copy them to a bug-tracking database. To search multiple files, we would open several different instances of Notepad, one for each file. To identify multiple strings or substrings, in Notepad there is no other way but to search, find the first occurrence of a string, and search again, until we get to the end of the file.
Notepad is not suitable for this: more specialized tools are much better. I would suggest Funduc's Search & Replace or ApSic's XBench: they allow searching on all files at once, display all the hits at the same time (in a more legible way), and permit more sophisticated searches, with regular expressions (Search & Replace) or with the "Power Search" feature of XBench. (In fact, with the test lead permission I at once installed XBench and started working with it).
In many QA projects, editing is part of the job. Again, Notepad is often the program provided: using a text editor ensures that no extraneous elements are surreptitiously added to the text file (as would happen easily, with a word processor such as MS Word). The disadvantage is that Notepad offers no good search functions, no syntax highlighting, no code folding, and so on.
Even if the translation company doesn't want to provide Ultra Edit or other high-end text editors (because of the cost involved, or the steeper learning curve), there are many excellent free text editors. For such tasks, for example, I use Notepad++.
One thing that particularly exasperates me, however, is the program supplied for accessing some of the reference material. The references are a set of tab-delimited files. We search in these files when we find a problem in the localized interface: inconsistent translation, mistranslation, etc. Unfortunately, the tool used by this (major) translation company is Notepad: with it, we are supposed to search within the files, identify all the relevant strings, and copy them to a bug-tracking database. To search multiple files, we would open several different instances of Notepad, one for each file. To identify multiple strings or substrings, in Notepad there is no other way but to search, find the first occurrence of a string, and search again, until we get to the end of the file.
In many QA projects, editing is part of the job. Again, Notepad is often the program provided: using a text editor ensures that no extraneous elements are surreptitiously added to the text file (as would happen easily, with a word processor such as MS Word). The disadvantage is that Notepad offers no good search functions, no syntax highlighting, no code folding, and so on.
Even if the translation company doesn't want to provide Ultra Edit or other high-end text editors (because of the cost involved, or the steeper learning curve), there are many excellent free text editors. For such tasks, for example, I use Notepad++.
Labels:
Localization,
Tips and Tricks,
Tools
Wednesday, January 28, 2009
100,000 page views - Thank you!
The page views counter for this blog was at 99,982 yesterday night. When I checked this morning it had reached 100,042.
A big thanks to all of you who have been reading this blog!
The next big goal is 100,000 visitors, but since at the moment the visitor's counter is at 56,576, I expect it will take another couple of years to get to the next big number.
Thanks again for visiting here!
A big thanks to all of you who have been reading this blog!
The next big goal is 100,000 visitors, but since at the moment the visitor's counter is at 56,576, I expect it will take another couple of years to get to the next big number.
Thanks again for visiting here!
Friday, January 16, 2009
Tip: deciphering handwritten place names
When doing legal translations, I sometimes find myself trying to decipher badly handwritten text. Usually I manage to puzzle out the text, and only seldom have to resort to the [illegible] tag. Names of people and places, however, are often more challenging, as context offers no help.
When a badly handwritten place name includes a ZIP or postal code, however, there is usually help: you can search for the ZIP or postal code to determine the name of the place. For example, Linderburst, NY or Linderhurst, NY? By looking up the 11757 ZIP code in the USPS web site, I can see that the correct spelling is Lindenhurst, and not Lindeburst.
When a badly handwritten place name includes a ZIP or postal code, however, there is usually help: you can search for the ZIP or postal code to determine the name of the place. For example, Linderburst, NY or Linderhurst, NY? By looking up the 11757 ZIP code in the USPS web site, I can see that the correct spelling is Lindenhurst, and not Lindeburst.
Labels:
Tips and Tricks
Dictionaries and encyclopedias as search engines
Fabio Said has a post (Installing many dictionaries as Firefox and Internet Explorer add-ons) in fidus interpretes about installing dictionaries, encyclopedias and other reference works as search engines in Firefox or other browsers. An excellent tip that I'm sure will prove useful to many of us. Check it out!
Beside the technique suggested by Fabio, you can set up Firebfox (or IE7) so that it opens with several dictionaries, each in its own tab. For example, I have tabs for the Garzanti, Rizzoli and Paravia English-Italian dictionaries, as well as separate tabs for the De Mauro Italian dictionary, for the Simone legal dictionaries, and for the English and Italian Wikipedias.
Beside the technique suggested by Fabio, you can set up Firebfox (or IE7) so that it opens with several dictionaries, each in its own tab. For example, I have tabs for the Garzanti, Rizzoli and Paravia English-Italian dictionaries, as well as separate tabs for the De Mauro Italian dictionary, for the Simone legal dictionaries, and for the English and Italian Wikipedias.
Labels:
Dictionaries,
Tips and Tricks
Wednesday, January 14, 2009
Idiom bug
I have often criticized Trados, but this time it's another SDL product that comes up short: Idiom Workbench.
When running the spelling checker on a translation some special characters are not recognized as legitimate. This would be OK, but the spelling checker in this case also does not display the unrecognized words (see screenshot).

This is a problem. If you click "Change", the unrecognized word is deleted, there is no option to skip, and the only thing left is to click "Cancel" close the spelling checker, advance manually, and restart it again.
To be fair, this might be a Microsoft Word bug more than an Idiom one (since Idiom uses the MS Word spell checking engine). However, when checked in Word the unrecognized word is displayed correctly, so I think the main culprit is Idiom Workbench.
When running the spelling checker on a translation some special characters are not recognized as legitimate. This would be OK, but the spelling checker in this case also does not display the unrecognized words (see screenshot).

This is a problem. If you click "Change", the unrecognized word is deleted, there is no option to skip, and the only thing left is to click "Cancel" close the spelling checker, advance manually, and restart it again.
To be fair, this might be a Microsoft Word bug more than an Idiom one (since Idiom uses the MS Word spell checking engine). However, when checked in Word the unrecognized word is displayed correctly, so I think the main culprit is Idiom Workbench.
Monday, January 12, 2009
Should the translator contact the author?
Should the translator contact the author, and if so, how much weight should the translator give to the author's overt intention as against his or her intentions as perceived or inferred from the text of the book?
[...] the translator also has to decide whether to be loyal to an author’s perceived intent or to the inner workings of the actual textA very interesting post by A.M. Correa in the Words Without Borders blog.
Labels:
Books,
Literary Translation
I so wish I could do that
Reading 462 books a year.
Brings to mind a passage in Chaim Potok's The Chosen, where Reuven more or less tells Danny to knock it off, because if Danny was reading ten books a week, Reuven himself was not far behind, at seven or eight.
The best I ever managed was slightly over 160 in a year, when I was in college, and nowadays I'm lucky if I break 50 or so.
Sigh.
Brings to mind a passage in Chaim Potok's The Chosen, where Reuven more or less tells Danny to knock it off, because if Danny was reading ten books a week, Reuven himself was not far behind, at seven or eight.
The best I ever managed was slightly over 160 in a year, when I was in college, and nowadays I'm lucky if I break 50 or so.
Sigh.
Low rates for beginners
Corinne McKay, in her blog "Thoughts On Translation", has an excellent post on Avoiding beginner's mistakes.
I would like to underscore one of the points she makes:
Not only do many beginners set their rates too low, but, when this is pointed out to them, they complain that otherwise they would not get any work.
What they don't realize is that work will eventually come aplenty to good translators, but that working for substandard rates leads to lower-quality work.
When working for low rates, the most obvious way to increase revenue is to accept more and more work. This means that work gets rushed and the inevitable errors creep in. Being kept busy by low-paying customers, also leaves little time for keeping up to date, for searching new customers and for accepting higher-paying work, should it arrive.
Working for substandard rates easily leads to accepting work for which one is ill suited: but in this regard, see another point in Corinne's post:
Finally, working for low rates means accepting work from the cheapest agencies in the industry. Eventually the translator's résumé will list a whole range of agencies notorious for paying little and for their little regard for quality. And once that is the image one conveys with his or her résumé, it is difficult to rebrand oneself as a "high-quality translator".
I would like to underscore one of the points she makes:
"DO NOT set your rates suspiciously low. I think that especially in a down economy, many beginning freelancers are tempted to set their rates markedly below the going rate for their languages. [...] I think that lowball rates attract bottom-feeding clients who are looking for high-quality work for minimum wage. "I agree, and would like to add something:
Not only do many beginners set their rates too low, but, when this is pointed out to them, they complain that otherwise they would not get any work.
What they don't realize is that work will eventually come aplenty to good translators, but that working for substandard rates leads to lower-quality work.
When working for low rates, the most obvious way to increase revenue is to accept more and more work. This means that work gets rushed and the inevitable errors creep in. Being kept busy by low-paying customers, also leaves little time for keeping up to date, for searching new customers and for accepting higher-paying work, should it arrive.
Working for substandard rates easily leads to accepting work for which one is ill suited: but in this regard, see another point in Corinne's post:
"DO NOT take on work that you know is wrong for you just because you need work".Another error many beginners do is to complain about "the agency's rate": there is no such thing - it's your rate, not the agency's, but thinking of it as the agency's rate leads to accepting things such as agencies unilaterally lowering their rates (as recently discusses on ProZ).
Finally, working for low rates means accepting work from the cheapest agencies in the industry. Eventually the translator's résumé will list a whole range of agencies notorious for paying little and for their little regard for quality. And once that is the image one conveys with his or her résumé, it is difficult to rebrand oneself as a "high-quality translator".
Labels:
Beginning translators,
Business Practices
Saturday, January 10, 2009
"Hello World": learning to program to better understand how translation works for software and the web
I'm developing a new class on software and web page localization for DU's University College.
I plan to teach how to create a web page using a text editor: I find that actually inputting the code, and see what the result looks like in a Browser, then changing it and see the effects of the changes, helps to understand how the web works.
I'll also teach how to write some simple programs, to show what's code, what are translatable strings, and how to tell the difference.
Finally, I'll introduce some more advanced topics, such as explaining the role that variables play in the text that users read on screen.
I don't think that software and web translators should necessarily become programmers (though knowing how to program at least a bit is often helpful). But to do our job better we should understand how various components of software go together. This way we can know what to translate and how, what not to translate and why, and, above all, what kind of questions to ask in case of doubt.
You can find more information on the Certificate of Advanced Study in Translation on the University College Web site.
I plan to teach how to create a web page using a text editor: I find that actually inputting the code, and see what the result looks like in a Browser, then changing it and see the effects of the changes, helps to understand how the web works.
I'll also teach how to write some simple programs, to show what's code, what are translatable strings, and how to tell the difference.
Finally, I'll introduce some more advanced topics, such as explaining the role that variables play in the text that users read on screen.
I don't think that software and web translators should necessarily become programmers (though knowing how to program at least a bit is often helpful). But to do our job better we should understand how various components of software go together. This way we can know what to translate and how, what not to translate and why, and, above all, what kind of questions to ask in case of doubt.
You can find more information on the Certificate of Advanced Study in Translation on the University College Web site.
Subscribe to:
Posts (Atom)




