I thought that this editon of the newsletter may be of interest. You
can subscribe for free at www.internationalwriters.com/toolkit.
Jost
The Tool Kit
A biweekly newsletter for people in the translation industry who want
to get more out of their computers.
Issue 5-9-45 (forty-fifth edition)
Contents:
Dragging: Moving or Copying? (Premium Content)
MICROSOFT GLOSSARIES!!
Codepages
The Philosophy of Translation and Technology
The Last Word on the Tool Kit
Dragging: Moving or Copying? (Premium Content)
Even though the following shortcuts for moving files have been
available since Windows 3.1 (for those who have never worked with
Windows 3.1, this is the version of the operating system where you
actually worked in "windows"), many users have quite successfully
ignored them.
There are various ways to move a file, i.e., to change the location
of a file and/or to copy a file within Windows with the help of a
mouse. And though I'm consistently abused by readers when I mention
anything that can be done with the mouse rather than the keyboard,
here I go again:
When you select a file within Windows Explorer or any other file
display within Windows and drag that file with your left mouse button
while pressing Ctrl+Shift, the operation creates a shortcut. This is
helpful, for instance, if you would like to create a shortcut to a
document or a program on your desktop, within your Start menu, or the
Quick Launch area (the links to the right of the Windows Start
button). Windows will show you where you are allowed to create a
shortcut by displaying a little shortcut symbol alongside your
cursor. As soon as a stop sign appears instead, you'll know that you
can't create a shortcut in that particular area. If you play around
with it you'll be surprised at how much you can do with it, such as
creating a shortcut to a file within a Word document.
And speaking of Microsoft Word: You can also highlight a section
(several words, a paragraph, or a graphic) within Word, drag that
section using the same method as you would with a file, and create a
shortcut (i.e., a cross-reference) within your document or even in a
separate document. Clicking on that shortcut will make you jump to
the original text. By the way, it works the same if you drag your
selection part to your desktop. Windows creates a little "scrap" link
that opens your document to the very place in the original text if
you click it. This is a great trick if you're tired after a long day
of translating or editing and want to jump right back the next
morning with fresher eyes to the place where you left off.
Of course, all this can also be done with just the Ctrl key rather
than Ctrl+Shift. The difference is that in this case a copy is
generated rather than a shortcut of the file. As soon as you start to
drag your file, you can see a little plus icon appear beside your
cursor, indicating that Windows will copy that item rather than just
move it.
This procedure not only works within Windows Explorer to make copies
of files or folders (if you move a file or folder within the same
folder, Windows will make a copy of that file or folder and rename it
to "Copy of <OldName>"), but also within most Windows applications.
And I don't have to tell you that this is extremely helpful when
translating in a bilingual environment (as you would when you
translate with the help of a computer-assisted translation
tool). . . .
Also, if you forget which key is used for what -- Ctrl or Ctrl+Shift -
- you can drag a file or a text fragment by holding the right mouse
button down. As soon as you drop the dragged content you will see
your choices in a context menu.
MICROSOFT GLOSSARIES!!
Very good news! For the last time ever (!), Microsoft has released
its glossaries in the comma-separated value format that most of us
have gotten used to over the last 10 years at
ftp://ftp.microsoft.com/developr/msdn/newup/Glossary. The next time
new versions of the glossaries are published, they most likely will
be in a very different format.
(And for the newer reader who doesn't know what the Microsoft
glossaries are: they are bilingual translation memories for the user
interface translation of many of the Microsoft products -- an
invaluable terminology resource for translators who translate
software and other materials).
Check out the list of languages for this release: Albanian, Arabic,
Basque, Bulgarian, Catalan, Chinese (Simplified), Chinese
(Traditional), Croatian, Czech, Danish, Dutch, Estonian, Farsi,
Finnish, French, Galician, German, Greek, Gujarati, Hebrew, Hindi,
Hungarian, Icelandic, Indonesian, Irish, Italian, Japanese, Kannada,
Kazakh, Konkani, Korean, Latvian, Lithuanian, Macedonian, Malay,
Marathi, Norwegian, Nynorsk, Polish, Portuguese (Brazilian),
Portuguese (European), Punjabi, Romanian, Russian, Serbian
(Cyrillic), Serbian (Latin), Slovak, Slovenian, Spanish, Swedish,
Tamil, Telugu, Thai, Turkish, Ukrainian, Urdu, Vietnamese, and Welsh.
That's an impressive list of 58 languages -- many of which you and I
would probably be hard pressed to even place geographically.
Depending on the language, there can be a substantial difference in
the number of files and the size of the zip file in which they're all
located. The size of the file that holds the German glossaries alone
is more than 100 MB (on the other side of the spectrum, Nynorsk and
Albanian have less than 2 MB).
This release is particularly useful, though, because glossaries of
older product releases that have not been published before are also
included along with the newest releases of each product. It ends up
being a real gift, and if you want to drop them a note and say thank
you, you may do that at termhelp@....
But please don't write to tell them that their servers are down and
you can't download the glossaries. The FTP server that the glossaries
are located on is not particularly strong and you may have to try
several times before you can connect.
Codepages
At www.ascendercorp.com/codepages.html you can find a helpful listing
of code pages for various languages that may be particularly helpful
when translating websites. Even though we're in the age of Unicode
and there really shouldn't be any reason for the Tower-of-Babel-like
confusion of code pages, confusion persists because many websites are
not in Unicode yet.
If you translate HTML pages with a CAT tool, the tool will most
likely automatically change the code page for the target language
marker for you. That marker is located at the top of the HTML file
and looks something like this:
<meta content="text/html; charset=iso-8859-1" http-equiv="Content-
Type">
(the code page is described where it says "iso-8859-1" in this
example)
And this is the ONLY place where you should "mess" with the HTML code
of a client's file. If the file comes in Unicode (UTF-8), you should
not do anything to the charset marker: Unicode will be able to
display (almost) all languages correctly.
One last comment about web-related things: Opera (www.opera.com) has
just released its browser for free (previously you either had to
accept advertisements or pay a fee). Opera is a truly full-fledged
browser with all the bells and whistles you could wish for, but the
greatest benefit as far as I am concerned is the speed. The program
opens in less than half the time that Firefox or Internet Explorer
need.
The Philosophy of Translation and Technology
As expected, there were some interesting reactions to the "dinosaur"
article in the last Tool Kit. Here is a particularly interesting one
from Roy Davison (www.RoyDavison.com), a Dutch-into-English
translator since 1978:
"Maybe you are confusing a connoisseur's view with a dinosaur's view.
"My experience is similar to that of Mr. Anatoly Zolotkov with regard
to CAT. I have tried several programs and they slow me down and
greatly decrease the quality of the translations because of the
interference caused by the utterly stupid suggested translations.
"For the sake of uniformity, I use a personally developed system
based on search and replace of standard expressions and technical
terms.
"I suppose that someone who took the time I do not have to learn how
to easily use a CAT program could gain some advantage from it. But
for me it is like trying to run with a ball and chain tied to my leg.
And I do not see how the interference problem could ever be solved.
When I see a sentence in Dutch I immediately know the English
equivalent. (. . .) But if I see another translation it interferes
with my ability to come up with the best translation. It then takes
much time to fix the bad translation and the quality is usually less
than my own translation would have been.
"With CAT one can quickly crank out 'something', but much more time
must be spent tooling it into a good translation. In my experience,
this requires more time than it takes to make a good translation
without CAT."
I think that these are valuable comments and are probably fairly
representative of a certain "translation philosophy."
What I would argue is this: the value of acquiring training to
understand the technical workings of translation memory programs is
fairly undisputed. Many translators do this on their own, with the
help of other translators in discussion groups, or through official
training seminars. Translators who have invested in one kind of
training or the other at the onset of their use of a translation
memory tool are typically more successful with it than their
colleagues who assume that the tools are or should be intuitive
enough for them to become a successful user from day one. This is not
a new concept and is true for virtually every complex work process or
product.
What we may need to discuss much more is that it also takes training
and experience on a mere translation level to adequately work with
translation memory technology. One of the primary qualities of a
translator working with translation memory applications should be
that of skepticism. Blind trust in what the translation memory or the
terminology management component suggests can easily lead to the poor
quality that Roy describes. However, if your translation memories and
especially your terminology databases are built up adequately, there
typically is a lot more than just one "correct translation." Instead
there is often a host of suggestions that the human translator can
select from or add to.
Another source of problems can be the unqualified selection process
of sources for translation memories and terminology databases. Just
because something has been translated or is bilingual doesn't mean
that it's good or usable as a database. In my opinion, this is one of
the main problems of alignment (i.e., the creation of a translation
memory from separate documents in source and target versions). While
alignment is a great way of building up specific databases for
specific topics and/or clients, the sheer amassing of data is often
frustrating and useless.
This is a good discussion, though, because it goes right to the heart
of what we do as translators and ways that we can or cannot increase
productivity and quality. While I obviously have strong opinions on
this matter, I'm intrigued to hear others as well.
© 2005 International Writers' Group