A matter of style

Style guides are underappreciated by most of us I suspect. By me as well. And yet many of us encounter problems, misunderstandings or confusion with clients over matters of formatting, spelling conventions, punctuation, etc.

Once in a while some fairly advanced client presents me with a style guide for English documentation in their company or their client's operation. While these are seldom perfect, they are very helpful, and they provide an important point of orientation for work and a basis for "negotiation" if improvements are needed.

I think that style guides are a service, like terminology, that translators could and should offer to clients, with regular updates. A style guide included with a project proposal might also not be a bad thing; it would lay out clearly the rules of writing which would apply by default to a translation and once again serve as a basis for negotiation if something else is desired. No more "oh, we actually wanted British English" three days after the delivery, with no indication of which British variant (Oxford, please) is desired. And, really, it should not be that hard to produce for most of us who have some notion of the rules we usually follow when we write.

Tools like PerfectIt! are useful for developing and maintaining style guides which can also be used for automated quality assurance procedures to catch those little mistakes which are so easy to overlook.


I've been thinking about style guides for many months now, considering how best to integrate them in my business. Recent efforts to incorporate various old blog entries in hardcopy tutorial documents made it clear to me that I need to consider a style guide for this blog too. Up to now, the formatting of text to indicate interface elements (menu paths, button names, field labels, etc.) has used a riot of colors, fonts and text styles. This is a bit counterproductive for didactic purposes as I really ought to know after nearly 30 years of teaching.


Have style guides played a role in your translation transactions? Have they been useful? What opportunities do you see for making better use of them?

Final checks in memoQ

"Having to do a separate final check in Word is a major MemoQ disadvantage over the Word/Trados Workbench (and Wordfast Classic) WYSIWYG procedure. It might even make some of us abandon MemoQ."

I read that statement in a recent digest from the Yahoogroups memoQ forum with some puzzlement. What exactly does the author of those words mean?


There are a few arguments I can muster in favor of the necessity to do a final check in MS Word or another original format. The limitations of the spellchecker in memoQ is one of these. Even when the MS Word spellchecker is used, as I recall memoQ (in the versions where I noticed this problem) did not flag doubled words, and I have a bad habit of typing "and and" and the like.


The use of style guide and consistency-checking tools like PerfectIt! are other good reasons to do such external checks.


But when I do such things, I work on my second monitor and immediately incorporate changes in my memoQ project to keep the TM updated among other things. Also, the filters in memoQ enable me to examine the scope of some problems faster and with greater ease than multiple "Find" operations in a word processor or other software.


But if the person quoted meant simple ease of reading on the screen, I wonder if he has paid any attention to the optimal use of the memoQ translation preview. One could simply resize that pane after translation and read through a preview of the translation:

If a problem is found, clicking on the text will select it and cause the translation window (above the preview) to jump to the segment to be corrected. And of course this works for any format that yields a preview in memoQ, so you are not limited as you would be working with the Trados Workbench macros or Wordfast Classic in MS Word. Excel files, PowerPoint slides, HTML, ODT files and other formats enable you to work this way.


But another reason why I would hesitate strongly before regressing to the tools mentioned is that I would sacrifice the ability to do terminology checks with the QA module. (This is, of course, possible to a limited extent in TagEditor.) Or other QA checks which may be of interest. These features are severely underutilized, but they aren't hard to learn, and they offer considerable benefits to freelance translators in the competition for consistent formal quality.


Similar advantages are likely to be had from other recent versions of leading translation environment tools. Very often it pays to consider the points of difficulty we have with these and discuss them with other users, because often new and better ways of using them will come to light.