The Translation Outpost

A project of Alex Lane and Galexi Wordcraft, LLC

User Tools

Site Tools


Sidebar


“Without his exceptional skill and adeptness at translation and interpretation, our communication and coordination with our Russian Federation counterparts would have been impossible.“ – L. E. Olsen, Capt., USN


start

Paragraph spacing that shows up!

Generally, I don't mess with formatting while translating text, but while I'm reviewing the translation, I cannot help but notice occasional–and sometimes not-so-occasional–formatting that cries out for a paragraph to have some space added either before or after.

The VBA code to do this is actually pretty straightforward. Here's the code for the macro IncreaseAfterBy3 (deducing what the code might be for a macro named IncreaseBeforeBy3 is left as an exercise for the reader):

Sub IncreaseAfterBy3()
'
' Increase the space after the current paragraph by 3 points
'
'
    With Selection.ParagraphFormat
        .SpaceAfter = .SpaceAfter + 3
        .SpaceBeforeAuto = False
        .SpaceAfterAuto = False
    End With
End Sub

I do not know whether setting both .SpaceBeforeAuto and .SpaceAfterAuto to false is absolutely required for this macro to work correctly, but as they do no harm in any event, I've left them in.

I've use this macro quite often, and in one section of this one document I was reviewing/editing, I noticed that it didn't seem to work at all. Puzzled, I brought up the Paragraph dialog box and noticed immediately that (a) the box labeled Don't add space between paragraphs of the same style was checked, and that (b) the specified spacing after the paragraph in question was now rather large, as I had executed the macro multiple times.

:-/

It occurred to me that since I wanted to increase the spacing after the paragraph, the solution was to have the macro uncheck the Don't add space… box, and the most direct method I could imagine of doing this was to fire up Word's Record Macro capability and step through the process, during which I would check the box, and then copy the line(s) that did what I wanted into the macro.

Surprisingly, the resulting VBA code didn't provide any clues as to what those lines might be, so I recorded a second macro that basically did the same thing, except this time, I unchecked the box. I figured if any lines changed in the generated code, that those were the lines I needed.

As it turned out the code for both operations was identical.

Back to the drawing board!

After a few minutes with Google, I determined that property I was interested in was associated with a Style and not a Paragraph, as in the line:

ActiveDocument.Styles("Normal").NoSpaceBetweenParagraphsOfSameStyle = False

The main hangup with this one-liner is that it applies to the Style called Normal; using this approach would change the parameter for all paragraphs in the document whose style was Normal. What I wanted was a way of changing this property just for the paragraph in which the cursor was located. After a bit more digging, it turned out the following code does the trick:

    With Dialogs(wdDialogFormatParagraph)
        .NoSpaceBetweenParagraphsOfSameStyle = 1 
        .Execute
    End With

Inserting these lines just before the End Sub line in the IncreaseAfterBy3 macro code gains the desired behavior. Now, whenever I want to open up just a bit of space beneath a paragraph, that space will appear.

Cheers…

Unjustifying paragraphs

As it turns out, I have a client who really, really does not like to see justified text in the documents I send him. This used to eat a certain amount of time during the post-translation phase, as the folks who put together the source document mix justified with left-aligned with centered, with a dash of right-alignment to round things off.

So it was only natural for me to finally sit down and write a Word macro that, basically, goes through each paragraph within a document and changes only those with justified text to display as left-aligned. Check it out:

Sub ChangeJustifiedToLeft()

Dim oSource As Document
Set oSource = ActiveDocument

j = oSource.Paragraphs.Count

For i = 1 To j
StatusBar = "Processing " & i & " of " & j
If oSource.Paragraphs(i).Format.Alignment = wdAlignParagraphJustify Then
  oSource.Paragraphs(i).Format.Alignment = wdAlignParagraphLeft
End If
Next i

End Sub

The StatusBar line is there to provide some visual feedback as the macro works its way through a file. Execution is not glacially slow, but it's far from blazing fast, and seeing that something is progressing makes the experience tolerable. (BTW, assigning the paragraph count up front to the variable j is done to keep things from slowing down even further by having to call oSource.Paragraphs.Count every time the ''StatusBar“ line is executed.)

2015/03/30 21:19 · Alex Lane · 2412 Comments

An org-mode experiment...

I've been using org mode in emacs for a few years, now, to help me keep track of my assignments, and more recently, to help generate invoices.

To generate a line item for an invoice, an item must have certain “Properties” (a feature of org mode). Generally speaking, these are:

  • a BillUnit property, which answers one of the following questions:
    • Is the charge based on source words or target words?
    • Does the job involve an hourly charge?
    • Is this a rush job?
    • Is this a minimum job?
  • a Units property, which indicates the number of BillUnits to bill.
  • and the all-important UnitRate, which is multiplied by the Units to get the line item total.

If I haven't done work for a certain client or end client for a while, I sometimes forget what UnitRate to charge, resulting in either (a) having to fish through the archive to find a job for the same client or end client, or (b), if I'm not mentally on the bounce, charging an incorrect—and typically lower—rate for work.

So I got to thinking about automating the process, and just as an experiment, I created the following function in my .emacs file (the file that emacs reads upon startup):

(defun clientA-xl8 () 0.xx)

where 0.xx reflects my translation rate for client “A”. Then, instead of assigning the value of 0.xx to the UnitRate property of the job, I entered the value

(clientA-xl8)

and then, when I ran my invoice generation function… lo, and behold (!), my hypothesis—that emacs evaluates property values in org mode and then uses any returned value—was demonstrated to have merit.

This is just a first step, but an important one.

2015/03/23 15:18 · Alex Lane · 2400 Comments

Oh, those 'editing blues'...

Despite the hopes and dreams of a number of dedicated programmers, computer translation–also known as machine translation–still falls far short of the quality most clients expect in their translated documents. However, one area in which computers have made significant progress is in the area of translation memory, which relies heavily on pattern-matching new source text against previously encountered source and translated target texts (the latter translated by a human translator), which are stored in a database.

One of the strengths of such systems is that patterns need not match 100% for the software to work. The sentence My name is Mary is a 75% match for the sentence My name is John and any translation memory system worth its storage space will recognize that. So not only will translation memory software recognize (and reuse) chunks of text that are identical, but it will also reuse high-percentage matches, presenting them to the translator for editing into final form.

Increasingly, however, agencies are using translation memories to “pre-process” documents. This results in the insertion, into draft translations, of (more or less) matching segments taken from aggregated corporate translation memory files. The reason for doing this has to do with the rather strange relationship between editing and translation in the translation profession: Editing, you see, is paid at a lower rate than is translation, typically between 25% and 33% of the rate paid for translation.

This is curious, if you consider that when a translator translates a document, the work flow cycle can be approximately described as follows:

  1. Read a portion of the source text.
  2. Comprehend the meaning of the text.
  3. Mentally recast the same meaning in the target language.
  4. Type out text that duplicates the meaning in the target language.

On the other hand, the work cycle undertaken when a translator edits a document can be approximately described as follows:

  1. Read a portion of the source text.
  2. Comprehend the meaning of the text.
  3. Read the corresponding portion of the target text.
  4. Identify the errors, if any, in said target text. Errors include:
    1. mistranslations,
    2. omissions,
    3. incorrect usage,
    4. terminological inconsistency,
    5. grammar, spelling, style, and punctuation problems, and
    6. awkward language.
  5. Modify the target text so as to correct the errors in the translation.

I don't know about you, but it seems pretty clear to me that a translation editor's work is significantly more complex than that of the translator of the text being edited. So then, you may ask, why is editing paid at a lesser rate?

I think it is because the editing rate has traditionally been predicated on the translation being of high quality to begin with.

If a translator is really, really good and produces high-quality work with no usage, grammar, spelling, style, or punctuation problems, or awkward sentences, or inconsistent terminology, the editor will generally have a pretty easy time of it when it comes to editing. However, if a translator produces translations that are riddled with such issues, editing such text begins to resemble a retranslation instead of an edit. In fact, when I started in this industry, agencies did their best to refrain from assigning work to translators who produced poor translations.

What's a high-quality translation? Well, back when I worked in-house for one of my clients, we took the criterion used by the American Translators Association for certification of entry level proficiency and adapted it to our company's ISO 9000 quality program. For example, if an editor found, on the average, less than one major error per 500 words of text, said translation was considered acceptable (from the perspective of what an editor had to do to edit it). Finding one major error per 250 words of text was considered cause for concern; finding two such errors per 250 words of text was evidence of incompetent work.

Do the segments in “pre-processed” documents represent high quality? Hardly.

Typically, pre-processed documents will contain segments that represent an “80% match” or better. This means that unless an offered segment is a “100% match,” it contains–at minimum–at least one major translation error as compared against the source text.

As an aside, it should be noted that even a candidate segment offered as a “100% match” doesn't actually guarantee that the segment is usable. One all-too-common problem is that the “100% match” classification is not merited in the first place. (A document I translated/edited some time ago offered “acquisition parameters” as a 100% match for the Russian “технические условия,” whereas the fairly standard rendering of the Russian source term is actually “specification.”) And problems may even be encountered if a “100% match” is perfectly acceptable text, as in the case where the terminology used in a proposed segment is not consistent with that used in the rest of the document.

In the final analysis, if we assume that segments to be “edited” contain exactly one major error per segment, then if we charitably assume an average of 25 words per sentence and do the math, we find that one page of “pre-processed” text presents the editor with ten major errors to correct per page. Some would maintain that such work squarely falls into the retranslation category. (I do, at any rate, but I just work here.)

In the end, having to edit retranslate gobs of what are, in effect, error-riddled translations at what amounts to a steeply cut rate is bad for one's morale and risks awakening that little voice in the lazy, shirking, goldbricking part of the mind that all of us seem to have, urging us to exert a minimum level of effort when making editing corrections, because even if the result is not perfect, it is head-and-shoulders better than what we started with.

Listening to that voice is a sure-fire route to what motivational speaker Zig Ziglar called “stinkin' thinkin',” and that kind of stuff is fatal if you want to succeed as a freelancer.

2015/03/06 21:22 · Alex Lane

Finding errors in fields

So the other day, I used an old translation as a template for a new translation, and after making all of the suitable changes and performing my QC, the document was sent off, along with the other documents of the assignment.

The old translation was old enough for me not to remember that I had used bookmarks and fields in the document, and even though my revision had “stepped on” a bookmark that occupied a table cell (I replaced the bookmarked contents with new contents), the document looked completely normal on my screen. As it turned out, it looked okay on the editor's screen as well.

It looked right on the end client's screen, too, until he tried to print it, whereupon the message Error! Reference source not found appeared in several places in the one-page document.

Oops.

In the end, the problem didn't cause any major ripples, and it was solved in short order. In the aftermath, however, it occurred to me that perhaps I should start printing documents as part of my QC process (no actual printing is necessary; it's enough to simple select File | Print and the print preview will show the error), but then I realized this would only help for short documents. So, after digging a bit on the Internet and my VBA manual, I came up with a macro that informs me if a field update is successful or not.

Sub UpdateFields()

  If ActiveDocument.Fields.UpDate = 0 Then
   MsgBox "Fields updated successfully!"
  Else
   MsgBox "There is a field with an error!"
  End If
  
End Sub

According to the Microsoft Office Dev Center Documentation, the ActiveDocument.Fields.UpDate method updates all the fields in the main body of the active document, returning the value zero if everything is okay or the index of the first field that contains an error.

After experimenting, however, I found that if a field contains an error, the method pretty consistently returns the value -1 (instead of an index to a field), which means that if the macro reports the existence of a field with an error, you'll have to search for the string Error! inside the document to find it.

Suggestions for improvement to the macro are welcome!

2015/03/05 22:24 · Alex Lane

Footnote fun

There are times, in the course of word processing, when one and the same footnote must be referenced from several places in the text. The quick and easy solution is to insert a new footnote into the document and then copy the text from the previous footnote into the new footnote. I personally think having two or more identically worded footnotes in a document is ugly (especially if multiple references appear on the same page), but this approach gets the job done.

There is, however, a way to refer to the same footnote from several points in the document text. I think it's more elegant than simply repeating the same footnote in the text.

To do this, enter the first occurrence of the footnote in the usual manner. Then, at any point where you want to refer to the same footnote:

  1. Select the References tab and then Cross-reference under Captions.
  2. In the Reference type list box, select Footnote.
  3. In the For which footnote list box, select the footnote you want to refer to. The diagram below shows the appropriate part of the ribbon and the dialog box.
  4. Click on the Insert button, and then on the Close button. You will see a footnote number at the insertion point, but it will be formatted as regular text.
  5. To fix that, use your favorite method to highlight just the newly inserted footnote number.
  6. Type Shift + F9. The number will turn into a Word field, for example
    { NOTEREF _Ref413254028 \h }

    (Note: When you do this, the string of digits following _Ref will almost certainly be something other that what is shown above.)

  7. Between the \h and the closing curly bracket, insert \f. The text of the field should now look like
    { NOTEREF _Ref413254028 \h \f }
  8. Type Shift + F9 again. The field text will disappear, and the new footnote will be superscripted.

One extra tip: Before finalizing or performing QC on any document that contains fields, it's an excellent idea to type Ctrl + A (which selects all text) and then F9 (which updates all fields).

2015/03/04 18:55 · Alex Lane

ScanSnap tip

One of my better purchasing decisions last year was to buy a ScanSnap scanner. What makes this scanner great is its ability to quickly scan both individual pages and stacks of pages (up to about 30-40) and the fact that it automatically scans both sides of pages that go through the unit. Scanned documents are automatically saved as PDF files.

One issue I have been having while scanning documents whose pages had been stapled together is having the pages “stick together” after the staple has been removed. This behavior is apparently the result of the stapling or the staple-removing process. As the ends of the metal staple are forced through the paper (or drawn back through the paper when a staple is removed), small, nested cone-like structures are created along the paths of the staple holes. When the staple is removed, a number of such structures will retain enough purchase to cause pages to all too often go through the scanner two at a time. The only way, then, to ensure glitch-free scanning of such documents is to first page through and manually separate the pages, which takes some time.

Or you could try my quick and dirty solution.

Unless there is an overriding reason to retain the entire page of the document being scanned (and this is hardly ever the case, as documents are stapled in the corner, away from text or graphics), just cut off the stapled corner of the document. Most of the time, the missing corner won't even show up in the scan.

Happy scanning!

2015/03/03 19:06 · Alex Lane

Heavily Under Construction

Happy New Year!

If you've come to get a copy of my GPG public key, you've come to the right place!

2015/01/02 08:04 · Alex Lane
start.txt · Last modified: 2015/01/02 08:05 by galexiadmin