Warning: count(): Parameter must be an array or an object that implements Countable in /home/jodybyrn/public_html/content/wp-includes/post-template.php on line 250

JodyByrne.com

Translator, Localiser or Jack-of-all-Trades? New Challenges Facing Today’s Translator

First published as Byrne, Jody (1999) Translator, Localiser or Jack-of-all-Trades? New Challenges Facing Today’s Translator. Translation Ireland, Vol. 13, No. 1, March 1999: Irish Translators’ Association

In today’s marketplace we as professional translators are increasingly being confronted with a considerable, if not startling change in both technology and the tasks we must address as part of our work. No longer are we expected to simply “translate” texts, providing a translation alone with no special formatting or other additional preparation
of the translated text. Instead we are often expected to provide what would have been regarded five years ago as services well beyond the remit of the translator: desktop publishing, graphics editing, online publishing, website translation, help files… The list is indeed quite considerable!
In actual fact one would be excused for wondering what exactly it is we understand by the word “translator”. Surely a translator simply translates? So where do we fit all of the ancillary tasks into our understanding of the word translator? Interestingly, the field of localisation, long regarded as being, in part, a cousin of translation provides us
with a possible moniker for today’s translator: documentation localiser. Admittedly a rather grandiose and technical-sounding label, but when we think of the scope of the work we carry out to produce a translated or “localised” text it seems appropriate.

Firstly, we find that even our perception of a text has undergone some radical changes in recent years. When we think of text we think, quite justifiably, of paper and ink. With the increased reliability and accessibility of  computers we saw the traditional hardcopy text transferred to the early monochrome VDU screen as the typewriter faded into obsolescence. Nowadays, “texts” may never even reach the printed hardcopy stage. Much of the documentation – manuals, reference guides, help files etc. – provided with modern software products is to be found in electronic format. These online documents are almost an alternative existence for texts. What is more, there are myriad variations of online documents: help files (.hlp) Portable Document Format (.pdf), HTML, Word files… All of which are stored on CD-ROM or the hard disk of your computer.

You may well be asking how this changes the way in which many of us describe our profession. And you would be quite justified in doing so. For this is the crux of my point: how can we adapt to the challenges of a new era of translation / interlingual communication and a reassessment of the role of the translator if we do not know how
our working practices will be affected. How can we adapt if we do not possess the skills necessary to make these changes? Obviously I cannot, and indeed would not, claim that I can impart all of the information and knowledge necessary. The fact of the matter is that all of us, no matter how experienced or schooled, are constantly learning new skills, technologies and strategies.  No matter how diligently we endeavour to stay abreast of technological advances (in addition to all of the other backroom tasks of the translator), technology will move on quicker than we can hope to keep up with. Nevertheless, the pressure upon all of us to acquire these skills is relentless. I believe there are a number of key areas which are of importance. These skills allow us to better meet the demands placed on us by an ever changing marketplace.

HTML

HTML or Hypertext Mark-up Language is familiar to most of us in one form or another not least because it forms the basis upon which most websites are built. However, when it comes to translating HTML files, or more commonly entire websites we can often run into problems. If you are not familiar with how HTML works or what it looks like,
a good idea is to view source code of a web page by opening it using the View Source commands of browsers such as Microsoft Internet Explorer or Netscape Navigator or with a text editor such as Notepad. Alternatively you can consult the HTML specifications at www.w3.org. What you see is the text that appears on the web page as
viewed through the browser surrounded by numerous tags or formatting codes which are contained in brackets < and >. These tags control the appearance and formatting of the document as well as instructing the browser to perform certain functions. The following is a typical tag:

<BODY BGCOLOR=“#000000” TEXT=“#008080” LINK=“#C0C0C0”>

The body part of the tag refers to the part of the document, i.e., the body text. The bgcolor, text and link elements refer to elements found within the body text. The hexadecimal codes (#008080) determine the colours of the elements referred to. This type of tag should not be translated or altered in any way as it may affect the overall
appearance or functioning of the page.

One tag which is of relevance to us and which is often overlooked is the <ALT> tag. This tag is used within an image tag <IMG> to insert an alternative text representation of the image if for some reason the image does not load correctly. It also displays a hint-type text when the cursor passes over the image in a browser. Although this text is
easily overlooked, it must be translated.

The <META> tag is another easily overlooked tag which contains translatable text. The primary type of META tag which concerns us is the <META type=“keywords” content=“words, words”>. This type of tag is not visible when the file is viewed in a browser yet it is important for other reasons: it is used to create keywords which are scanned by search engines such as Yahoo, Excite, Infoseek, Lycos and so on. These keywords (in our example “words, words”) must be translated to accommodate searches by users in the target language(s). Whether you include the original keywords in the translated file depends on your brief for the job. This type of text is often overlooked both during translation and also during word counts which can cause quite substantial errors when invoicing a client.
We now find ourselves asking two questions: How do we translate HTML files? How do we perform a wordcount on HTML files? With regard to the question of how to translate the files, we have a number of options open to us: we can use any text editor such as Microsoft Notepad or similar, MS Word, HTML editors such as Microsoft FrontPage, WebEdit or Arachnophilia HTML Editor, CAT tools such as Translators Workbench, Déjà Vu, Transit etc. The exact procedure for translating the text varies depending on which application you use. Once we have translated all translatable text in the files we need to count the number of translated words. Again, there are a number of methods but not all include the text contained in the <META> and <ALT> tags.

Rather than manually count all the text in the file there are a number of tools on the market to do this. One such tool is WebBudget, a product developed in Spain which counts all visible text as well as hidden text contained in tags and Java scripts etc. WebBudget is available from Aquino Software at www.webbudget.com. Another very good tool is TransWeb Express by Berlitz which is available from www.berlitz.ie/TWE [Edit: this tool is sadly now defunct]. In addition to what has already been said, here are a number of other tips to bear in mind when translating HTML files:

  • Never change URLs (Uniform Resource Locators; for example www.altavista.com) or mailto: commands.
  • When inserting accented characters, use the appropriate ASCII codes instead of, for example &Egrave (for É)
  • Do not change filenames or extensions (.htm or .html) as they may affect links from several pages
  • When you have finished translating the files, check them for layout andfunctionality using as many different browsers as possible.

PDF and PostScript Files

As I have already stated, most documentation produced by software manufacturers is distributed in electronic format. probably the most common of these formats is the Portable Document Format developed by Adobe. Using Adobe Acrobat these files can be created from any application and depending on which of the two possible methods
you use to make the files, special formatting, hyperlinks etc. can be retained from the original translated file. What makes this format so attractive is that the same file can be read on virtually any platform by using either Acrobat itself or Acrobat Reader, a free application for viewing PDF files available from www.adobe.com.

So now that we know what PDF files are, we should look at how to produce them. I mentioned above that there are to ways in which to produce PDF files: firstly you can “print to PDF” which converts the original file into PDF format using the PDF Writer printer driver. This method is suitable really only for simple documents and business literature which do not contain complex formatting. The other method, using Acrobat Distiller, is suitable for maintaining even the most complex formatting from DTP applications. You can either print directly to Distiller Assistant or convert a PostScript (.ps) or a printer file (.prn) into PDF format by simply opening it with Distiller.

An important issue in the creation of PDF files is that of fonts; certain fonts and certain point sizes do not transfer well into PDF format. You should make sure that you have the exact same fonts which were used in the original source file before you convert your translation into PDF format. Often what happens if any fonts are missing from say, a template or stylesheet for a file is that they are substituted with another similar font which can seriously affect the format and layout of the document. The following are some other things to bear in mind when converting translated files to PDF format:

  • Any graphics which appear in the file should appear with the same quality as theoriginal. If there are significant differences in the quality of the source andtranslated files, you could try recreating the PDF files using different imagecompression options or by changing the file format of the image.
  • If the PDF file is intended to be printed out by the user, either in its entirety or in sections, make sure that you select A4 as the paper size when you create the PDFfile.
  • Make sure that the default page view and magnification of the PDF file when it is opened is the same for both source and translated files.
  • The translated PDF file should contain the same Document Info as the source file –this information includes such information as document title, subject, author andkeywords. This information should be translated where appropriate. To check this, go to the File menu and click Document Info.
  • Check with your client if you are required to create bookmarks and thumbnailviews of the pages etc. Often, especially on large documents, the bookmarks andcross-references are contained in the original source file (not the PDF file). These are then retained when you create the PDF file.
  • The size of the translated file should be roughly the same as the original. If this is not the case, try creating the PDF file again using different compression levels.

Localising Graphics

Most, if not all, software manuals contain copious amounts of graphics and screenshots to better illustrate the operation of the product as well as to familiarise users with the interface. When translating the manual, we need to replace these screenshots from a localised version of the application itself. There are a number of ways to do this.
Perhaps the best way of doing this is to use a graphics editing package such as PaintShop Pro, Collage Complete, Capture Professional or similar. PaintShop Pro is probably the most commonly used tool and is available as shareware from the makers at www.jasc.com [Edit: now part of Corel Corp.].

PaintShop Pro allows you to determine exactly which part of the screen to capture, whether or not the cursor should be included in the capture etc. It also allows you to edit the captured images. Another, more basic method is to press the Alt key and press Print Screen on your keyboard. When you have done this, open a graphics package such as MS Paint and Paste the image into a new file. The disadvantage of this method is that it lacks the flexibility of graphics packages and only captures an entire active window or dialog box.

Sometimes, however, creating screen captures is not possible for a variety of reasons: the localised version of the software may not yet be available, the image file may be missing or there may be some error in the file itself which prevents it from being used. In such cases we need to translate the image itself directly. In order to get at the text to
be translated it is necessary to use a graphics package to edit the image. One of the more popular packages is PaintShop Pro. First we need to delete the source word. We do this by selecting the text with the Select tool and outlining the word. We now delete this and fill the resulting space with the same colour as the background. Using the Text tool insert the translated word into the image. Normally Microsoft applications use 8-pt MS Serif Sans in menus and dialog boxes, although Arial is sometimes used. Now move the inserted text to where the original word was. Repeat this process until the entire image has been translated.

In the case of both screen captures and edited images, you should determine whether or not the image is to be embedded or linked in the translated document. Be sure also to save it as the same file format to maintain consistency.

Where to Now?

The paragraphs above are by no means exhaustive nor are they comprehensive. Simply knowing how to create PDF documents, translate HTML files and edit screen captures does not mean we know all there is to know. Nor does it mean we are fully prepared for the bewildering range of technologies abundant in the marketplace. Rather they are
intended to serve as helpful hints aimed at assisting fellow translators. They are also pointers as to the future of our day-to-day roles as translators. They are sure signs that the days when simply having word processing skills was sufficient technical knowledge for a translator. We must acknowledge the fact that our activities have become so dependent on increasing levels of technical skills that our job description hardly compares to that of a translator ten or even five years ago. In short, it is our responsibility to both ourselves and to our profession that we strive to remain technically competent to both deal with current translation work but also to ensure that we continue to do so well into the future.

Share
Category: Academic Papers